Недавно у нас возникли проблемы с настройкой Varnish (3x) -> Apache (3x), что привело к резкому скачку SYN_SENT соединения.
Сам по себе всплеск связан с объемом нового трафика, попадающего на сайт (а не с DDOS любого вида), и похоже, что наши машины Varnish испытывают проблемы с пересылкой трафика на внутренние серверы (падение трафика Apache коррелирует с всплесками на лаках ), переполняя пул доступных портов SYN_SENT.
Keep-alive включены на 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
Apache 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 обслуживают только статические файлы, кэшированные в памяти). Я предполагаю, что ваши соединения обрабатываются быстрее в 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 может вызвать проблемы с балансировщиками нагрузки и т. д.