ビジーなインターフェイスでtcpdumpingを実行すると、多くのドロップされたパッケージ


11

私の挑戦

大量のデータのtcpdumpを実行する必要があります。実際には、多くのトラフィックを見ることができる無差別モードのままの2つのインターフェースからです。

まとめると

  • 2つのインターフェイスからの無差別モードのすべてのトラフィックを記録します
  • これらのインターフェイスにはIPアドレスが割り当てられていません
  • pcapファイルは〜1Gごとにローテーションする必要があります
  • 10 TBのファイルが保存されたら、最も古いファイルの切り捨てを開始します

私が現在していること

現在、私は次のようにtcpdumpを使用しています。

ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER

$FILTERはsrc / dstフィルターが含まれているため、を使用できます-i any。この理由は、2つのインターフェイスがあり、2つではなく1つのスレッドでダンプを実行したいからです。

compress.sh tarを別のCPUコアに割り当て、データを圧縮し、適切なファイル名を付けて、アーカイブの場所に移動します。

2つのインターフェイスを指定できないため、フィルターを使用してanyインターフェイスからダンプすることを選択しました。

現在、私はハウスキーピングを行いませんが、ディスクの監視を計画しており、100Gが残っているときに最も古いファイルの消去を開始します-これで問題ありません。

そしていま; 私の問題

ドロップされたパケットが表示されます。これは、数時間実行され、およそ250ギガバイトのpcapファイルを収集したダンプからのものです。

430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel  <-- This is my concern

多数のパケットがドロップされるのを回避するにはどうすればよいですか?

これらのことは私がすでに試したか見た

値を変更/proc/sys/net/core/rmem_maxし、/proc/sys/net/core/rmem_default実際に助けをやっている-実際にはそれだけで約半分ドロップされたパケットのの世話をしました。

gulpについても見てきました。gulpの問題は、1つのプロセスで複数のインターフェースをサポートしておらず、インターフェースにIPアドレスがない場合に怒るということです。残念ながら、それは私の場合、契約を破る要因です。

次の問題は、パイプを介してトラフィックが流れるとき、自動回転を実行できないことです。1つの巨大な10 TBファイルを取得するのはあまり効率的ではなく、wiresharkを実行できる10 TB以上のRAMを搭載したマシンはないので、それはありません。

何か提案はありますか?おそらく、トラフィックダンプをすべて行うより良い方法です。


私の場合、オプション-s0を使用していましたが、-s1600(MTUのすぐ上)に変更すると解決しました。
LatinSuD

回答:


11

tcpdumpは着信データをリングバッファに保存します。tcpdumpが内容を処理する前にバッファがオーバーフローすると、パケットが失われます。

デフォルトのリングバッファサイズはおそらく2048(2MiB)です。

バッファサイズを増やすには、-Bオプションを追加します。

tcpdump -B 4096 ...

また、より高速なディスクストレージを使用してみてください。


バッファサイズを変更してみます。ディスクストレージの速度が問題ではないことはほぼ確実です。ダンプ時および17ギガファイルのdd'ing時、データを約15M /秒で書き込みます:17179869184バイト(17 GB)コピー、23.5737 s、729 MB / s(bs = 8k count = 2048kを使用)
Frands Hansen

7

一緒に暮らすための解決策を見つけました。ドロップされたパッケージは.0047%から.00013%に減少しました。これは最初はそれほどではないように見えますが、何百万ものパケットについて話しているときは、かなりたくさんあります。

解決策はいくつかのもので構成されていました。1つは、Michael Hamptonが示唆したように、リングバッファサイズを変更することでした。

また、ramfsを作成してライブダンプを行い、圧縮スクリプトを書き直して、ダンプをramfsからディスクに移動するようにしました。これは、ディスクのすべてのテストとベンチマークが示しているにもかかわらず、ディスクがボトルネックになってはならないことを示していますが、量を非常に少なくしましたが、注目に値します。ここではアクセス時間が非常に重要だと思います。

ハイパースレッディングを無効にすることも、思っていた以上のことをしました。


「ハイパースレッディングを無効にする」ことは大いに役立つということですか?それはどれくらい役立つことができますか?ありがとう。
貧しい開発者

率直に言って、私はもうその詳細を思い出すことができません。それ以来職場を変えましたが、書いたところから、ハイパースレッディングを無効にすると問題が解決したようです。
フランズハンセン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.