Изучая жалобы на плохую производительность HTTP-сервера, я обнаружил эти строки в dmesg моего хоста Xen XCP, который содержит гостевую ОС с указанным сервером:
[11458852.811070] net_ratelimit: 321 callbacks suppressed [11458852.811075] nf_conntrack: table full, dropping packet. [11458852.819957] nf_conntrack: table full, dropping packet. [11458852.821083] nf_conntrack: table full, dropping packet. [11458852.822195] nf_conntrack: table full, dropping packet. [11458852.824987] nf_conntrack: table full, dropping packet. [11458852.825298] nf_conntrack: table full, dropping packet. [11458852.825891] nf_conntrack: table full, dropping packet. [11458852.826225] nf_conntrack: table full, dropping packet. [11458852.826234] nf_conntrack: table full, dropping packet. [11458852.826814] nf_conntrack: table full, dropping packet.
Жалобы повторяются каждые пять секунд (количество подавленных обратных вызовов каждый раз разное).
Что могут означать эти симптомы? Это плохо? Есть подсказки?
(Обратите внимание, что вопрос более узкий, чем «как решить конкретный случай плохой производительности HTTP-сервера», поэтому я не буду вдаваться в подробности по этому поводу.)
Дополнительная информация:
$ uname -a Linux MYHOST 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04 LTS Release: 12.04 Codename: precise $ cat /proc/sys/net/netfilter/nf_conntrack_max 1548576
Нагрузка на сервер составляет около 10 миллионов обращений в день.
Обновить:
iptables на Dom0:
$ iptables -L -t nat -v Chain PREROUTING (policy ACCEPT 23155 packets, 1390K bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 9 packets, 720 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 27 packets, 1780 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 23173 packets, 1392K bytes) pkts bytes target prot opt in out source destination $ iptables -L -v Chain INPUT (policy ACCEPT 13976 packets, 1015K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 241K packets, 24M bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 13946 packets, 1119K bytes) pkts bytes target prot opt in out source destination
iptables на одном из DomU:
$ iptables -L -t nat -v Chain PREROUTING (policy ACCEPT 53465 packets, 2825K bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 53466 packets, 2825K bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 51527 packets, 3091K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 51527 packets, 3091K bytes) pkts bytes target prot opt in out source destination $ iptables -L -v Chain INPUT (policy ACCEPT 539K packets, 108M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 459K packets, 116M bytes) pkts bytes target prot opt in out source destination
Мне было немного интересно узнать об этом, и я нашел довольно хорошее объяснение вашим симптомам. Они хорошо описаны в nf_conntrack: table full - как отсутствие правил может привести к неожиданному поведению.
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, что полностью устраняет проблему.