web-dev-qa-db-ja.com

/ proc / net / nf_conntrackを読み取ると、/ proc / sys / net / netfilter / nf_conntrack_countが極端に低下します

私は非常に忙しいWebサーバーを持っているので、どのような種類のトラフィックが存在するかを確認するためにいくつかの分析を導入したいと思いました。つまり、すべての接続の総数、待機時間、確立された接続、udpおよびtcp接続。

まず、グラフを単純にしました。/proc/sys/net/netfilter/nf_conntrack_countを次のように読み取ることで、接続の総数のみを表示します。

$ cat /proc/sys/net/netfilter/nf_conntrack_count 1994

すべてがグラフにうまく表示されていたので、詳細をグラフに導入しました。同様のコマンドで/proc/net/nf_conntrackを処理し、適切な監視を行います。

$ grep -c tcp /proc/net/nf_conntrack 1273 $ grep -c udp /proc/net/nf_conntrack 49

Nf_conntrackのこの分析を毎分実行するようにしました。最初はすべてが正しく表示されていたので、1日放置しました。

翌日、接続数の合計（/proc/sys/net/netfilter/nf_conntrack_count）が大幅に低下し、再バウンスすることに気付きました。これは、数分ごとに発生するWebサーバーでは正常ではありませんでした。多くのテストとトラブルシューティングを行った後、私はついに謎の背後にある理由を特定しました。

ターミナルwatch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count"（ほぼリアルタイムの接続数をチェックインするため）を入力し、2番目にcat /proc/net/nf_conntrackのみを実行し、Enterキーを押すとすぐにnf_conntrack_count大幅に低下 1993年から1411年にかけて、2〜3秒で「通常の」値に戻りました。 cp、grep、conntrack -L -p tcpなどを試してみましたが、コマンドを実行するたびにこのドロップが発生しました。

基本的に、/proc/net/nf_conntrack-の読み取りが行われるたびに、一時的に/proc/sys/net/netfilter/nf_conntrack_countが低下し、監視によって低い値が選択されてグラフに表示されることがあります。

さらに、cat nf_conntrackとconntrack -Lの結果には大きな違いがあることに気づきました。また、nf_conntrackの行数はnf_conntrack_countとは異なります。カーネルはv4.19.5です。これらの2つのコマンドを使用すると、3秒間隔ですべてが表示されます。

[07:30:14] root@web1(~)$ wc -l /proc/net/nf_conntrack; \
                         cat /proc/sys/net/netfilter/nf_conntrack_count
1236 /proc/net/nf_conntrack
1575

[07:30:18] root@web1(~)$ cat /proc/sys/net/netfilter/nf_conntrack_count;\
                             wc -l /proc/net/nf_conntrack
2009
1191 /proc/net/nf_conntrack

私の質問は、ここで正確に何が起こっているのか、なぜこれが起こっているのか（ドロップ）、リストされたファイルに違いがあるのはなぜですか、そしてこのドロップを防ぐ方法は何ですか？

linuxtcpkernelconntrackproc
1
Victoria Javi

カーネル3.10.0-693.21.1.el7.x86_64でCentOS7.4.1708を実行している本番サーバーの1つでgrep -c tcp /proc/net/nf_conntrackとwatch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count"を使用して同じテストを実行しようとしましたが、同じものがあることを確認できません。あなたが直面している問題。

少なくともカーネルバージョンを送信してみてください。同じバージョンのサーバーを実行している誰かがそれをテストできるかもしれません。

何が起こっている可能性があるかという考えの1つは、grepの使用中にシステムメモリまたはCPUの制限に達し、nf_conntrackに影響を与えるということです。あなたはすなわち実行しようとすることができます。 Nice -n19 grep -c tcp /proc/net/nf_conntrackそして、ulimitsまたはcgroupsを使用してRAMをトロールします。別のアイデアは、問題の定義と組み合わせて、カーネルバージョンまたはnf_conntrackバージョンのグーグルを試すことです。バグの可能性がありますが、可能性は低いです。

1
patok

全体的に、それはあなたのカーネルバージョンとあなたが追跡している接続の数に依存すると思います。 IIRC、カーネルは/ proc/net/nf_conntrackを生成するためにいくつかのロックを取得する必要があります。これが、おそらく低下が見られる理由です。

より良い方法は、conntrackを使用して情報を取得し、同じ一連の問題に悩まされないnetlinkユーティリティを使用することです。

1
V13