Большое количество TIME_WAIT в Haproxy

Question

У нас есть haproxy 1.3.26, размещенный на процессоре CentOS 5.9 с процессором Intel Xeon с тактовой частотой 2,13 ГГц, который действует как балансировщик нагрузки tcp http 10 для множества сервисов, обеспечивая максимальную пропускную способность ~ 2000 запросов/секунду , Он работает отлично в течение 2 лет, но постепенно увеличивается количество трафика и количество услуг.

В конце мы заметили, что даже после перезагрузки старый процесс гапрокси остается. В ходе дальнейшего исследования мы обнаружили, что старый процесс имеет многочисленные связи в состоянии TIME_WAIT. Мы также видели, что netstat и lsof занимали много времени. При обращении http://agiletesting.blogspot.in/2013/07/the-mystery-of-stale-haproxy-processes.html мы представили option forceclose, но он испортил различные службы мониторинга и, следовательно, вернул его. При дальнейшем копания мы поняли, что в /proc/net/sockstat близко к 200K сокеты в tw (TIME_WAIT) состояние, которое вызывает удивление, как в /etc/haproxy/haproxy.cfgmaxconn был определен как 31000 и ulimit-n, как 64000. Мы были timeout server и timeout client, как 300s, который мы изменили на 30s, но не много использование.

Теперь сомнения: -

• ли такое большое количество TIME_WAITs является приемлемым. Если да, то какой номер, после которого мы должны волноваться. Глядя на What is the cost of many TIME_WAIT on the server side? и Setting TIME_WAIT TCP, похоже, не должно быть никаких проблем.
• Как уменьшить этот TIME_WAITs
• Существует ли какая-либо альтернатива NetStat и LSOF, которые будет выполнять хорошо, даже если Есть очень большого количество TIME_WAITs

Answer 1

Примечание: Кавычки в этом ответе все из a mail by Willy Tarreau (главный автор HAProxy) в список рассылки HAProxy.

Соединения в TIME_WAIT состоянии безвредны и больше не потребляют никаких ресурсов. Они сохраняются ядром на сервере в течение некоторого времени для редкого события, когда он все еще получает пакет после закрытия соединения. По умолчанию время закрытого соединения сохраняется в этом состоянии, как правило, 120 секунд (или в 2 раза больше максимального срока службы сегмента)

TIME_WAIT безвредны на стороне сервера. Вы можете легко достичь миллионов без каких-либо проблем.

Если вы все еще хотите уменьшить это число, чтобы освободить соединения ранее, вы можете дать указание ядру сделать это. Напр. установить его на 30 секунд выполнить это:

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout 

Если у вас есть много соединений (либо в TIME_WAIT или нет), netstat, lsof, ipcs выполняют очень плохо и на самом деле замедлить всю систему.Для того, чтобы еще раз процитировать Вилли:

Есть две команды, которые вы должны абсолютно никогда не использовать в системе мониторинга :

• netstat -a
• ipcs -a

Обе они насыщают и значительно замедлить его, когда что-то начинает не так. Для сокетов вы должны использовать то, что находится в /proc/net/sockstat. У вас есть все номера, которые вы хотите. Если вам нужно больше , используйте ss -a вместо netstat -a, он использует интерфейс netlink и на несколько порядков быстрее.

В системах Debian и Ubuntu, ss доступен в пакете iproute или iproute2 (в зависимости от версии дистрибутива).