Ubuntu服务器:奇怪的延迟跳转在局域网

我们用运行Ubuntu 16.04的服务器replace了老化的防火墙。

它几乎没有什么比使用约900条规则运行iptables(filter&nat combined)。

它更换的老化服务器工作正常,没有任何问题。

每隔一段时间(可以是一个小时或每30秒一次),新防火墙和LAN上的任何其他主机之间的延迟从0.1-0.2ms跳跃到10,40,100甚至3000ms几秒钟有时甚至持续几分钟)。 我注意到它在与DMZ主机的ssh连接上有一个简单的延迟(不应该有任何延迟),然后用简单的连续,高速率(-i 0.1)pingtesting对各种主机进行testing。

我在10gbps接口和1gbps接口之一上进行了testing。 服务器远不及networking的限制(〜10Kpps,100-400mbps的上下综合)。 CPU空闲99%

在从互联网连接到防火墙进行debugging的较长“中断”之一中,我注意到其他任何接口都没有问题,并且没有延迟问题。

为了从等式中移除交换机,我将1gbps接口移到了我们堆栈外的另一台交换机上,并将另一台服务器添加到新交换机上进行testing。 这个问题依然存在,我对多台机器运行一个固定的ping,每隔一段时间都会有2-3秒的时间,包括一个在“立即”交换机上的时间。

dmesg什么也没有显示,ifconfig显示没有错误,/ proc / interrupts显示所有的内核参与处理nic(s)(虽然我确信这么低的吞吐量,即使是1个内核也足够了)

任何build议或想法如何debugging这种情况下,将不胜感激。

谢谢!

编辑:添加ethtool输出:

eno1的设置:

Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes 

编辑2:也许这是无关紧要的,但我确实看到(真的很长)中断之一:

 %Cpu(s): 0.1 us, 3.3 sy, 0.0 ni, 95.7 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st KiB Mem : 16326972 total, 14633008 free, 296636 used, 1397328 buff/cache KiB Swap: 0 total, 0 free, 0 used. 15540780 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29163 root 20 0 0 0 0 S 8.0 0.0 14:08.45 kworker/4:0 31722 root 20 0 0 0 0 S 7.3 0.0 9:39.76 kworker/6:0 11677 root 20 0 0 0 0 S 5.6 0.0 0:04.65 kworker/3:1 149 root 20 0 0 0 0 S 4.0 0.0 27:21.36 kworker/2:1 46 root 20 0 0 0 0 S 0.3 0.0 0:06.93 ksoftirqd/6 

非常高的kworker cpu使用率(通常约为1%)。 任何想法?

我有类似的情况,这个链接帮助我们解决了我们的问题!

从本质上讲,你可能需要configurationTCP套接字接收最大缓冲区大小在2-4mb之间,甚至可能更小,如果它不影响你的服务,因为你有这么多的大尖峰。

比较这些问题:

  • 许多健康的交通与看似随机的,大规模的滞后高峰可能会持续很长一段时间。
  • 您已经确认问题出在您的新防火墙上。
  • 所有来自testing的数据都告诉你没有问题。
  • 这是一个非常偶然的,看似随机的操作系统接收的数据包和处理之间的延迟。

希望这是有帮助的!