Лак кончается открытыми портами, много SYN_SENT соединений

Недавно у нас возникли проблемы с нашей настройкой Varnish (3x) -> Apache (3x), что привело к огромному скачку SYN_SENTсоединений.

Сам пик связан с количеством нового трафика, попадающего на сайт (а не DDOS), и кажется, что у наших машин Varnish возникают проблемы с переадресацией трафика на серверы бэкэнда (падение трафика Apache соответствует выбросам на лаках). ), перегружая пул доступных портов SYN_SENT.

Keep-alives включены в Apache (15 с).

На чьей стороне вина? Объем трафика является значительным, но ни в коем случае он не должен вызывать остановку такой установки (3 внешних сервера Varnish, 3 внутренних сервера Apache).

Пожалуйста помоги.

Скриншот Munin для подключения через брандмауэр здесь .

лакировка ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf (Лак)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

апаш netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (Apache)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

Ваша проблема, вероятно, с sysctl на серверах Apache.

Некоторые предположения: Как правило, Varnish значительно быстрее обрабатывает каждое соединение, чем веб-сервер (если, возможно, ваши серверы Varnish не имеют гораздо меньше ЦП, а ваши серверы Apache обслуживают только статические файлы, кэшированные в памяти.) Я предполагаю, что ваши соединения обрабатываются быстрее в лаке чем апач.

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

Похоже, ваши запросы застряли в Varnish и не попадают на серверы Apache.

Есть некоторые доказательства этого:

Обратите внимание, что в вашем графике Мунина до резервного копирования SYN_SENT запросы в TIME_WAIT увеличиваются, а после некоторого момента они начинают накапливаться как SYN_SENTS. Это указывает на то, что запросы начинают отвечать медленнее, затем резервная копия очереди и запросы вообще не получают ответа.

Это указывает на то, что ваш сервер Apache не принимает достаточно соединений (где они могут затем сидеть и стоять в очереди для обработки их Apache).

Я вижу несколько возможных ограничений в вашем конфигурационном файле:

Когда у вас есть всплеск, у вас есть около 30000 соединений в состоянии SYN_SENT на вашем сервере Varnish.

Однако на сервере Apache ваш max_syn_backlog составляет всего 16384. Ваш somaxconn - только 2048.

Также обратите внимание, что размер буферов вашей сетевой памяти на серверах Apache очень мал. Вы настроили их на сервере Varnish до 16 МБ. Но на сервере Apache ваш net.ipv4.tcp_rmem составляет всего 524 КБ, чтобы соответствовать вашему net.core.rmem_max.

Я рекомендую поднять все эти параметры на сервере Apache.

Вам нужно больше сосредоточиться на диагностике на сервере Apache, чтобы точно узнать, что происходит, но вам может не понадобиться, если вы повысите эти значения.

Вы, вероятно, не должны настраивать net.ipv4.tcp_mem. Обратите внимание, что блок для этого параметра находится в страницах, а не в байтах, поэтому копирование одного и того же значения из net.ipv4.tcp_rmem или net.ipv4.tcp_wmem (оба в байтах) не имеет никакого смысла. Он автоматически настраивается Linux в зависимости от вашего объема памяти, поэтому он редко нуждается в настройке. На самом деле это может быть вашей проблемой, произвольно ограничивая объем памяти, доступной для общей очереди соединений.

Смотрите: http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

Также обратите внимание, что ваш «vm.swappiness = 0» установлен дважды, один раз как 10, и снова внизу как 0, что является эффективным значением.

На сервере Varnish попробуйте изменить эти 2 параметра:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuse позволит ему повторно использовать соединения в TIME_WAIT.

tw_recycle может вызвать проблемы с балансировщиком нагрузки и т. д.