运行RHEL 6.10的HP ProLiant DL360 G9上的数据包丢弃
运行RHEL 6.10的HP ProLiant DL360 G9上的数据包丢弃
提问于 2019-05-31 01:09:50
我们有一个HP ProLiant DL360 G9运行RHEL 6.10和2X Intel 82599ES 10-Gigabit SFI/SFP+。HP产品名称为HP Ethernet 10Gb 2-port 560SFP+ Adapter
eth5和eth6显示了大量的丢包(rx_missed_errors)，我在网卡级别禁用了流量控制，然后rx_missed_errors停止了增加，但rx_no_dma_resources开始增加。
- 它们都是独立的接口，而不是连接的一部分。
- Eth5和eth6在不同的卡上
- 这两种卡都安装在PCIe 3.0 X16插槽上
- irqbalance正在服务器上运行。
更新1
eth5和eth6的环参数是相同的，并且已经达到最大值。
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096我注意到了eth6在/proc/interrupts中的跟随
Sun Jun 2 19:39:42 EDT 2019
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19
165: 0 0 0 0 0 484430 111744 333783 458868 577617 0 0 0 0 0 17978 402211 84832 183482 10567190 PCI-MSI-edge eth6-TxRx-0
166: 0 0 0 0 0 92569 2522312 36248 19459 1970 0 0 0 0 0 10140 33710 10180 1071214 651534 PCI-MSI-edge eth6-TxRx-1
167: 0 0 0 0 0 41060 2532170 37345 10970 92570 0 0 0 0 0 3055 22158 12485 1203344 494179 PCI-MSI-edge eth6-TxRx-2
168: 0 0 0 0 0 218925 8555 2312817 115650 126113 0 0 0 0 0 14575 3965 114145 995924 538667 PCI-MSI-edge eth6-TxRx-3
169: 0 0 0 0 0 7354 7781 199591 2262057 45221 0 0 0 0 0 34813 176350 105008 649389 962393 PCI-MSI-edge eth6-TxRx-4
170: 0 0 0 0 0 27982 23890 44703 162340 2597754 0 0 0 0 0 25991 22873 11846 885511 943057 PCI-MSI-edge eth6-TxRx-5
171: 0 0 0 0 0 16710 370 155 17725587 7504781 0 0 0 0 0 1054801625 1644839 14655 583745291 266971465 PCI-MSI-edge eth6-TxRx-6
172: 0 0 0 0 0 9823 6688 407394 11207 44103 0 0 0 0 0 88057 2496075 9284 56799 1391075 PCI-MSI-edge eth6-TxRx-7
173: 0 0 0 0 0 21175 1995 125490 151465 27120 0 0 0 0 0 19960 177195 2288457 787724 848755 PCI-MSI-edge eth6-TxRx-8
174: 0 0 0 0 0 7835 2210 3990 56075 106870 0 0 0 0 0 109740 24135 27720 2599827 1510934 PCI-MSI-edge eth6-TxRx-9
175: 0 0 0 0 0 42450 2605 39545 54520 162830 0 0 0 0 0 56035 11380 33815 52905 3993251 PCI-MSI-edge eth6-TxRx-10
176: 0 0 0 0 0 92335 33470 2290862 7545 227035 0 0 0 0 0 7550 25460 17225 65205 1682649 PCI-MSI-edge eth6-TxRx-11
177: 0 0 0 0 0 81685 56468 2273033 264820 195585 0 0 0 0 0 120640 36250 29450 244895 1146510 PCI-MSI-edge eth6-TxRx-12
178: 0 0 0 0 0 39655 24693 703993 1680384 22325 0 0 0 0 0 147980 27170 41585 72085 1689466 PCI-MSI-edge eth6-TxRx-13
179: 0 0 0 0 0 108905 1335 48265 2415832 19985 0 0 0 0 0 3545 23360 12590 35185 1780334 PCI-MSI-edge eth6-TxRx-14
180: 0 0 0 0 0 134826 291569 98014 9159 2262093 0 0 0 0 0 128867 18499 20078 39858 1463678 PCI-MSI-edge eth6-TxRx-15
181: 0 0 0 0 0 3220 37430 39030 129550 11070 0 0 0 0 0 2382452 24840 10860 146795 1664089 PCI-MSI-edge eth6-TxRx-16
182: 0 0 0 0 0 23120 28700 134025 96455 31545 0 0 0 0 0 30340 2262857 24485 144620 1673189 PCI-MSI-edge eth6-TxRx-17
183: 0 0 0 0 0 8900 29070 22490 112785 186240 0 0 0 0 0 40690 31665 2274862 37160 1705474 PCI-MSI-edge eth6-TxRx-18
184: 0 0 0 0 0 77090 18270 68465 53235 142648 0 0 0 0 0 16295 33770 29175 2367462 1642926 PCI-MSI-edge eth6-TxRx-19
185: 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 4 PCI-MSI-edge eth6所以看起来CPU/Core 15/18/19正面临着在eth6上处理通信量的压力
基本上，我不知道下一步该去哪里，我猜这可能与irq的亲和力有关，但不确定。我也认为禁用irqbalance，但不确定这是否会产生任何影响。
有什么建议吗？
更新2
NIC司机信息和我想我们没有那个窃听器。与2009年的情况一样。
driver: ixgbe
version: 4.2.1-k
firmware-version: 0x800008ea
bus-info: 0000:08:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no到达are 5/6的数据都是多播数据。这就足够了，安装端口镜像需要一张网络工程师团队的票，并且需要时间。我也不知道该告诉他们什么。
如果我正确理解您的注释，就有一种方法可以将eth6-rxtx队列平衡到多个CPU核心。我自己做了一些搜索，收集了以下信息，希望对你有用。
ethtool -x eth5和eth6
RX flow hash indirection table for eth5 with 20 RX ring(s):
0: 0 1 2 3 4 5 6 7
8: 8 9 10 11 12 13 14 15
16: 0 1 2 3 4 5 6 7
24: 8 9 10 11 12 13 14 15
32: 0 1 2 3 4 5 6 7
40: 8 9 10 11 12 13 14 15
48: 0 1 2 3 4 5 6 7
56: 8 9 10 11 12 13 14 15
64: 0 1 2 3 4 5 6 7
72: 8 9 10 11 12 13 14 15
80: 0 1 2 3 4 5 6 7
88: 8 9 10 11 12 13 14 15
96: 0 1 2 3 4 5 6 7
104: 8 9 10 11 12 13 14 15
112: 0 1 2 3 4 5 6 7
120: 8 9 10 11 12 13 14 15
RSS hash key:
3c:f9:4a:0e:fc:7e:cb:83:c2:2a:a4:1c:cf:59:38:1c:ca:54:38:b9:6b:e8:2b:63:6e:d2:9f:eb:fc:04:c2:86:6d:e3:54:f2:73:30:6a:65ethtool -n eth5 rx-flow-hash udp4和eth6
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA我还在eth5和eth6上运行了D37
sudo ./set_irq_affinity local eth5IFACE CORE MASK -> FILE
=======================
eth5 0 1 -> /proc/irq/144/smp_affinity
eth5 1 2 -> /proc/irq/145/smp_affinity
eth5 2 4 -> /proc/irq/146/smp_affinity
eth5 3 8 -> /proc/irq/147/smp_affinity
eth5 4 10 -> /proc/irq/148/smp_affinity
eth5 10 400 -> /proc/irq/149/smp_affinity
eth5 11 800 -> /proc/irq/150/smp_affinity
eth5 12 1000 -> /proc/irq/151/smp_affinity
eth5 13 2000 -> /proc/irq/152/smp_affinity
eth5 14 4000 -> /proc/irq/153/smp_affinity
eth5 0 1 -> /proc/irq/154/smp_affinity
eth5 1 2 -> /proc/irq/155/smp_affinity
eth5 2 4 -> /proc/irq/156/smp_affinity
eth5 3 8 -> /proc/irq/157/smp_affinity
eth5 4 10 -> /proc/irq/158/smp_affinity
eth5 10 400 -> /proc/irq/159/smp_affinity
eth5 11 800 -> /proc/irq/160/smp_affinity
eth5 12 1000 -> /proc/irq/161/smp_affinity
eth5 13 2000 -> /proc/irq/162/smp_affinity
eth5 14 4000 -> /proc/irq/163/smp_affinitysudo ./set_irq_affinity local eth6IFACE CORE MASK -> FILE
=======================
eth6 5 20 -> /proc/irq/165/smp_affinity
eth6 6 40 -> /proc/irq/166/smp_affinity
eth6 7 80 -> /proc/irq/167/smp_affinity
eth6 8 100 -> /proc/irq/168/smp_affinity
eth6 9 200 -> /proc/irq/169/smp_affinity
eth6 15 8000 -> /proc/irq/170/smp_affinity
eth6 16 10000 -> /proc/irq/171/smp_affinity
eth6 17 20000 -> /proc/irq/172/smp_affinity
eth6 18 40000 -> /proc/irq/173/smp_affinity
eth6 19 80000 -> /proc/irq/174/smp_affinity
eth6 5 20 -> /proc/irq/175/smp_affinity
eth6 6 40 -> /proc/irq/176/smp_affinity
eth6 7 80 -> /proc/irq/177/smp_affinity
eth6 8 100 -> /proc/irq/178/smp_affinity
eth6 9 200 -> /proc/irq/179/smp_affinity
eth6 15 8000 -> /proc/irq/180/smp_affinity
eth6 16 10000 -> /proc/irq/181/smp_affinity
eth6 17 20000 -> /proc/irq/182/smp_affinity
eth6 18 40000 -> /proc/irq/183/smp_affinity
eth6 19 80000 -> /proc/irq/184/smp_affinity更新3
我修改了upd4 rx-flow-hash，使其包括源端口和目标端口，但没有产生任何区别。
ethtool -n eth5 rx-flow-hash udp4UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]禁用irqbalance并手动更新/proc/irq/171/smp_affinity_list以包括所有10‘本地’CPU核心。
cat /proc/irq/171smp_affinity_list5-9,15-19下面是我进行上述更改后的grep 171: /proc/interrupts (将src和dst端口添加到udp4 rx-flow-hash，并将5-9,15-19添加到/proc/irq/171/smp_affinity_list)，让我们在前面调用它。
这是今天早上的grep 171: from /proc/interrupts，我们结束后再打电话吧。
Before 171: 0 0 0 0 0 16840 390 155 17725587 7505131 0 0 0 0 0 1282081848 184961789 21430 583751571 266997575 PCI-MSI-edge eth6-TxRx-6
After 171: 0 0 0 0 0 16840 390 155 17725587 7505131 0 0 0 0 0 1282085923 184961789 21430 583751571 267026844 PCI-MSI-edge eth6-TxRx-6从上面可以看出，irq 171只能由CPU 19来处理。如果irqbalance运行的是不同的CPU，那么似乎由于某种原因，irq 171不能平衡到多个CPU。
以下是丢包更新
Wed Jun 5 01:39:41 EDT 2019
ethtool -S eth6 | grep -E "rx_missed|no_buff|no_dma"
rx_no_buffer_count: 0
rx_missed_errors: 2578857
rx_no_dma_resources: 3456533
Thu Jun 6 05:43:34 EDT 2019
njia@c4z-ut-rttp-b19 $ sudo ethtool -S eth6 | grep -E "rx_missed|no_buff|no_dma"
rx_no_buffer_count: 0
rx_missed_errors: 2578857
rx_no_dma_resources: 3950904时间在这里并不重要，因为多播数据每天下午16:00后停止。
我在红帽网站当多个进程订阅同一个多播组时丢包上找到了这篇文章。
我们的开发人员还提到，如果我们只有一个运行应用程序的实例，则下降的次数会显著减少。通常有8个。
net.core.rmem_default从4Mb增加到16Mb
sysctl -w net.core.rmem_default=16777216
net.core.rmem_default = 16777216这是当前的Udp堆栈状态，明天将再次检查。
Fri Jun 7 00:40:10 EDT 2019
netstat -s | grep -A 4 Udp:
Udp:
90579753493 packets received
1052 packets to unknown port received.
1264898431 packet receive errors
1295021855 packets sent回答 1
Server Fault用户
发布于 2019-05-31 06:23:53
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://serverfault.com/questions/969574
复制相关文章
相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号