Настройка сервера под высокую нагрузку

Есть, прямо в мейллисте в ветке анонса 1.1.12. Вроде уже решили откатить.

В основе механизма синкуков лежит, то что когда очередь полуоткрытых соединений заполнена, новые соединения не ставятся в очередь, а сервер в своем ответе SYN+ACK в 32-битном поле TCP заголовка Sequence number указывает число вычисленное по определенному алгоритму и только клиент с настоящим IP получает пакет SYN+ACK и отвечает правильным пакетом ACK.

На википедии довольно ясно описан алгоритм работы синкуков

http://en.wikipedia.org/wiki/SYN_cookies

там пишется о трех возможных проблемах, которые он вызывает.

1. First, the server is limited to only 8 unique MSS values, as that's all that can be encoded in 3 bits.

2. Second, the server must reject all TCP options (such as large windows), because the server discards the SYN queue entry where that information would otherwise be stored.

3. Third, a connection may freeze when the final ACK of the three-way handshake is lost and the client first awaits data from the server

Также там пишется, что эти ограничения возникают лишь во время атаки, а пока атаки нет (Очередь соединений не заполнена) механизм синкуки не используется.

Furthermore, these restrictions need only apply when the server is under attack, and the connection would have otherwise been denied. In such a situation, the loss of a few of the more esoteric options in order to save the connection is usually a reasonable compromise.

Я не вижу аргументов, почему синкуки нужно выключать, когда нет атаки.

Кто то может такие аргументы привести?

если вы пропишете единичку, то син-куки не включатся пока не будет атаки. порог включения-выключения определяется другим параметром (не помню напамять). поэтому имеет смысл говорить только о случае когда атака идет.

или я не понял ваш вопрос.

Мой вопрос в том чем опасно включение сикуков

echo '1'>/proc/sys/net/ipv4/tcp_syncookies

Для высоконагруженного сервера, который иногда ддосят. (Раз в месяц)

Сервер обслуживает несколько миллионов запросов в сутки.

Синкуки у меня всегда включены и проблем с подключением я не замечал.

В логах были единичные строки

kernel: [1745232.115484] possible SYN flooding on port 80. Sending cookies.

Но они единичны.

А после того как я увеличил длину очереди полуоткрытых соединений, таких сообщений стало еще меньше.

echo '4096' >/proc/sys/net/ipv4/tcp_max_syn_backlog

Не знаю почему, но 25000 онлайн тремя апачевскими процессами не обслужить хоть убейся. Значит, было их не три, вот и всё :)

Я вообще не понимаю дальнейшего обсуждения про всякие синкуки и подобное. Если первая страница открывается с тормозами, а последующие быстро и keepalive не при чём, то это проблема другого характера.

backlog действительно по умолчанию низкий для нагруженных серверов, даже без всяких атак, так что увеличивайте. возможно стОит увеличить порог срабатывания син-куков, т.к. вы увеличили очередь.

минус лично я вижу только один - если у вас почтовый сервер, то возможна ситуация когда почтовый клиент повиснет при попытке забрать почту во время атаки. самого сервера это никак не коснется. ну или ssh - тоже есть отличная от нуля вероятность что повесится при коннекте.

про другие минусы может быть madoff расскажет.

А он уже смирился с тем, что в дебьяне на выбор только два варианта. Или допотопная версия или сырая. Баланса нет, увы. Слишком медленный процесс.

Тем не менее было порядка 3 процессов, ну может иногда - 4. Мои слова может подтвердить сотрудник системинтегры (не знаю смотрел ли он в сервер-статус, но по крайней мере он был на сервере под рутом и видел нагрузку - она не была какой-то чрезмерной).

На каждого нового посетителя приходится ещё ~55-57 дополнительных запросов которые nginx обрататывает самостоятельно (картинки, js, css - да согласен, много. Картинки всё никак не соберусь в спрайты объединить), но все они должны кэшироваться на стороне клиента (в конфиг nginx'а вручную вписал expires). Получается, что общее число запросов к серверу перевалило за 60 млн, что вроде бы не так уж и мало и, подозреваю, кем-то уже может быть названо "ddos атакой".

Сервер подключен к 100мбитному каналу (не гарантированному), но обычно все 100мбит доступны (по крайней мере сколько я не проверял - 11мбайт/с получалось и качать и отдавать). 31 числа не догадался проверить :( может быть кто-то из соседей тоже трафик как и я генерировал (мой сервер на пике отдавал примерно 45-50мбит/с)

Для справки прикладываю картинку нагрузки на сайт от Яндекс.Метрики. Тревогу я забил примерно в 16 часов когда увидел, что график числа запросов стал рваным. И сразу обнаружил недоступность сайта из некоторых точек в хост-трекере и пинг-админе. Забыл сказать, тогда же я проверил на доступность соседний IP из тойже подсети что и мой сервер - там с доступностью проблем не было (понятно, что он может быть совсем в другом сегменте ДЦ, но скорее всего стоит рядом и подключен к тому же сетевому оборудованию).

Другого - это какого? Я ещё в первом посте очень просил подсказать в каком направлении можно пофантазировать :)

какое значение startservers и т.д.?

Апач работает под prefork.

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxClients 150

MaxRequestsPerChild 0

Обычно (что сейчас, что тогда) - рабочими висят те самые 10 процессов. Только если сейчас 9 idle, то 31 декабря бездействовали 7.