Як зменшити кількість розеток у TIME_WAIT?

Ubuntu Server 10.04.1 x86

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

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

TIME_WAIT

Я хотів би зменшити кількість розеток.

Що я можу зробити, крім цього?

$ 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 (зворотний проксі-сервер балансира завантаження) 
       ----- TCP-socket -> nginx (працівник) 
       --domain-socket -> fcgi-програмне забезпечення
                          --sele-persistent-TCP-socket -> Redis
                          --sele-persistent-TCP-socket -> MySQL (інша машина)

Я, мабуть, повинен переключити підключення навантаження-балансира -> до сокетів домену, але проблема щодо 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 порівняно з тим, що виглядає як, можливо, 32k кришка на них, і ось тут Linux переробляє їх. На це 32 к. Посилається на це посилання :

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

Це посилання також говорить про те, що стан TIME_WAIT становить 60 секунд і не може бути налаштований через proc.

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

Повторне використання Vs Recycle:
Це щось цікаве, воно звучить як повторне ввімкнення повторного використання розеток time_Wat, і переробка переводить його в режим 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для швидшого зворотного зв'язку, ніж Мунін.

— Кайл Брандт
джерело

@Kyle: яке значення net.ipv4.tcp_fin_timeoutви б рекомендували?

— Олександр Гладиш

@Kyle: клієнт --TCP-сокет -> nginx (зворотний проксі-сервер балансира завантаження) - TCP-сокет -> nginx (працівник) - домен-сокет -> fcgi-програмне забезпечення

— Олександр Гладиш

Я б сказав , 30чи , може бути 20. Спробуйте і подивіться. У вас багато навантаження, тому багато TIME_WAIT має сенс.

— Кайл Брандт

@Kyle: вибачте за дурне питання (я на рівні вантажопасажирські культовий тут до сих пір, на жаль), але то , що саме я повинен очікувати, що при зміні net.ipv4.tcp_fin_timeoutвід 1до 20?

— Олександр Гладиш

О, це хороший один лайнер: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c. Тож @ Алекс, якщо Муніну не подобається, можливо, вивчить, як він стежить за цією статистикою. Можливо, єдине питання полягає в тому, що Мунін надає вам погані дані :-)

— Кайл Брандт

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

Крім того, ви можете запустити більше служб, слухаючи різні порти за вашим балансиром навантаження, якщо вичерпання портів є проблемою.

— andrew паштет
джерело