故障排除"KNI:内存不足(&Q);QvPC-DI平台上的错误
简介
本文档介绍如何确定StarOS KNI:内存不足日志是由StarOS应用程序中的问题或硬件驱动程序引起的。
背景
DPDK内部转发器(IFTASK)流程中的内核网络接口(KNI)模块是一种机制，它允许用户空间程序直接从网络接口接收数据包，完全绕过Linux网络和Linux IP堆栈。
KNI:内存不足日志当存在影响KNI模块的资源争用问题时会产生速率限制警告。
- 内存缓冲区在裸机（硬件）级别未清除，导致缓冲区溢出。
- iftask从中为这些数据包分配消息缓冲区的KNI池空间不足。
- 虚拟功能会查询更多数据包，但物理功能会响应它没有任何内容。
- 一旦KNI:如果出现内存不足的情况，iftask将进入备份内存池以进一步分配和处理数据包。如果备份池也耗尽内存，系统将丢弃数据包。
- 由于iftask无法读取来自内核的数据包突发，因此KNI:内存不足日志在StarOS上生成。
KNI触发因素：内存不足情况：
缓冲区溢出情况的潜在触发因素可能会有所不同，例如运行SFTP或SCP应用程序，或者在CF卡和SF卡之间传输超大文件。
调查步骤
步骤1.观察症状
步骤2.检查DI网络运行状况是否下降
步骤3.检查Userspace KNI Drops
步骤4.检查硬件驱动程序
步骤1.观察症状
关联KNI的时间：内存不足错误和其他症状，如数据包丢失或应用层降级(egtpc路径故障)。
KNI:内存不足日志
— 在StarOS系统日志中，您可以看到指示内核网络接口内存不足的日志。
2023-Nov-16+09:18:03.205 [iftask 214701 error] [1/0/9602 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:内存不足错误：
Wed Nov 15 17:20:30 2023 PID:7387 KNI: Out of memory, kni port cpbond0, socket_id=0, total=-759247296, iter=25EGTPC路径故障
- gtpc到不同对等体的路径故障峰值可能出现，原因为在数据包丢失期间，对等体不会做出响应。
2023-10-23T00:14:33.813+00:00 Nodename evlogd: [local-60sec33.780] [egtpmgr 143137 info] [6/0/12364 egtpmgr_pm.c:905] [context: mme_ctx, contextID: 3] [software internal system critical-info syslog] context: mme_ctx, service : mme_svc_egtp, self addr: , GTP-C path failure for peer , peer session count marked: 0, egtpmgr state SRP_SESS_STATE_ACTIVE 步骤2.检查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 contoplane输出确定哪些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%
步骤3.检查Userspace KNI Drops
show iftask stats
— 多次收集show iftask stats输出，以验证KNI丢弃不会在IFTASK用户空间应用级别(StarOS)中增加。
******** 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
-----------------------------------------------------------------------------------------------
步骤4.检查硬件驱动程序
在应用层洗清罪责之后，重点关注硬件级别的基础驱动程序，以解决KNI:内存不足错误。
由于裸机硬件驱动程序为每个虚拟功能分配一定量的缓冲区，因此资源争用问题通常是由硬件级别的驱动程序不匹配或驱动程序缺陷导致的。分配应用程序所需的缓冲区的有缺陷的硬件驱动程序未释放内存。
如果使用第三方（非思科）虚拟化软件和/或硬件，请调查版本和驱动程序是否存在潜在的兼容性不匹配或缺陷。
摘要
要确定KNI:内存不足错误是由应用级进程或底层硬件驱动程序引起的，请检查是否存在DI网络降级和用户空间KNI丢弃。如果存在DI网络降级，而没有相应的用户空间KNI降级，则原因可归结为在硬件级别。KNI:Out of Memory错误和硬件级别降级指示硬件驱动程序故障。
节点卸载和重新加载受影响的应用级StarOS虚拟功能所在的主机计算，可以临时清除基础计算机上的内存缓冲区，从而暂时减少错误和数据包丢失。但是，这不是永久的解决方案！丢包和KNI:当有故障的硬件驱动程序上再次出现缓冲区溢出情况时，内存不足错误会再次出现。
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
2.0 |
30-Apr-2024
|
首次公开发布 |
1.0 |
29-Apr-2024
|
初始版本 |
反馈