web-dev-qa-db-ja.com

dmesgのnf_conntrackの苦情

HTTPサーバーのパフォーマンスが悪いという苦情を調査し​​ているときに、XenXCPホストのdmesgで次の行を発見しました。

 [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.826814] nf_conntrack：テーブルがいっぱいで、パケットをドロップしています。

苦情は5秒ごとに繰り返されます（抑制されるコールバックの数は毎回異なります）。

これらの症状はどういう意味ですか？それは悪いですか？ヒントはありますか？

（質問は「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 
使用可能なLSBモジュールはありません。
ディストリビューターID：Ubuntu 
説明：Ubuntu 12.04 LTS 
リリース：12.04 
コード名：exact 
 
 $ cat/proc/sys/net/netfilter/nf_conntrack_max
1548576

サーバーのヒット数は約1,000万回/日です。

更新：

dom0のiptables：

 $ iptables -L -t nat -v 
 Chain PREROUTING（policy ACCEPT 23155 packet、1390K bytes）
 pkts bytes target prot opt in out source destination 
 
 Chain INPUT（ポリシーACCEPT 9パケット、720バイト）
 pktsバイトtargetprot opt in out source destination 
 
 Chain OUTPUT（ポリシーACCEPT 27パケット、1780バイト） 
 pkts bytes target prot opt in out source destination 
 
 Chain POSTROUTING（policy ACCEPT 23173 packet、1392K bytes）
 pkts bytes target prot opt in out source destination 
 
 .____。] 
 $ iptables -L -v 
 Chain INPUT（policy ACCEPT 13976 packet、1015K bytes）
 pkts bytes target prot opt in out source destination 
 
 Chain FORWARD（ポリシーACCEPT 241Kパケット、24Mバイト）
 pktsバイトターゲットprotオプトインアウトソース宛先
 
チェーン出力（ポリシーACCEPT 13946パケット、1119Kバイト）
 pktsバイトターゲットprotオプトインソース宛先

domUの1つにあるiptables：

 $ iptables -L -t nat -v 
 Chain PREROUTING（policy ACCEPT 53465 packet、2825K bytes）
 pkts bytes target prot opt in out source destination 
 
 Chain INPUT（ポリシーACCEPT 53466パケット、2825Kバイト）
 pktsバイトターゲットprotオプトインソース宛先
 
 Chain OUTPUT（ポリシーACCEPT 51527パケット、3091Kバイト） 
 pkts bytes target prot opt in out source destination 
 
 Chain POSTROUTING（policy ACCEPT 51527 packet、3091K bytes）
 pkts bytes target prot opt in out source destination 
 .____。] 
 $ iptables -L -v 
 Chain INPUT（policy ACCEPT 539K packet、108M bytes）
 pkts bytes target prot opt in out source destination 
 
 Chain FORWARD（ポリシーACCEPT 0パケット、0バイト）
 pktsバイトターゲットprotオプトインアウトsou rce destination 
 
 Chain OUTPUT（policy ACCEPT 459K packet、116M bytes）
 pkts bytes target prot opt in out source destination
ubuntudmesgxennf-conntrack
3
Alexander Gladysh

私はこれについて少し興味があり、あなたの症状についてかなり良い説明を見つけました。それらは nf_conntrack：table full-ルールがないと予期しない動作につながる可能性がある で詳しく説明されています。

TL; DR：iptables -t nat -vnLを実行するだけで、nf_conntrackモジュールのロードが開始され、意図しないステートフルファイアウォールが発生します。私はまだこれを自分で確認していません、あなたは私が明日仕事でそれを正しくすることは間違いありません。

解決策：NATとにかくブリッジングを行っているために必要ない場合は、nf_conntrack_*モジュールとそれらに依存する他のすべての依存モジュールをアンロードします。chkconfig ip[6]tables offを介してファイアウォールを完全に無効にすることをお勧めします、も。

Ubuntuでファイアウォールを無効にするには、Sudo ufw disableを実行し、再起動したくない場合は これらの手順 を実行します。

4
Alexander Janssen

XenはdomUサーバーへの接続をNATしている必要があり、接続の数が非常に多いため、カーネルがそれらを追跡する機能を圧倒しています。 nf_conntrack_maxを増やすことで接続の追跡に割り当てられるスペースを増やすことはできますが、NATの代わりに ブリッジネットワーク を使用したほうがよいでしょう。このようにして、domUサーバーは独自の仮想イーサネットカードを取得し、問題を完全に回避します。

3
200_success