On 06/27/13 14:45, Alexey Markov wrote:
Насколько я помню, состояние FIN_WAIT_1 - это когда приложение (nginx)
уже закрыло соединение через close(), система послала FIN клиенту, а в
ответ - тишина... В итоге, через некоторое время общее число соединений
упирается в системный лимит, и все остальные клиенты обламываются. :-(
Либо nginx послал FYN на бэкенд (ruby) и не получил ответ.
net.inet.tcp.nolocaltimewait случаем не используется? У него есть "особенности"
и проще будет его выключить.
Собственно, вопрос такой: будет ли ipfw считать соединения в состоянии
FIN_WAIT_1 как "всё ещё установленные", и тем самым можно ли ограничить
их число через limit src-addr <N>? И стоит ли в этом случае увеличить
сразу net.inet.ip.fw.dyn_max с дефолтных 8192?
ipfw в случае DoS ресурсов будет расходовать не меньше чем экономить, я
рекомендую его отключить совсем.
1. Нужно потюнить sysctl/tunables чтобы сервер мог обслуживать достаточное число
коннекций. Немножко про это есть тут:
http://webcrunch.ru/library/equipment/clusters/tuning-freebsd/
хотя часть из того. что там написано уже устарело, так что это больше следует
воспринимать не как готовый рецепт, а как подсказку, на что обратить внимание.
На одном из моих серверов такие настройки:
http://paste.org.ru/?mp3z7j (в nginx worker_processes*worker_connections*2
должно быть меньше kern.ipc.maxsockets).
2. Далее можно ограничивать число коннекций / запросов на проксируемые location
средствами nginx.
А какой объем RAM на сервере? 68628 сокетов это не так уже и много...
