简介
本文档介绍如何确定StarOS KNI:内存不足日志是否由StarOS应用程序中的问题或硬件驱动程序引起。
背景
DPDK内部转发器(IFTASK)流程中的内核网络接口(KNI)模块是一种机制,它允许用户空间程序直接从网络接口接收数据包,完全绕过Linux网络和Linux IP堆栈。
KNI:当存在影响KNI模块的资源争用问题时,会产生“内存不足”日志的速率限制警告。
- 内存缓冲区在裸机(硬件)级别未清除,导致缓冲区溢出。
- iftask从中为这些数据包分配消息缓冲区的KNI池空间不足。
- 虚拟功能可查询更多数据包,但物理功能会响应它没有任何内容。
- 一旦KNI: Out of Memory情况发生,iftask将进入备份内存池中进一步分配和处理数据包。如果备份池也耗尽内存,系统将丢弃数据包。
- 由于iftask无法读取来自内核的数据包突发,因此StarOS上将生成KNI: Out of Memory日志。
KNI:内存不足情况的触发器:
缓冲区溢出情况的潜在触发因素可能会有所不同,例如运行SFTP或SCP应用,或者CF和SF卡之间传输超大文件。
调查步骤
步骤1:观察故障症状
第二步:检查DI网络运行状况降级
第三步:检查Userspace KNI丢弃
第四步:检查硬件驱动程序
步骤1:观察故障症状
将KNI:内存不足错误计时与其他症状(例如数据包丢失或应用层降级[egtpc路径故障])关联。
KNI:内存不足日志
- 在StarOS系统日志中,您可以看到指示核心网络接口内存不足的日志。
2023-Nov-16+09:18:03.205 [iftask 214701 error] [1/0/9602 <evlogd:0> evlgd_syslogd.c:236] [software internal system syslog] CPU[3/0]: Nov 16 14:18:03 iftask[7387]: KNI: Out of memory, kni port cpbond0, socket_id=0, total=-130952296, iter=27
- 如果备份内存耗尽,您会看到错误消息,指示备份池的内存也耗尽。
RTE_LOG(ERR, KNI, "Out of memory from Backup pool, kni port %s, socket_id=%d, total=%d, iter=%d\n", kni->name, rte_socket_id(), kni->oom_backup_warn, i)
- 在IFTask日志中(位于debug shell的tmp目录中),您可以看到KNI: Out of Memory错误:
Wed Nov 15 17:20:30 2023 PID:7387 KNI: Out of memory, kni port cpbond0, socket_id=0, total=-759247296, iter=25
EGTPC路径故障
- 导致多个对等体的gtpc路径故障峰值的原因可能导致在数据包丢失期间对等体没有响应。
2023-10-23T00:14:33.813+00:00 Nodename evlogd: [local-60sec33.780] [egtpmgr 143137 info] [6/0/12364 <egtpegmgr:3> egtpmgr_pm.c:905] [context: mme_ctx, contextID: 3] [software internal system critical-info syslog] context: mme_ctx, service : mme_svc_egtp, self addr: <X.X.X.X>, GTP-C path failure for peer <Y.Y.Y.Y>, peer session count marked: 0, egtpmgr state SRP_SESS_STATE_ACTIVE
第二步:检查DI网络运行状况降级
找到出现降级的连接。如果持续显示,较高的DI网络运行状况输出中的丢包或丢失百分比可能表示DI网络配置或运行问题、流量过载或VM或主机问题。
show session recovery status verbose
- 使用show session recover status verbose输出确定哪个虚拟功能卡充当解复用器卡。
******** show session recovery status verbose *******
Tuesday October 24 11:23:45 EDT 2023
Session Recovery Status:
Overall Status : Ready For Recovery
Last Status Update : 1 second ago
----sessmgr--- ----aaamgr---- demux
cpu state active standby active standby active status
---- ------- ------ ------- ------ ------- ------ -------------------------
3/0 Active 24 1 24 1 0 Good
4/0 Active 24 1 24 1 0 Good
5/0 Active 24 1 24 1 0 Good
6/0 Active 0 0 0 0 10 Good (Demux)
7/0 Active 24 1 24 1 0 Good
8/0 Active 24 1 24 1 0 Good
9/0 Active 24 1 24 1 0 Good
10/0 Active 24 1 24 1 0 Good
11/0 Active 24 1 24 1 0 Good
12/0 Standby 0 24 0 24 0 Good
show cloud monitor di-network detail
- 使用“show cloud monitor di-network detail”输出确定虚拟功能卡之间的哪些DI网络连接在心跳中发生丢弃。
- 显示了从CF卡和SF卡到SF卡6的波动信号丢失。CF和SF卡到其他CF和SF卡的输出显示无心跳丢弃。
******** show cloud monitor di-network detail *******
Tuesday October 24 11:23:51 EDT 2023
Card 1 Heartbeat Results:
ToCard Health 5Min-Loss 60Min-Loss
------ ------- --------- ----------
…
6 Good 0.00% 0.66%
…
Card 2 Heartbeat Results:
…
6 Bad 14.67% 3.50%
…
Card 3 Heartbeat Results:
…
6 Bad 5.35% 2.69%
…
Card 4 Heartbeat Results:
…
6 Good 0.00% 0.00%
…
Card 5 Heartbeat Results:
…
6 Bad 18.57% 3.90%
…
Card 6 Heartbeat Results:
…
1 Good 0.00% 0.90%
2 Bad 12.63% 3.31%
3 Bad 2.90% 2.14%
4 Good 0.00% 0.00%
5 Bad 13.09% 3.30%
7 Good 0.00% 0.00%
8 Bad 2.91% 2.20%
9 Good 0.00% 0.93%
10 Bad 14.28% 3.38%
11 Bad 3.67% 2.09%
12 Good 0.00% 0.00%
…
Card 7 Heartbeat Results:
…
6 Good 0.00% 0.00%
…
Card 8 Heartbeat Results:
…
6 Bad 7.47% 2.85%
…
Card 9 Heartbeat Results:
…
6 Bad 0.00% 1.07%
…
Card 10 Heartbeat Results:
…
6 Bad 16.01% 3.73%
…
Card 11 Heartbeat Results:
…
6 Bad 7.47% 2.71%
…
Card 12 Heartbeat Results:
…
6 Good 0.00% 0.00%
show cloud monitor controlplane
- 使用show cloud monitor contolplane输出确定哪些DI网络连接性能下降。
******** show cloud monitor controlplane *******
Tuesday October 24 11:24:22 EDT 2023
Cards 15 Second Interval 5 Minute Interval 60 Minute Interval
Src Dst Xmit Recv Miss% Xmit Recv Miss% Xmit Recv Miss%
--- --- ------ ------ ------ ------ ------ ------ ------ ------ ------
…
01 06 75 75 0.0% 1500 1500 0.0% 18000 17842 0.9%
…
02 06 75 75 0.0% 1500 1265 15.7% 18000 17546 2.5%
…
03 06 75 75 0.0% 1500 1396 6.9% 18000 17491 2.8%
…
04 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
…
05 06 75 75 0.0% 1500 1267 15.5% 18000 17325 3.8%
…
06 01 75 75 0.0% 1500 1500 0.0% 18000 17823 1.0%
06 02 75 75 0.0% 1500 1301 13.3% 18000 17567 2.4%
06 03 75 75 0.0% 1500 1419 5.4% 18000 17561 2.4%
06 04 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
06 05 75 75 0.0% 1500 1294 13.7% 18000 17579 2.3%
06 07 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
06 08 75 75 0.0% 1500 1417 5.5% 18000 17565 2.4%
06 09 75 75 0.0% 1500 1500 0.0% 18000 17824 1.0%
06 10 75 75 0.0% 1500 1296 13.6% 18000 17573 2.4%
06 11 75 75 0.0% 1500 1422 5.2% 18000 17570 2.4%
06 12 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
…
07 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
…
08 06 75 75 0.0% 1500 1426 4.9% 18000 17545 2.5%
…
09 06 75 75 0.0% 1500 1500 0.0% 18000 17833 0.9%
…
10 06 75 75 0.0% 1500 1278 14.8% 18000 17369 3.5%
…
11 06 75 75 0.0% 1500 1408 6.1% 18000 17481 2.9%
…
12 06 75 75 0.0% 1500 1500 0.0% 18000 18000 0.0%
show cloud monitor dataplane
- 使用show cloud monitor dataplane输出识别哪些DI网络连接有降级,并识别虚拟功能卡之间的任何单向降级。
******** show cloud monitor dataplane *******
Tuesday October 24 11:21:46 EDT 2023
Cards 15 Second Interval 5 Minute Interval 60 Minute Interval
Src Dst Miss Hit Pct Miss Hit Pct Miss Hit Pct
--- --- ------ ------ ------ ------ ------ ------ ------ ------ ------
…
06 01 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 02 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 03 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 04 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 05 1 149 0.7% 0 3001 0.0% 0 36000 0.0%
…
01 06 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
02 06 0 150 0.0% 210 2790 7.0% 1015 34985 2.8%
03 06 31 119 20.7% 540 2460 18.0% 995 35005 2.8%
04 06 34 116 22.7% 554 2446 18.5% 1017 34983 2.8%
05 06 0 150 0.0% 213 2787 7.1% 991 35009 2.8%
07 06 0 150 0.0% 0 3000 0.0% 359 35641 1.0%
08 06 29 121 19.3% 546 2454 18.2% 1009 34991 2.8%
09 06 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
10 06 0 150 0.0% 208 2792 6.9% 992 35008 2.8%
11 06 31 119 20.7% 548 2452 18.3% 993 35007 2.8%
12 06 34 116 22.7% 547 2453 18.2% 1001 34999 2.8%
…
06 07 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 08 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 09 0 150 0.0% 0 3000 0.0% 1 35999 0.0%
…
06 10 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 11 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
…
06 12 0 150 0.0% 0 3000 0.0% 0 36000 0.0%
第三步:检查Userspace KNI丢弃
show iftask stats
- 多次收集show iftask stats输出,以验证IFTASK userspace应用程序级别(StarOS)中的KNI丢弃没有增加。
******** show iftask stats *******
Tuesday October 24 11:22:06 EDT 2023
…
CARD 6 STATS
---------------------------------------------------------------------------
Counters SF6 SF6_PPS
---------------------------------------------------------------------------
svc_rx 2587301598 2203
svc_tx 548969428 295
di_rx 2260147059 2258
di_tx 4072038717 3966
__ALL_DROPS__ 0 0
svc_tx_drops 0 0
di_rx_drops 0 0
di_tx_drops 0 0
sw_rss_enq_drops 0 0
kni_thread_drops 0 0
kni_drops 0 0
mcdma_drops 0 0
mux_deliver_hop_drops 0 0
mux_deliver_drops 0 0
mux_xmit_failure_drops 0 0
mc_dma_thread_enq_drops 0 0
sw_tx_egress_enq_drops 0 0
cpeth0_drops 0 0
mcdma_summary_drops 0 0
fragmentation_err 0 0
reassembly_err 0 0
reassembly_ring_enq_err 0 0
__DISCARDS__ 241984 0
__BOND_DISCARDS__ 55282718 142
…
TOTAL STATS
---------------------------------------------------------------------------
Counters TOTAL TOTAL_PPS
---------------------------------------------------------------------------
svc_rx 27964563261 24791
svc_tx 36109966153 30168
di_rx 74133486629 51929
di_tx 73958155063 50897
__ALL_DROPS__ 0 0
svc_tx_drops 0 0
di_rx_drops 0 0
di_tx_drops 0 0
sw_rss_enq_drops 0 0
kni_thread_drops 0 0
kni_drops 0 0
mcdma_drops 0 0
mux_deliver_hop_drops 0 0
mux_deliver_drops 0 0
mux_xmit_failure_drops 0 0
mc_dma_thread_enq_drops 0 0
sw_tx_egress_enq_drops 0 0
cpeth0_drops 0 0
mcdma_summary_drops 0 0
fragmentation_err 0 0
reassembly_err 0 0
reassembly_ring_enq_err 0 0
__DISCARDS__ 2324968 0
__BOND_DISCARDS__ 55635534 149
-----------------------------------------------------------------------------------------------
NDR is 100.0000
CONTINUE_TRAFFIC
-----------------------------------------------------------------------------------------------
第四步:检查硬件驱动程序
在应用层已洗脱罪责后,侧重于硬件级别的基础驱动程序,以解决KNI: Out of Memory错误。
由于裸机硬件驱动程序为每个虚拟功能分配一定量的缓冲区,因此资源争用问题通常是由硬件级别的驱动程序不匹配或驱动程序缺陷导致的。分配应用程序所需缓冲区的有缺陷的硬件驱动程序未释放内存。
如果正在使用第三方(非思科)虚拟化软件和/或硬件,请检查版本和驱动程序是否存在潜在的兼容性不匹配或缺陷。
摘要
要确定KNI: Out of Memory错误是由应用层进程还是由底层硬件驱动程序引起的,请检查DI网络降级和用户空间KNI丢弃的证据。如果存在DI网络降级,而没有相应的用户空间KNI降级,则可以认为原因在硬件层面。KNI:内存不足错误和硬件级别降级表明硬件驱动程序故障。
对受影响应用级StarOS虚拟功能所在的主机计算进行节点卸载和重新加载可以临时清除基础计算上的内存缓冲区,从而暂时减少错误和数据包丢失。但是,这不是一个永久的解决方案! 数据包丢失和KNI:当有故障的硬件驱动程序上再次出现缓冲区溢出情况时,就会再次出现“内存不足”错误。