Недавно у нас был сервер Apache, который очень медленно реагировал из-за переполнения SYN. Обходной путь для этого должен был включить tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf).
Я разместил вопрос об этом здесь, если вы хотите больше информации.
После включения syncookies мы начали видеть следующее сообщение в / var / log / messages примерно каждые 60 секунд:
[84440.731929] possible SYN flooding on port 80. Sending cookies.
Vinko Vrsalovic сообщил мне, что это означает, что synlog backlog заполняется, поэтому я поднял tcp_max_syn_backlog до 4096. В какой-то момент я также снизил tcp_synack_retries до 3 (по умолчанию 5), выдав sysctl -w net.ipv4.tcp_synack_retries=3. После этого частота, казалось, упала, а интервал сообщений варьировался примерно от 60 до 180 секунд.
Затем я выпустил sysctl -w net.ipv4.tcp_max_syn_backlog=65536, но все еще получаю сообщение в журнале.
На протяжении всего этого я наблюдал за количеством соединений в состоянии SYN_RECV (при запуске watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), и оно никогда не поднималось выше, чем около 240, что намного меньше, чем размер отставания. Тем не менее у меня есть сервер Red Hat, который колеблется около 512 (ограничение на этом сервере по умолчанию 1024).
Существуют ли какие-либо другие настройки tcp, которые ограничивают размер задела, или я лаю не на том дереве? Должно ли количество соединений SYN_RECV netstat -tunaсоответствовать размеру отставания?
Обновить
Насколько я могу судить, я имею здесь дело с законными связями, netstat -tuna|wc -lколеблется около 5000. Я исследовал это сегодня и нашел этот пост от сотрудника last.fm, который был довольно полезен.
Я также обнаружил, что tcp_max_syn_backlog не имеет никакого эффекта, когда включены синхронизаторы (по этой ссылке )
В качестве следующего шага я установил следующее в sysctl.conf:
net.ipv4.tcp_syn_retries = 3
# default=5
net.ipv4.tcp_synack_retries = 3
# default=5
net.ipv4.tcp_max_syn_backlog = 65536
# default=1024
net.core.wmem_max = 8388608
# default=124928
net.core.rmem_max = 8388608
# default=131071
net.core.somaxconn = 512
# default = 128
net.core.optmem_max = 81920
# default = 20480
Затем я настроил свой тест времени отклика, запустил sysctl -pи отключил syncookies sysctl -w net.ipv4.tcp_syncookies=0.
После этого количество соединений в состоянии SYN_RECV по-прежнему оставалось около 220-250, но соединения снова начинали задерживаться. Как только я заметил эти задержки, я снова включил syncookies, и задержки прекратились.
Я считаю, что то, что я видел, все еще улучшало исходное состояние, однако некоторые запросы все еще задерживались, что намного хуже, чем включение syncookies. Похоже, я застрял с ними, пока мы не подключим еще несколько серверов, чтобы справиться с нагрузкой. Даже тогда, я не уверен, что вижу вескую причину, чтобы отключить их снова, поскольку они отправляются (очевидно), когда буферы сервера переполняются.
Но, похоже, что отставание в синхронизации не заполнено всего лишь ~ 250 соединениями в состоянии SYN_RECV! Возможно ли, что сообщение о затоплении SYN - это красная сельдь, а это не что иное, как syn_backlog, который заполняет?
Если у кого-то есть какие-либо другие параметры настройки, которые я еще не пробовал, я был бы более чем счастлив попробовать их, но я начинаю удивляться, если параметр syn_backlog по какой-то причине не применяется должным образом.