Проблема, с которой мы сталкиваемся, заключается в том, что время отклика некоторых HTTP-соединений превышает 60 с (около 5%). Я обнаружил, что проблема должна возникать между веб-сервером и балансировщиком нагрузки.
Вот мой вывод, мы попробовали два набора серверов:
Настройка A: только 1 веб-сервер (сервер A), весь трафик TCP напрямую указывает на этот сервер.
Настройка B: балансировщик нагрузки + сервер A, вес сервера A равен 100. С алгоритмом «Round Robin с постоянным IP-адресом»
Для установки A соединение TCP действительно стабильно, коэффициент тайм-аута составляет менее 1%. Однако для установки B коэффициент тайм-аута составляет более 5%, и вот в чем проблема. (тайм-аут соединения установлен на клиенте 60 с)
Мы протестировали эти два параметра в общей среде (за 10 минут), в которой есть ближайший номер пакета (около 700 000 пакетов) и трафик. В результате мы получили 2 набора tcpdump, я обнаружил несколько странных записей журнала и посчитал их следующим образом:
Setup A Setup B
TCP Zero window size 0 611
TCP Window Full 0 3672
TCP Out-Of-Order 4147 4577
TCP Retransmission 23665 21551
TCP Dup Ack 10592 10121
Для приведенного выше результата я совершенно уверен, что это проблема с окном TCP, поэтому я попытался включить перезагрузку net.ipv4.tcp_window_scaling>, но это не помогает. Еще пробовал отключить iptables, тоже не помогает. Я не знаю, влияет ли какая-либо конфигурация на окно TCP.
Одна вещь, которую стоит знать, это наш ip loadbalancer xx.xx.117.128, все пакеты, помеченные как TCP Window Full, от сервера A до xx.xx.117.25, и все пакеты, отмеченные как размер окна TCP Zero, от xx.xx .117.25 к серверу A
Я спросил специалиста по softlayer, что такое xx.xx.117.25, и они сказали: «xx.xx.117.25 - это адрес, с которого балансировщик нагрузки будет подключаться к вашим реальным серверам». Они предполагают, что это проблема брандмауэра, как я упоминал выше. Я тестировал с выключенным iptables. Таким образом, мы можем устранить этот фактор
Это то, что я обнаружил до сих пор.
Возможно, вас интересует конфигурация sysctl, и вот она:
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.shmall = 4294967296
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_max_syn_backlog = 1000
net.core.netdev_max_backlog = 1000
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_fin_timeout = 20
вот снимок состояния tcp сервера A в настройке A
604 TIME_WAIT
7 SYN_RECV
1 LISTEN
2 FIN_WAIT1
1 ESTABLISHED
1 CLOSING
Не совсем уверен, почему TIME_WAIT так велик (у меня есть entable tcp_tw_reuse и tcp_tw_recycle). Я также отслеживал статус tcp в настройке B, количество TIME_WAIT еще меньше (около 300-400)
для конфигурации apache:
KeepAlive Off
<IfModule prefork.c>
StartServers 5
MinSpareServers 10
MaxSpareServers 50
ServerLimit 500
MaxClients 500
MaxRequestsPerChild 4000
</IfModule>
Пожалуйста помоги. огромное спасибо
Вы пробовали свою настройку без tcp_tw_recycle и tcp_tw_reuse параметры? По крайней мере tcp_tw_recycle может вызвать проблемы с балансировщиками нагрузки.
Также количество розеток в TIME_WAIT state не должно быть проблемой, так как оно далеко не 30k, что является количеством портов по умолчанию, доступных в Linux.
Если вы хотите быть уверены, что доступно достаточно портов, вы можете установить net.ipv4.ip_local_port_range sysctl в 1024 65535.