Как уменьшить количество сокетов за TIME_WAIT?

Сервер Ubuntu 10.04.1 x86

У меня есть машина с HTTP-службой FCGI за nginx, которая обслуживает множество небольших HTTP-запросов множеству разных клиентов. (Около 230 запросов в секунду в часы пик, средний размер ответа с заголовками составляет 650 байт, несколько миллионов различных клиентов в день.)

В результате у меня много сокетов, зависших в TIME_WAIT (график снят с настройками TCP ниже):

Хочу уменьшить количество розеток.

Что еще я могу сделать?

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
1
$ cat /proc/sys/net/ipv4/tcp_tw_recycle
1
$ cat /proc/sys/net/ipv4/tcp_tw_reuse
1

Обновление: некоторые подробности о фактическом макете службы на машине:

client -----TCP-socket--> nginx (load balancer reverse proxy) 
       -----TCP-socket--> nginx (worker) 
       --domain-socket--> fcgi-software
                          --single-persistent-TCP-socket--> Redis
                          --single-persistent-TCP-socket--> MySQL (other machine)

Я, вероятно, также должен переключить балансировщик нагрузки -> рабочее соединение с сокетами домена, но проблема с сокетами TIME_WAIT останется - я планирую добавить второго рабочего на отдельной машине в ближайшее время. В этом случае невозможно будет использовать доменные сокеты.

Для начала вам следует исправить net.ipv4.tcp_fin_timeout=1. Это слишком низкий показатель, вам, вероятно, не стоит брать намного меньше 30.

Поскольку это стоит за nginx. Означает ли это, что nginx действует как обратный прокси? Если это так, то ваши соединения будут 2x (одно с клиентом, одно с вашими веб-серверами). Вы знаете, к какому концу относятся эти розетки?

Обновить:
fin_timeout - как долго они остаются в FIN-WAIT-2 (Из networking/ip-sysctl.txt в документации ядра):

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

Я думаю, вам, возможно, просто нужно позволить Linux поддерживать номер сокета TIME_WAIT против того, что похоже на ограничение на 32 КБ, и именно здесь Linux их перерабатывает. Этот 32k упоминается в этом ссылка на сайт:

Кроме того, я считаю, что / proc / sys / net / ipv4 / tcp_max_tw_buckets сбивает с толку. Хотя по умолчанию установлено значение 180000, я вижу сбой TCP, когда в моей системе 32 КБ сокетов TIME_WAIT, независимо от максимального количества сегментов tw.

Эта ссылка также предполагает, что состояние TIME_WAIT составляет 60 секунд и не может быть настроено с помощью процедуры.

Случайный забавный факт:
Вы можете увидеть таймеры на timewait с помощью netstat для каждого сокета с netstat -on | grep TIME_WAIT | less

Повторное использование против повторного использования:
Это довольно интересно, он читается как повторное использование включает повторное использование сокетов time_Wait, а recycle переводит его в режим TURBO:

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

Я бы не рекомендовал использовать net.ipv4.tcp_tw_recycle, поскольку это вызывает проблемы с клиентами NAT..

Может быть, вы могли бы попробовать не включать оба из них и посмотреть, какой эффект это имеет (попробуйте по одному и посмотрите, как они работают самостоятельно)? я хотел бы использовать netstat -n | grep TIME_WAIT | wc -l для более быстрой обратной связи, чем Munin.

tcp_tw_reuse относительно безопасен, поскольку позволяет повторно использовать соединения TIME_WAIT.

Также вы можете запустить больше сервисов, прослушивающих разные порты за балансировщиком нагрузки, если нехватка портов является проблемой.