linux - UDP调整Linux

Question

我有一个传输udp流的c应用程序。它在大多数服务器上运行良好，但在少数服务器上却很疯狂。
我有100Mbps的网络连接，比如服务器上的eth1。使用这个网络我通常传输（tx）大约10-30mbps的udp流，这个网络连接将有大约100-300kbps的rx到服务器。我有其他网络连接，比如服务器中的eth0，C应用程序从该服务器接收udp流并转发到100Mbps网络连接eth1。
我的应用程序使用blockingsendto()函数在eth1中传输udp数据包。数据包的长度可变，从17字节到最大1333字节。但大多数时候，超过1000字节。
问题是：有时eth1上的功能块会在1秒左右长时间阻塞。这种情况每30秒到3分钟发生一次。当sendto阻塞时，我将有很多udp数据包被内核缓冲在eth0的udp接收缓冲区中，在这里c应用程序接收数据包。一旦eth1上的长阻塞调用返回sendto，c应用程序将有大量缓冲数据包要从eth0传输。然后c应用程序用nextsendto调用发送所有这些缓冲包。这将在从eth1接收udp流的另一个端点上创建峰值速率。这将在另一个端点创建类似z的速率图。所以这个z型的速度尖峰是我的问题。
我试图在内核设置中将sendto从大约131kb增加到5mb以克服峰值。设置这个可以解决我的尖峰问题。现在我在另一个终点没有z型的峰值速率，但我有了新的问题。新问题是：我得到了很多包丢失代替尖峰。我认为这可能是因为eth1的发送缓冲区积累了大量要发送的数据包，而从eth1发送当前数据包需要花费大量时间（这就是为什么可能会阻塞较长的原因）。在下一时刻，当网卡在短时间内从发送缓冲区发送所有累积的数据包时，这可能会导致网络拥塞，我可能会得到大量的数据包丢失，而不是尖峰。
所以，这是第二个问题。但我认为根本原因是：为什么有时nic在发送流量时会暂停很长时间，每30秒到3分钟一次？
我可能需要查看eth1驱动程序的tx环缓冲区吗？当套接字发送缓冲区由于nic没有及时发送而满时（由于随机长时间的tx暂停），然后下一次调用wmem_defaultblocks for room in socket send buffer，是否也会阻塞driver tx ring buffer中的room？
请不要告诉我udp是不可靠的，我们无法控制包丢失。我知道它不可靠，udp包可能丢失。但我相信我们仍然可以做些事情来减少数据包丢失。
编辑
我试图在内核设置中将sendto从大约131kb增加到5mb以克服峰值。我还删除了阻塞sendto调用。现在我使用like:wmem_default和使用sendto的大发送缓冲区。另外，由于发送缓冲区太大，我在sendto(sockfd, buf, len, MSG_DONTWAIT ,dest_addr, addrlen);上没有得到任何wmem_default或EAGAIN错误，但是仍然有数据包丢失而不是尖峰。
编辑
由于eth0的接收缓冲区中没有积累过多的数据包，因此，由于eth0的非阻塞EWOULDBLOCK调用和sendto中没有任何sendto或wmem_default错误，因此消除了峰值。我认为从应用程序的角度来看这是可能的解决方案。但主要的问题是为什么nic每过几分钟就会变慢？可能的原因是什么？当它从长时间的tx暂停恢复时，可能会在发送缓冲区中积累大量的数据包，这些数据包在下一时刻会以突发的方式发送，从而造成大量的数据包丢失。
更多更新
我使用相同的C应用程序在机器（127.0.0.1）中进行本地传输，并且从未在本地遇到任何峰值或数据包丢失问题。

Answer 1

问题是：有时eth1上的sendto函数块会在1秒左右长时间阻塞。
令人惊讶的是，阻塞sendto可能会阻塞。
问题是：有时eth1上的sendto函数块会在1秒左右长时间阻塞。
可能是IP stack is performing path MTU discovery：
当mtu发现正在进行时，来自数据报套接字的初始数据包可能会被丢弃。使用udp的应用程序应该意识到这一点，而不是考虑到它们的包重传策略。
我尝试在内核设置中将wmem_的默认值从大约131kb增加到5mb，以克服峰值。
小心增加缓冲区大小。在一定的限制之后，增加缓冲区大小只会增加排队的数量，从而增加延迟，导致臭名昭著的bufferbloat。
您也可以使用NIC Queuing Disciplines，它们负责丢弃传出的数据包。