<html>
<head>
<meta content="text/html; charset=KOI8-R" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Странно что нет ответа, но думаю
проблема еще актуальна.<br>
Очевидно проблема с параметрами ядра, скорее даже их реализация.<br>
Есть такой параметр tcp_max_syn_backlog ограничивающий
максимальное значение backlog, man listen:<br>
The behavior of the backlog argument on TCP sockets changed with
Linux 2.2. Now it specifies the queue length for completely
established sockets waiting to be accepted, instead of the number
of incomplete connection requests. The maximum length of the
queue for incomplete sockets can be set using
/proc/sys/net/ipv4/tcp_max_syn_backlog. When syncookies are
enabled there is no logical maximum length and this setting is
ignored.<br>
Вот тут рассматривается как эти значения связаны с
net.core.somaxconn:
<a class="moz-txt-link-freetext" href="http://blog.dubbelboer.com/2012/04/09/syn-cookies.html">http://blog.dubbelboer.com/2012/04/09/syn-cookies.html</a><br>
Так вот первая проблема hardcoded в ядре и заключается в том что
net.core.somaxconn имеет тип USHRT_MAX, т.е. максимальное значение
65535. <br>
Вторая проблема в том что это ограничение очень неявное и его
очень трудно найти среди кривых "инструкций по тюнингу параметров
ядра". Вот тут обсуждается патч предназначенный предупреждать
админа о неверном значении (уже видел в действии на свежем ядре)
<a class="moz-txt-link-freetext" href="https://groups.google.com/d/msg/linux.kernel/2sXyQqIEMXw/uOQh_goW-9kJ">https://groups.google.com/d/msg/linux.kernel/2sXyQqIEMXw/uOQh_goW-9kJ</a><br>
Третья проблема в том что из-за одной переполненной очереди
страдают даже ненагруженные приложения типа мониторинга, причину
которой я пока не нашел.<br>
<br>
Итого могу посоветовать понизить значения
net.ipv4.tcp_max_syn_backlog и net.core.somaxconn до 65535. <br>
К тому же зачем выключили syncookies, есть веские причины это
делать?<br>
Дополнительно можно поэкспериментировать с параметром
net.ipv4.tcp_tw_recycle (reuse позволяет использовать
освободившиеся структуры в памяти, recycle позволяет делать это
очень быстро не дожидаясь окончания WAIT периода).<br>
<br>
07.05.2014 19:20, Bogdan пишет:<br>
</div>
<blockquote
cite="mid:%3CCACz2Q8G3=bsmbFPjwY+GE=HLtwSDF-iyEHxjVnmy_Vu8gru_6g@mail.gmail.com%3E"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Добрый день.<br>
<br>
</div>
Есть ряд серверов с Nginx ( 1.6.0-1.el6.ngx ),
PHP-FPM (5.4.27, 100-200 workers), memcached.
Входящая нагрузка - 1000-1500 коннектов в секунду,
может быть в пике до 2000.<br>
</div>
Исходящие соединения - подключения к локальному и
удалённмы PHP-FPM примерно с той же интенсивностью.<br>
</div>
<div>Процессоры: 2xE5-2430 (2.2Ghz, HexCore, HT)<br>
</div>
<div><br>
</div>
worker_processes 24<br>
worker_connections 8192<br>
sendfile on<br>
tcp_nopush on<br>
tcp_nodelay on<br>
listen <a moz-do-not-send="true"
href="http://0.0.0.0:80">0.0.0.0:80</a>
default_server backlog=32768;<br>
<br>
<br>
</div>
У меня есть мониторинг некоторых значений из
/proc/net/snmp и всей TCP-части /proc/PID/net/netstat
для master-процесса nginx.<br>
<br>
</div>
Типовое количество одновременно установленных (CurrEstab)
TCP-коннектов в системе на момент возникновения проблем
~40k.<br>
</div>
Суть проблемы: в прайм-тайм начинают просадки
производительности без перегрузки компонент системы. Т.е.
процессор уходит в idle ~90%, удалённые БД простаивают и
т.п. Продолжается это несколько минут, затем работа системы
восстанавливается и через несколько минут всё повторяется
снова.<br>
</div>
При возникновении проблемы в системе увеличивается TCP
RetransSegs с 200 до 1500-2000 в секунду, количество
установленных соединений уменьшается с 40 до 25 тысяч и менее.<br>
</div>
Обнаружил следующие отклонения параметров из
/proc/PID/net/netstat от типовых значений:<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
DelayedACKs - уменьшается с 3000 до 0<br>
<div>
<div>
<div>
<div>
<div>ListenDrops - рост от нуля до
40-50 (возможно этот и ряд других
параметров луше снимать с воркеров?)<br>
ListenOverflows - рост от нуля до
30-50<br>
TCPChallengeACK - рост от нуля до
60-80<br>
TCPDirectCopyFromBacklog - падение с
60K до 0<br>
TCPDirectCopyFromPrequeue - падение
с 12M до 0<br>
TCPDSACKRecv - падение со 120 до 60<br>
TCPDSACKUndo - падение с 60 до 30<br>
<div>
TCPFastRetrans - падение с 15 до 0<br>
TCPForwardRetrans - падение с 15
до 0<br>
TCPHPHits - падение с 35K<br>
TCPPrequeued - падение с 30K до
нуля<br>
TCPPureAcks - падение с 10K до 4K<br>
TCPTimeouts - рост 200 до
1100-1500<br>
<br>
</div>
<div>Все значения - скорость, т.е.
дельта показателя за одну секунду.<br>
<br>
</div>
<div>Вот такая вот невесёлая
картинка получается. Подскажите
пожалуйста, что ещё стоит добавить
в мониторинг и как вообще такую
проблему можно исправить?<br>
<br>
</div>
<div>sysctl (поверх дефолтного в
CentOS) следующий:<br>
<br>
net.core.rmem_default=16777216<br>
net.core.netdev_max_backlog=262144<br>
net.core.somaxconn=262144<br>
net.ipv4.tcp_syncookies=0<br>
net.ipv4.tcp_max_orphans=262144<br>
net.ipv4.tcp_max_syn_backlog=262144<br>
net.ipv4.tcp_synack_retries=2<br>
net.ipv4.tcp_syn_retries=2<br>
net.ipv4.ip_local_port_range=2048
65535<br>
net.ipv4.tcp_tw_reuse=1<br>
net.ipv4.tcp_max_tw_buckets=6000000<br>
net.core.rmem_default=65536<br>
net.core.wmem_default=65536<br>
net.core.rmem_max = 33554432<br>
net.core.wmem_max = 33554432<br>
net.ipv4.tcp_rmem=8192 873800
8388608<br>
net.ipv4.tcp_wmem=4096 655360
8388608<br>
net.ipv4.tcp_fin_timeout = 7<br>
net.ipv4.tcp_slow_start_after_idle
= 0<br>
<br>
</div>
<div>Помимо сказанного в nginx
массово падают ошибки о
невозможности подключения к
бэкендам FastCGI. Т.е.
предположітельно TCP-стэк ломается
не только "на вход", но и "на
выход". Conntrack выключен. <br>
</div>
<div>Ядро -
2.6.32-431.11.2.el6.x86_64<br>
</div>
<div>Подобное поведение проявлялось
с различными версиям Nginx, PHP,
ядра, раньше пробовал запускать
это уже нагрузку на Debian - было
ещё хуже.<br>
</div>
<div><br>
</div>
<div><br>
-- <br>
WBR, Bogdan B. Rudas
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Alexey Schurov
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:aa.schurov@gmail.com">aa.schurov@gmail.com</a>
Skype: a_schurov
Mob: +7 91 60 62 44 77</pre>
</body>
</html>