Нещодавно у нас був сервер 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.
Вінко Врсалович повідомив мені, що це означає, що відставання синхронізації заповнюється, тому я підвищив 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і відключив синкокі sysctl -w net.ipv4.tcp_syncookies=0.
Після цього кількість з'єднань у стані SYN_RECV все ще залишалася близько 220-250, але з'єднання знову починали затримуватися. Як тільки я помітив ці затримки, я знову включив синкокі, і затримки припинилися.
Я вважаю, що те, що я бачив, все ще покращився від початкового стану, проте деякі запити все ще були відкладені, що значно гірше, ніж увімкнено синхрокіаки. Так виглядає, що я затримався з ними, доки ми не зможемо отримати ще кілька серверів в Інтернеті, щоб впоратися з навантаженням. Навіть тоді я не впевнений, що бачу поважну причину відключити їх знову, оскільки вони надсилаються (мабуть) лише тоді, коли буфери сервера заповнюються.
Але, схоже, що відставання синхронізації не заповнене лише ~ 250 підключеннями в стані SYN_RECV! Чи можливо, що повідомлення про затоплення SYN - це червона оселедець, і це щось інше, ніж заповнення syn_backlog?
Якщо у когось є якісь інші налаштування, я ще не пробував, я був би більш ніж радий спробувати їх, але я починаю цікавитись, чи налаштування syn_backlog чомусь не застосовується належним чином.