sockstat

dovidov · Непрочитанное сообщение **dovidov** » 2014-09-24 11:57:33

День добрый!
Имеется сервер

# uname -mor
FreeBSD 9.2-STABLE amd64

Запущены порядка 10-15 джайлов
Раз в 2-3 недели в джайлах перестают закрываться сокеты и начинаются дикие тормоза на отдаче контента.
Т.е. имеем, что-то вроде:

Код: Выделить всё

# sockstat -4 | grep -c 80
485128

При том, что обычная рабочая "нагрузка", примерно

Код: Выделить всё

# sockstat -4 | grep -c 80
150

DDoS-атак в момент проблем нет, нагрузка на сервер:

Код: Выделить всё

last pid:  9103;  load averages:  0.12,  0.12,  0.09                                                                         up 1+09:10:14  12:55:39
563 processes: 9 running, 518 sleeping, 0 zombie, 33 waiting
CPU:  1.7% user,  0.0% nice,  1.3% system,  0.0% interrupt, 97.0% idle
Mem: 3090M Active, 24G Inact, 1625M Wired, 44M Cache, 1114M Buf, 2545M Free
Swap:

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
   11 root       155 ki31     0K   128K RUN     1  32.4H 100.00% idle{idle: cpu1}
   11 root       155 ki31     0K   128K CPU3    3  32.4H 100.00% idle{idle: cpu3}
   11 root       155 ki31     0K   128K CPU5    5  32.3H 100.00% idle{idle: cpu5}
   11 root       155 ki31     0K   128K CPU0    0  32.3H 100.00% idle{idle: cpu0}
   11 root       155 ki31     0K   128K CPU7    7  32.3H 100.00% idle{idle: cpu7}
   11 root       155 ki31     0K   128K CPU4    4  32.3H 100.00% idle{idle: cpu4}
   11 root       155 ki31     0K   128K CPU6    6  32.3H 100.00% idle{idle: cpu6}
   11 root       155 ki31     0K   128K CPU2    2  32.3H 100.00% idle{idle: cpu2}
69743 www         24    0   326M 83656K accept  4   0:31  2.39% httpd
39419 www         23    0   309M 76456K accept  6   0:30  1.76% httpd
69734 www         25    0   330M 87516K accept  4   0:21  1.27% httpd
69783 www         24    0   330M 87324K accept  6   0:20  0.78% httpd
    0 root       -16    0     0K   288K swapin  1 7001.6  0.00% kernel{swapper}
51973 www         20    0   305M 72976K accept  6   2:03  0.00% httpd
   12 root       -60    -     0K   528K WAIT    0   1:59  0.00% intr{swi4: clock}

Код: Выделить всё

# sysctl -a | grep jail | grep sock
security.jail.param.allow.socket_af: 0
security.jail.param.allow.raw_sockets: 0
security.jail.allow_raw_sockets: 1
security.jail.socket_unixiproute_only: 1

Код: Выделить всё

# sysctl -a | grep max | grep sock
kern.ipc.maxsockbuf: 83886080
kern.ipc.maxsockets: 1046783

Проблема вероятно не в джайлах, а в самой хост-системе, но куда копать пока ума не приложу. Перезапуск джайлов не помогает.

Хостинг HostFood.ru · **Хостинг HostFood.ru**

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

skeletor

Смотрите netstat -an и состояние соединений: TIME_WAIT, ESTABLISHED, ... и по ним уже считайте, сколько каких и что нужно делать:
- если много ESTABLISHED, то нужно понимать почему, возможно DDOS-атака типа занять все доступные сокеты, а возможно стоит подтюнить сетевой стек на предмет увеличения количества сокетов, полуоткрытых соединений и прочего.
- если много TIME_WAIT, CLOSE, то можно уменьшить время ожидания закрытия соединения, например net.inet.tcp.msl=30000 или ещё меньше.

Ещё полезно посмотреть netstat -m, может идёт переполнение по каким-то буферам.
В любом случае, как минимум прочесть
http://www.opennet.ru/base/net/tune_freebsd.txt.html
http://dadv.livejournal.com/49013.html
http://alexandr.sysoev.ru/node/116

dovidov · Непрочитанное сообщение **dovidov** » 2014-09-24 13:18:14

skeletor писал(а):возможно DDOS-атака

Атак гарантированно нет. Сервер находится в демилитаризованной зоне и служит бакендом, перед которым есть фильтрующиие фронтенды. Никаких аномальны превышений трафика на нём нет. При этом сетевой стек там подтюнен, и самостоятельно готов принять порядка 500kpps перфект-син флуда.

skeletor писал(а):net.inet.tcp.msl=30000

На данный момент он уже 2500, но изменение никак не отразилось на результате.

Весь вопрос в том, что рост происходит не под действием атаки и т.п. Кол-во незакрытых сокетов растёт неторопливо на протяжении нескольких дней, а то и недель и начинается рост опять же не сразу, а через неделю-другую после ребута.
Сейчас повесил уведомлялку, чтобы поймать рост на начальном этапе, но не могу понять, что может являться "стартом" для такого роста.

skeletor

Не ставьте очень маленькое значение. 2500 - реально очень мало. Оптимальное значение - 15000. у вас явно где-то переполнение по стеку идёт и то ли уже тюнить некуда, то ли не всё подтюнено.

dovidov · Непрочитанное сообщение **dovidov** » 2014-09-24 13:50:34

skeletor писал(а):Не ставьте очень маленькое значение. 2500 - реально очень мало. Оптимальное значение - 15000. у вас явно где-то переполнение по стеку идёт и то ли уже тюнить некуда, то ли не всё подтюнено.

2500 это уже от безысходности на тестах дошёл, хотя на самом деле никогда проблем со значениями ниже 10000 не испытывал.
Но опять же, подчёркиваю, нагрузка не сетевой стек здесь попсовая всю дорогу. Выше 1kpps никогда не подымалась.

Гость

вновь начался рост

Код: Выделить всё

[18:35]# netstat -an | grep -c TIME_WAIT
3506
[18:45]# netstat -an | grep -c TIME_WAIT
6354
[18:55]# netstat -an | grep -c TIME_WAIT
9000

текущая активность

Код: Выделить всё

# netstat -w1
            input        (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
        12     0     0       1786         10     0       2313     0
        86     0     0      33606         55     0     152814     0
       140     0     0     121741        120     0     256348     0
       118     0     0      55433         75     0     199032     0

Код: Выделить всё

#  netstat -m
32785/4730/37515 mbufs in use (current/cache/total)
32768/3248/36016/2028130 mbuf clusters in use (current/cache/total/max)
32768/1536 mbuf+clusters out of packet secondary zone in use (current/cache)
0/2223/2223/1014065 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/300463 9k jumbo clusters in use (current/cache/total/max)
0/0/0/169010 16k jumbo clusters in use (current/cache/total/max)
73732K/16570K/90302K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
255042 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Electronik

покажите полный вывод когда выросло много соединений

netstat | grep tcp

netstat | grep udp

sockstat | grep tcp

dovidov · Непрочитанное сообщение **dovidov** » 2014-10-07 11:30:09

Electronik писал(а):покажите полный вывод когда выросло много соединений
netstat | grep tcp
netstat | grep udp
sockstat | grep tcp

Уже в следующий раз. В этот раз как-то быстро выросло. Меньше чем за 2 часа до 40000, пришлось ребутать. Прошлые разы несколько часов удавалось помучать.
Что ещё выяснилось - параллельно с ростом незакрытых сокетов перестаёт работать ipmi, т.е. не реагирует на клавиатурный ввод.

Electronik

может оперативе хана?
что за железо?

dovidov · Непрочитанное сообщение **dovidov** » 2014-10-07 12:28:59

Electronik писал(а):может оперативе хана?
что за железо?

Код: Выделить всё

# grep -i cpu: /var/run/dmesg.boot ; grep -i "real memory" /var/run/dmesg.boot ; dmidecode | grep -i "Product Name:"
CPU: Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (3700.08-MHz K8-class CPU)
real memory  = 34368126976 (32776 MB)
Product Name: X9SRE/X9SRE-3F/X9SRi/X9SRi-3F

forum.lissyara.su

sockstat

sockstat

Услуги хостинговой компании Host-Food.ru

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat

Re: sockstat