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

Bogdan bogdar at gmail.com
Wed May 7 15:20:57 UTC 2014


Добрый день.

Есть ряд серверов с 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20140507/965c62d5/attachment.html>


Подробная информация о списке рассылки nginx-ru