在繁忙的界面上进行 tcpdumping 时有很多丢弃的包

Question

我的挑战

我需要对大量数据进行 tcpdumping - 实际上来自处于混杂模式的 2 个接口，它们能够看到大量流量。

把它们加起来

现在我像这样使用 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。这样做的原因是，我有两个接口，我想在单个线程而不是两个线程中运行转储。

compress.sh 负责将 tar 分配给另一个 CPU 内核，压缩数据，给它一个合理的文件名并将其移动到存档位置。

我无法指定两个接口，因此我选择使用过滤器并从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的问题是，它不支持一个进程中的多个接口，如果接口没有 IP 地址，它会生气。不幸的是，这对我来说是一个交易破坏者。

下一个问题是，当交通流过管道时，我无法进行自动旋转。获取一个巨大的 10 TB 文件效率不高，而且我没有一台可以运行 Wireshark 的 10TB 以上 RAM 的机器，所以就这样了。

你有什么建议吗？也许甚至更好的方式来完成我的流量转储。

Answer 1

tcpdump 将传入数据存储在环形缓冲区中。如果缓冲区在 tcpdump 处理其内容之前溢出，那么您将丢失数据包。

要增加缓冲区大小，请添加-B选项：

tcpdump -B 4096 ...

您还应该尝试使用更快的磁盘存储。

Answer 2

我最终找到了一个可以忍受的解决方案。丢弃的包已从 .0047% 减少到 0.00013% - 起初看起来并不多，但是当我们谈论数百万个包时，它已经很多了。

解决方案包括几件事。一种是按照 Michael Hampton 的建议更改环形缓冲区大小。

此外，我创建了一个 ramfs 并对其进行了实时转储，重写了我的压缩脚本以负责将转储从 ramfs 移动到磁盘。这只是减少了很少的数量，但足以引起注意 - 即使磁盘的所有测试和基准测试表明，磁盘不应该是瓶颈。我想访问时间在这里非常重要。

禁用超线程也比你想象的要多。