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