Re: Ломается TCP-стэк в CentOS 6, помогите настроить.

[Alexey Schurov <aa.schurov@xxxxxxxxx>]

Странно что нет ответа, но думаю проблема еще актуальна.
Очевидно проблема с параметрами ядра, скорее даже их реализация.
Есть такой параметр tcp_max_syn_backlog ограничивающий максимальное значение backlog, man listen:
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.
Вот тут рассматривается как эти значения связаны с net.core.somaxconn: http://blog.dubbelboer.com/2012/04/09/syn-cookies.html
Так вот первая проблема hardcoded в ядре и заключается в том что net.core.somaxconn имеет тип USHRT_MAX, т.е. максимальное значение 65535.
Вторая проблема в том что это ограничение очень неявное и его очень трудно найти среди кривых "инструкций по тюнингу параметров ядра". Вот тут обсуждается патч предназначенный предупреждать админа о неверном значении (уже видел в действии на свежем ядре) https://groups.google.com/d/msg/linux.kernel/2sXyQqIEMXw/uOQh_goW-9kJ
Третья проблема в том что из-за одной переполненной очереди страдают даже ненагруженные приложения типа мониторинга, причину которой я пока не нашел.

Итого могу посоветовать понизить значения net.ipv4.tcp_max_syn_backlog и net.core.somaxconn до 65535.
К тому же зачем выключили syncookies, есть веские причины это делать?
Дополнительно можно поэкспериментировать с параметром net.ipv4.tcp_tw_recycle (reuse позволяет использовать освободившиеся структуры в памяти, recycle позволяет делать это очень быстро не дожидаясь окончания WAIT периода).

07.05.2014 19:20, Bogdan пишет:

Добрый день.

Есть ряд серверов с Nginx ( 1.6.0-1.el6.ngx ), PHP-FPM (5.4.27, 100-200 workers), memcached. Входящая нагрузка - 1000-1500 коннектов в секунду, может быть в пике до 2000.

Исходящие соединения - подключения к локальному и удалённмы PHP-FPM примерно с той же интенсивностью.

Процессоры: 2xE5-2430 (2.2Ghz, HexCore, HT)

worker_processes 24
worker_connections 8192
sendfile        on
tcp_nopush     on
tcp_nodelay on
listen       0.0.0.0:80 default_server backlog=32768;

У меня есть мониторинг некоторых значений из /proc/net/snmp и всей TCP-части /proc/PID/net/netstat для master-процесса nginx.

Типовое количество одновременно установленных (CurrEstab) TCP-коннектов в системе на момент возникновения проблем ~40k.

Суть проблемы: в прайм-тайм начинают просадки производительности без перегрузки компонент системы. Т.е. процессор уходит в idle ~90%, удалённые БД простаивают и т.п. Продолжается это несколько минут, затем работа системы восстанавливается и через несколько минут всё повторяется снова.

При возникновении проблемы в системе увеличивается TCP RetransSegs с 200 до 1500-2000 в секунду, количество установленных соединений уменьшается с 40 до 25 тысяч и менее.

Обнаружил следующие отклонения  параметров из /proc/PID/net/netstat от типовых значений:

DelayedACKs - уменьшается с 3000 до 0

ListenDrops - рост от нуля до 40-50 (возможно этот и ряд других параметров луше снимать с воркеров?)
ListenOverflows - рост от нуля до 30-50
TCPChallengeACK - рост от нуля до 60-80
TCPDirectCopyFromBacklog - падение с 60K до 0
TCPDirectCopyFromPrequeue - падение с 12M до 0
TCPDSACKRecv - падение со 120 до 60
TCPDSACKUndo - падение с 60 до 30

TCPFastRetrans - падение с 15 до 0
TCPForwardRetrans - падение с 15 до 0
TCPHPHits - падение с 35K
TCPPrequeued - падение с 30K до нуля
TCPPureAcks - падение с 10K до 4K
TCPTimeouts - рост 200 до 1100-1500

Все значения - скорость, т.е. дельта показателя за одну секунду.

Вот такая вот невесёлая картинка получается. Подскажите пожалуйста, что ещё стоит добавить в мониторинг и как вообще такую проблему можно исправить?

sysctl (поверх дефолтного в CentOS) следующий:

net.core.rmem_default=16777216
net.core.netdev_max_backlog=262144
net.core.somaxconn=262144
net.ipv4.tcp_syncookies=0
net.ipv4.tcp_max_orphans=262144
net.ipv4.tcp_max_syn_backlog=262144
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_syn_retries=2
net.ipv4.ip_local_port_range=2048 65535
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_max_tw_buckets=6000000
net.core.rmem_default=65536
net.core.wmem_default=65536
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem=8192 873800 8388608
net.ipv4.tcp_wmem=4096 655360 8388608
net.ipv4.tcp_fin_timeout = 7
net.ipv4.tcp_slow_start_after_idle = 0

Помимо сказанного в nginx массово падают ошибки о невозможности подключения к бэкендам FastCGI. Т.е. предположітельно TCP-стэк ломается не только "на вход", но и "на выход". Conntrack выключен.

Ядро - 2.6.32-431.11.2.el6.x86_64

Подобное поведение проявлялось с различными версиям Nginx, PHP, ядра, раньше пробовал запускать это уже нагрузку на Debian - было ещё хуже.

--
WBR,  Bogdan B. Rudas

-- 
Regards,
 Alexey Schurov
 e-mail: aa.schurov@xxxxxxxxx
 Skype: a_schurov
 Mob: +7 91 60 62 44 77

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru