Nightbook

timewait соединений и file descriptors

Уже длительный промежуток времени я размышляю о полезности использования параметров net.ipv4.tcp_tw_recycle и net.ipv4.tcp_tw_reuse. Подробности о них и их влиянии можно найти в интернете. Сегодня, я так думаю, я окончательно сформировал свое мнение о этих параметрах.
На Linux-системах, которые обслуживают большое количество соединений в секунду по сети, возникают постоянные проблемы с ограничениями по количеству открытых файлов. И что уже не делают. И поднимают значение максимального количества дескрипторов в системе fs.file-max (должно соответствовать объему оперативной памяти), то пытаются увеличивать количество дескрипторов на конкретные процессы и системных пользователей.

Сначала стоит понять сколько и какие именно дескрипторы использует процесс.

Проверить это можно командой lsof или даже ls.

lsof -p PID | wc -l
ls -1 /proc/PID/fd | wc -l

PID - это pid вашего процесса
там же можно и посчитать дескрипторы по типам
И если это оказались именно сетевые соединения (ага они в файловых дескрипторах, так как в линупсе все файлы), то следует определить их состояние
Все это лирика. Можно и системными утилитами определить проблему для которой решением могут стать net.ipv4.tcp_tw_recycle и net.ipv4.tcp_tw_reuse. Но чаще всего вы заметите ее со стороны приложения. Это будут исключения вида "too many open files".

Общая диагностика системы

На примере вывода утилиты ss будет видно "узкое место":

ss -s

результат

Total: 354 (kernel 696)
TCP:   36316 (estab 278, closed 36029, orphaned 0, synrecv 0, timewait 36027/0), ports 0

Transport Total     IP        IPv6
*       696       -         -        
RAW     0         0         0        
UDP     13        9         4        
TCP     287       285       2        
INET    300       294       6        
FRAG    0         0         0

А именно большое количество соединений в состоянии timewait . Прикольные цифры, если учесть ограничения на использования сетевых портов:

cat /proc/sys/net/ipv4/ip_local_port_range

результат

1025    65535

1025 - верхний порог, так как порты до 1024, включительно, может использовать только приложения суперпользователя.
теперь прикинем что всего нам доступно 64510 портов. При том что используются 36316. Половина наших процессов используется!!! Это плохо? Да нет. Вот только тот факт что они все ждут 2 минуты до закрытия!!!

Вывод

net.ipv4.tcp_tw_recycle и net.ipv4.tcp_tw_reuse помогают избежать этого состояния и более эффективно использовать имеющиеся порты, но есть и обратные стороны медали. Собственно меня это и смущало. Общее правило, которое я сегодня для себя вывел, использовать эти параметры можно спокойно если на этом узле выполняется только то приложение для которого задуман весь этот тюнинг.