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

Modified on: Mon, 25 Mar 2019 21:20:02 +0800

我的挑战

我需要对大量数据进行tcpdumping - 实际上是从混杂模式下留下的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。原因是,我有两个接口,我想在一个线程而不是两个线程中运行转储。

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文件并不是非常有效,我没有一台10TB + RAM的机器,我可以运行wireshark,所以就这样了。

你有什么建议吗?也许甚至可以更好地完成我的流量转储。

最佳答案

我最终找到了一个可以忍受的解决方案。丢弃的软件包已经从.0047%减少到.00013% - 这一开始看起来并不多,但是当我们谈论数百万个数据包时,这是非常多的。

解决方案包括几件事。一个是改变环形缓冲区大小,如迈克尔汉普顿所建议的那样。

另外,我创建了一个ramfs并对其进行了实时转储,重新编写了我的压缩脚本,以便将转储从ramfs移动到磁盘。这只是减少了很少的数量,但足以引人注目 - 即使磁盘的所有测试和基准测试显示,磁盘不应该成为瓶颈。我想这里的访问时间非常重要。

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


相关问答

添加新评论