Ошибка сети с 65k соединений TIME_WAIT
На прошлой неделе у нас были проблемы с одним из наших серверов изображений, и нам нужна помощь. Смотрите наш график мониторинга Мунина:
Мы запускаем debian squeeze и у нас много запросов, потому что это один из наших серверов изображений. Мы не используем keep-alive (возможно, нам следует, но это уже другая тема)
Эти числа являются количеством запросов в минуту из наших файлов журнала:
- 17:19: 66516
- 17:20: 64627
- 17:21: 123365
- 17:22: 111207
- 17:23: 58257
- 17:24: 17710
- ... и так далее
Итак, вы видите, у нас много запросов в минуту, но так как большая часть запросов обрабатывается в 0-1мс, все обычно работает нормально.
Теперь, как вы видите на нашем рисунке munin, munin не удалось подключиться к этому серверу через порт munin и запросить соответствующие номера. Соединение просто не удалось. Поскольку сервер не перегружен никакими средствами (процессор, память, сеть). он должен иметь какое-то отношение к нашему стеку firewall/tcp. В то время, когда плагин munin не мог подключиться, у нас было только 17 Мбит входящего и исходящего трафика на 100 Мбит соединения.
Вы часто здесь ограничиваете 65 тыс. соединений tcp, но это обычно вводит в заблуждение, поскольку относится к 16-битному заголовку tcp и относится к 65 тыс. на комбинацию ip/port.
наш тайм-аут time_wait установлен в
net.ipv4.tcp_fin_timeout = 60
мы могли бы уменьшить это, чтобы сбросить больше соединений TIME_WAIT ранее, но сначала я хочу знать, что ограничивает доступность сети.
мы используем iptables с модулем состояния. Но мы уже подняли параметр max_conntrack.
net.ipv4.netfilter.ip_conntrack_max = 524288
Кто-нибудь знает, какие параметры ядра нужно посмотреть или как диагностировать эту проблему на следующей неделе, когда у нас будет следующий обзор?
2 ответа
Хорошо, я нашел ответ сам. Плагин munin работает довольно медленно и достигает своего значения тайм-аута. если таблица conntrack заполнена, чтение из /proc/net/ip_conntrack происходит очень-очень медленно. сервер, кажется, реагирует, а плагин munin - нет.
FIN_WAIT (таймаут для подтверждения запроса FIN) не совпадает с TIME_WAIT (время, чтобы убедиться, что сокет действительно больше не используется). И да, с 65 тыс. Портов в состоянии TIME_WAIT у вас не хватит TCP-портов, если вы используете один IP -адрес запрашивающего - как может быть, если все ваши клиенты находятся за устройством NAT. Вы также можете использовать ресурсы из-за переполненной таблицы блоков управления передачей - посмотрите это превосходно, даже если несколько устарела статья о возможных последствиях производительности.
Если вы действительно беспокоитесь о своих сокетах в состоянии TIME_WAIT и не имеете межсетевых экранов с контролем состояния между вашими клиентами и вашим сервером, вы можете подумать о настройке /proc/sys/net/ipv4/tcp_tw_recycle, но вы бы пожертвовали соответствием RFC и могли бы иметь интересную сторону -эффекты в будущем из-за этого вопроса.