nf_conntrack жалобы в dmesg
Исследуя жалобы на плохую производительность HTTP-сервера, я обнаружил эти строки в dmesg моего хоста Xen XCP, который содержит гостевую ОС с указанным сервером:
[11458852.811070] net_ratelimit: 321 обратный вызов подавлен [11458852.811075] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.819957] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.821083] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.822195] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.824987] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.825298] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.825891] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.826225] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.826234] nf_conntrack: таблица заполнена, отбрасываемый пакет. [11458852.826814] nf_conntrack: таблица заполнена, отбрасываемый пакет.
Жалобы повторяются каждые пять секунд (количество подавленных обратных вызовов каждый раз отличается).
Что могут означать эти симптомы? Это плохо? Есть намеки?
(Обратите внимание, что вопрос более узкий, чем "как решить конкретный случай плохой производительности HTTP-сервера", поэтому я не буду вдаваться в подробности).
Дополнительная информация:
$ uname -a Linux MYHOST 3.2.0-24-generiC#37-Ubuntu SMP Ср 25 апреля 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux $ lsb_release -a Модули LSB не доступны. Идентификатор распространителя: Ubuntu Описание: Ubuntu 12.04 LTS Релиз: 12.04 Кодовое имя: точный $ cat /proc/sys/net/netfilter/nf_conntrack_max 1548576
Сервер находится под нагрузкой около 10 миллионов обращений в день.
Обновить:
iptables на Dom0:
$ iptables -L -t nat -v Цепочка PREROUTING (политика ACCEPT 23155 пакетов, 1390K байт) pkts байтов целевой протокольный вход в исходной цепи назначения INPUT (политика ACCEPT 9 пакетов, 720 байт) pkts байтов целевой прототип в выходной исходной цепи назначения OUTPUT (политика ACCEPT 27 пакетов, 1780 байт) pkts bytes target prot opt in out источника назначения Цепочка POSTROUTING (policy ACCEPT 23173 пакета, 1392K байтов) pkts bytes target prot opt in out источника назначения $ iptables -L -v Chain INPUT (политика ACCEPT 13976 пакетов, 1015K байт) pkts байт целевой протокол в исходном источнике Цепь FORWARD (политика ACCEPT 241K пакетов, 24M байт) pkts байт целевой протокол в исходном источнике Chain OUTPUT (политика ACCEPT 13946 пакетов, 1119K байт) pkts байт целевой протокол выбрать источник назначения
iptables на одном из DomU:
$ iptables -L -t nat -v Цепное ПРЕДУПРЕЖДЕНИЕ (политика ПРИНИМАЕТ 53465 пакетов, 2825 КБ) pkts bytes target prot opt in out source source Цепной ВХОД (политика ПРИНЯТЬ 53466 пакетов, 2825 КБ) pkts bytes target prot opt in out source source Цепной ВЫХОД (политика ПРИНИМАЕТ 51527 пакетов, 3091 КБ) pkts bytes target prot opt in out source source Цепная POSTROUTING (политика ACCEPT 51527 пакетов, 3091 Кбайт) pkts bytes target prot opt in out source source $ iptables -L -v Цепной ВХОД (политика ПРИНЯТЬ 539 КБ пакетов, 108 МБ) pkts bytes target prot opt in out source source Цепочка FORWARD (политика ACCEPT 0 пакетов, 0 байт) pkts bytes target prot opt in out source source Цепной ВЫХОД (политика ПРИНИМАЕТ 459 КБ пакетов, 116 МБ) pkts bytes target prot opt in out source source
2 ответа
Я немного заинтересовался этим и нашел довольно хорошее объяснение ваших симптомов. Они хорошо описаны в nf_conntrack: таблица заполнена - как отсутствие правил может привести к неожиданному поведению.
TL; DR: просто работает iptables -t nat -vnL начинает загрузку nf_conntrack модуль, в результате чего получается непреднамеренное состояние межсетевого экрана. Я еще не проверил это сам, можешь поспорить, я сделаю это прямо завтра на работе.
Решение: Если вам не нужен NAT, потому что вы все равно используете мосты, выгрузите nf_conntrack_* модули и все другие зависимые модули, которые зависят от тех. Отключение межсетевого экрана через chkconfig ip[6]tables off было бы хорошей идеей тоже.
Отключение брандмауэра в Ubuntu может быть сделано sudo ufw disable и следуйте этим инструкциям, если вы не хотите перезагружаться.
Xen должен быть NAT-соединениями с вашим сервером domU, а само количество соединений подавляет способность ядра отслеживать их. Хотя вы можете увеличить пространство, выделяемое для отслеживания соединений, увеличив nf_conntrack_max, вам, вероятно, было бы лучше использовать мостовую сеть вместо NAT. Таким образом, сервер domU получает собственную виртуальную карту Ethernet, что полностью исключает проблему.