debugging感知的networking饱和度

我遇到了一个networking问题,一台机器正在以150 Mbit / s的速率发送数据,而另一台正在以100 Mbit / s的速度接收数据。 发送应用程序最终崩溃,抱怨内存不足(这实际上是一个自定义的DSP,所以没有用于进入错误消息)。

所以我很怀疑接收机不能正确处理负载,但是我在调​​试这种情况方面不是很有经验。

我一直在运行一些vmstat但我不知道是否有任何数字是惊人的或不是:

 rb swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 13317200 262808 2311648 0 0 0 0 1131 3403 4 1 96 0 0 0 0 0 13309140 262808 2311652 0 0 0 9 2092 9235 10 2 89 0 0 0 0 0 13295748 262808 2311652 0 0 0 0 4521 22710 14 4 82 0 0 5 0 0 13279620 262808 2311652 0 0 0 0 13835 66325 30 10 60 0 0 6 0 0 13257432 262808 2311656 0 0 0 0 20092 92365 43 14 43 0 0 3 0 0 13232756 262808 2311660 0 0 0 0 22522 117367 49 17 34 0 0 3 0 0 13207832 262808 2311664 0 0 0 10 23419 149649 54 20 26 0 0 7 0 0 13159720 262808 2311668 0 0 0 8 23816 168436 56 21 23 0 0 8 0 0 13122148 262808 2311668 0 0 0 0 26267 168578 54 20 26 0 0 8 0 0 13119544 262808 2311668 0 0 0 0 30498 164004 53 24 24 0 0 7 0 0 13117312 262808 2311668 0 0 0 0 29853 163340 55 23 23 0 0 8 0 0 13116832 262808 2311664 0 0 0 3 29942 162609 55 22 24 0 0 8 0 0 13118824 262808 2311668 0 0 0 0 30098 162232 55 21 24 0 0 8 0 0 13118212 262808 2311668 0 0 0 0 29213 159902 45 18 37 0 0 8 0 0 13116352 262808 2311668 0 0 0 3 29552 161978 55 21 24 0 0 7 0 0 13117468 262808 2311664 0 0 0 9 30218 162704 56 22 22 0 0 5 0 0 13116972 262808 2311672 0 0 0 0 30172 164399 57 19 24 0 0 8 0 0 13115608 262808 2311672 0 0 0 8 30068 163894 56 18 26 0 0 0 0 0 13181080 262808 2311676 0 0 0 0 19062 151066 46 20 34 0 0 6 0 0 13186536 262808 2311676 0 0 0 0 6812 85690 15 19 66 0 0 1 0 0 13186784 262808 2311676 0 0 0 0 6733 82150 19 22 59 0 0 0 0 0 13203400 262808 2311716 0 0 0 9 2659 33015 5 5 90 0 0 

我也检查了sockstat ,但是我不知道这些数字是否令人担忧:

 > cat /proc/net/sockstat sockets: used 920 TCP: inuse 82 orphan 0 tw 0 alloc 91 mem 8228 UDP: inuse 271 mem 20 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 

这里是TCP缓冲存储器(我尝试将它们设置为实验室中另一台机器上看到的值,它们大约是没有变化的三倍):

 > sysctl -a | grep tcp.*mem net.ipv4.tcp_mem = 69888 93184 139776 net.ipv4.tcp_wmem = 4096 16384 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 

至于硬件方面,我有8个这样的核心:

 > cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Xeon(R) CPU E5472 @ 3.00GHz stepping : 10 cpu MHz : 2403.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes bogomips : 5999.77 clflush size : 64 cache_alignment : 64 address sizes : 38 bits physical, 48 bits virtual 

还有什么其他的工具可以用来debugging呢? 如果有人有这种debugging的好资源,我将不胜感激!

这显示了什么? sudo sysctl -a | grep tcp.*mem

另外: sudo ethtool ethWhateverYoursIs

这是我的猜测,发送应用程序不是在尊重TCPstream量控制,并最终用完TCP发送缓冲区内存和崩溃。

我假设发件人有一个1Gbit网卡,它发送的stream量不是TCP,否则它永远不会比接收者能够接收的速度快。 “最好的”解决scheme可能是让应用程序获得一些不太快的发送,但是你也可以检查接收器是否实际运行100Mbit而不是1Gbit。 你也可以看两个系统上的netstat -i来查看是否有错误或丢失。

编辑:根据您的意见,我会build议或者TCP工作不正常(如果您的应用程序泄漏内存,几乎肯定是一个错误,这是有道理的),或者您的测量工具不准确。 你用什么来衡量你的stream量? 您可以运行netstat -i -c进行持续更新(每秒一次)以查看系统认为正在发送和接收的内容。