我需要做很多数据的tcpdump – 实际上从混杂模式中剩余的2个接口，能够看到很多stream量。
把它们加起来
现在我使用这样的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 / dstfilter，以便我可以使用-i any 。 原因是，我有两个接口，我想运行在一个单一的线程而不是两个转储。
compress.sh负责将tar分配给另一个CPU核心，压缩数据，给它一个合理的文件名并将其移动到归档位置。
我不能指定两个接口，因此我select使用filter并从any接口转储。
现在，我不做任何家务pipe理，但我计划监控磁盘，当我剩下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的问题是，它不支持一个进程中的多个接口，并且如果接口没有IP地址，就会生气。 不幸的是，在我的情况下，这是一个交易断路器。
接下来的问题是，当交通stream经pipe道时，我无法自动旋转。 获得一个巨大的10TB文件不是很有效率，我没有一台可以运行wireshark的10TB + RAM的机器，所以没有了。
你有什么build议吗？ 也许甚至更好的做我的stream量转储的方式。
tcpdump将传入的数据存储在环形缓冲区中。 如果在tcpdump处理其内容之前缓冲区溢出，则会丢失数据包。
默认的环形缓冲区大小可能是2048 （2MiB）。
要增加缓冲区大小，请添加-B选项：
tcpdump -B 4096 ...
你也应该尝试使用更快的磁盘存储。
我最终find了一个与之共存的解决scheme。 丢弃的软件包从0.0047％下降到了0.00013％，这个数据起初看起来并不多，但是当我们谈论数百万个数据包的时候，这个数量还是相当多的。
解决scheme包括几件事情。 一个是按照迈克尔·汉普顿的build议来改变环形缓冲区的大小。
另外，我创build了一个ramfs，并进行了实时转储，重写了我的压缩脚本，负责将转储从ramfs移动到磁盘。 尽pipe所有的磁盘testing和基准testing都显示磁盘不应该成为瓶颈，但这个数量只是减less了很less的数量，但足以引人注目。 我猜这里的访问时间非常重要。
禁用超线程也比你想象的要多。