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

[Alexey Schurov]

Странно что нет ответа, но думаю проблема еще актуальна.
Очевидно проблема с параметрами ядра, скорее даже их реализация.
Есть такой параметр 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 <http://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 at gmail.com
  Skype: a_schurov
  Mob: +7 91 60 62 44 77

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140519/a9f2f39f/attachment.html>