Назад | Перейти на главную страницу

Сетевая ошибка с 65k подключений TIME_WAIT

На прошлой неделе у нас возникли проблемы с одним из наших серверов изображений, и нам нужна помощь. Смотрите наш график мониторинга munin:

Мы запускаем debian squeeze, и у нас много запросов, потому что это один из наших серверов образов. Мы не используем keep-alive (может, стоит, но это уже другая тема)

Эти числа представляют собой количество запросов в минуту из наших файлов журнала:

Как видите, у нас много запросов в минуту, но поскольку большинство запросов обслуживаются за 0–1 мс, обычно все работает нормально.

Теперь, как вы видите в нашем графике munin, munin не смог подключиться к этому серверу через порт munin и запросить соответствующие номера. Соединение просто не удалось. Поскольку сервер никаким образом не перегружен (процессор, память, сеть). он должен иметь какое-то отношение к нашему стеку firewall / tcp. В то время, когда плагин munin не смог подключиться, у нас было только 17 Мбит входящего и исходящего трафика на 100 Мбит соединение.

вы часто здесь ограничиваете 65 КБ TCP-соединений, но обычно это вводит в заблуждение, поскольку он относится к 16-битному заголовку TCP и относится к 65 КБ на комбинацию IP / порта.

наш тайм-аут time_wait установлен на 

 net.ipv4.tcp_fin_timeout = 60

мы могли бы уменьшить это значение, чтобы раньше терять больше соединений TIME_WAIT, но сначала я хочу знать, что ограничивает доступность сети.

мы используем iptables с модулем состояния. Но мы уже подняли параметр max_conntrack.

 net.ipv4.netfilter.ip_conntrack_max = 524288

Кто-нибудь знает, на какие параметры ядра смотреть или как диагностировать эту проблему на следующей неделе, когда у нас будет следующий обзор?

Хорошо, я сам нашел ответ. Плагин munin работает довольно медленно и достигает своего собственного значения тайм-аута. если таблица conntrack заполнена, чтение из / proc / net / ip_conntrack будет очень медленным. сервер кажется отзывчивым, а плагин munin - нет.

FIN_WAIT (тайм-аут для подтверждения запроса FIN) не то же самое, что TIME_WAIT (время, чтобы убедиться, что сокет действительно больше не используется). И да, с портами 65k в состоянии TIME_WAIT у вас будут исчерпываться порты TCP, только если вы используете один IP-адрес запрашивающей стороны - как это может иметь место, если все ваши клиенты находятся за устройством NAT. У вас также могут быть ресурсы из-за чрезмерно заполненной таблицы блоков управления передачей - см. эта отличная, даже если несколько устаревшая бумага для возможных последствий для производительности.

Если вас действительно беспокоят ваши сокеты в состоянии TIME_WAIT и у вас нет межсетевых экранов с отслеживанием состояния между вашими клиентами и вашим сервером, вы можете подумать о настройке / proc / sys / net / ipv4 / tcp_tw_recycle, но вы пожертвуете соответствием RFC и, возможно, получите интересную сторону -эффекты в будущем из-за этого.