Fehlerbehebung für "KNI: Nicht genügend Arbeitsspeicher" Fehler auf QvPC-DI-Plattformen
Inhalt
Einleitung
In diesem Dokument wird beschrieben, wie Sie feststellen können, ob StarOS KNI: Out of Memory-Protokolle durch Probleme in der StarOS-Anwendung oder durch Hardwaretreiber verursacht werden.
Hintergrund
Das Kernel Network Interface (KNI)-Modul innerhalb des DPDK Internal Forwarder (IFTASK)-Prozesses ist ein Mechanismus, der es Anwenderraumprogrammen ermöglicht, Pakete direkt von einer Netzwerkschnittstelle zu empfangen, wobei das Linux-Netzwerk und der Linux-IP-Stack vollständig umgangen werden.
KNI: Protokolle außerhalb des Arbeitsspeichers geben Warnungen zur Beschränkung der Datenrate aus, wenn ein Ressourcenkonflikt das KNI-Modul beeinträchtigt.
- Speicherpuffer werden nicht auf Bare-Metal- (Hardware-) Ebene geleert, was zu einem Pufferüberlauf führt.
- Den KNI-Pools, aus denen die iftask den Nachrichtenpuffer für diese Pakete zuordnet, geht der Speicherplatz aus.
- Die virtuelle Funktion fragt nach mehr Paketen, die physische Funktion antwortet jedoch, dass sie über nichts verfügt.
- Sobald der Zustand KNI: Out of Memory (KNI: Nicht genügend Arbeitsspeicher) auftritt, geht die iftask in den Reservespeicherpool, um das Paket zuzuweisen und weiter zu verarbeiten. Wenn auch der Speicher des Sicherungspools knapp wird, verwirft das System die Pakete.
- Da die iftask den Burst von Paketen, die vom Kernel kommen, nicht lesen kann, wird auf StarOS das KNI: Out of Memory Log erzeugt.
Trigger für KNI: Out of Memory Bedingung:
Mögliche Auslöser für den Pufferüberlauf können variieren, z. B. die Ausführung von SFTP- oder SCP-Anwendungen oder eine sehr große Dateiübertragung zwischen CF- und SF-Karten.
Schritte zur Untersuchung
Schritt 1: Beobachtung der Symptome
Schritt 2: Überprüfen Sie die Integrität des DI-Netzwerks.
Schritt 3: Nach KNI-Drops im Benutzerbereich suchen
Schritt 4: Überprüfen der Hardwaretreiber
Schritt 1: Beobachtung der Symptome
Korrelation der Zeitpunkte von KNI: Out-of-Memory-Fehlern mit anderen Symptomen, wie Paketverlusten oder Beeinträchtigungen der Anwendungsebene (Ausfall des EGTC-Pfads)
KNI: Protokolle zu wenig Arbeitsspeicher
- In den StarOS Syslogs können Sie Protokolle sehen, die darauf hinweisen, dass die Kernelnetzwerkschnittstelle nicht mehr über genügend Arbeitsspeicher verfügt.
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- Wenn der Backup-Speicher aufgebraucht ist, werden Fehlermeldungen angezeigt, die darauf hinweisen, dass auch der Speicher des Backup-Pools aufgebraucht ist.
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)- In den IFTask-Protokollen im Verzeichnis tmp in der Debug-Shell können Sie die Fehler KNI: Out of Memory (KNI: Nicht genügend Arbeitsspeicher) beobachten:
Wed Nov 15 17:20:30 2023 PID:7387 KNI: Out of memory, kni port cpbond0, socket_id=0, total=-759247296, iter=25EGTPC-Pfadfehler
- Spitzen bei Gtpc-Pfadfehlern zu verschiedenen Peers können die Ursache haben. Keine Antwort vom Peer kann während der Zeit der Paketverluste auftreten.
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_ACTIVESchritt 2: Überprüfen Sie die Integrität des DI-Netzwerks.
Finden Sie heraus, welche Verbindungen die Degradation aufweisen. Werden diese Daten dauerhaft angezeigt, können höhere Verlustraten bei den DI-Netzwerkdiagnosen auf Probleme mit der Konfiguration oder dem Betrieb des DI-Netzwerks, Überlastung des Datenverkehrs oder Probleme mit virtuellen Systemen oder Hosts hinweisen.
Ausführliche Informationen zum Wiederherstellungsstatus der Sitzung anzeigen
- Verwenden Sie show session recover status verbose ausgaben, um zu identifizieren, welche virtuelle Funktionskarte als Demux-Karte dient.
******** 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
Details zu Di-Netzwerken für Cloud-Monitor anzeigen
- Verwenden Sie die Ausgabe "show cloud monitor di-network detail", um zu ermitteln, welche DI-Netzwerkverbindungen zwischen virtuellen Funktionskarten einen Heartbeat-Verlust aufweisen.
- Ein Herzschlag von CF- und SF-Karten auf SF-Karte 6 wird angezeigt. Ausgänge für CF- und SF-Karten zu anderen CF- und SF-Karten zeigen keine Heartbeat-Drops.
******** 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%
Kontrollebene für Cloud-Monitor anzeigen
- Verwenden Sie show cloud monitor control plane ausgaben, um zu identifizieren, welche DI-Netzwerkverbindungen verschlechtert haben.
******** 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%
Datenflugzeug für Cloud-Überwachung anzeigen
- Verwenden Sie show cloud monitor dataplane output, um zu identifizieren, welche DI-Netzwerkverbindungen Verschlechterungen aufweisen, und um etwaige unidirektionale Verschlechterungen zwischen virtuellen Funktionskarten zu identifizieren.
******** 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%
Schritt 3: Nach KNI-Drops im Benutzerbereich suchen
iftask-Statistiken anzeigen
- Sammeln Sie show iftask stats Ausgaben mehrmals, um sicherzustellen, dass KNI-Drops nicht in der IFTASK UserSpace Application Level (StarOS) inkrementiert werden.
******** 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
-----------------------------------------------------------------------------------------------
Schritt 4: Überprüfen der Hardwaretreiber
Nachdem die Anwendungsebene von der Verantwortung entbunden wurde, konzentrieren Sie sich auf die zugrunde liegenden Treiber auf Hardwareebene, um die Fehler KNI: Out of Memory (Nicht genügend Arbeitsspeicher) zu beheben.
Da der Bare-Metal-Hardwaretreiber für jede virtuelle Funktion eine bestimmte Puffermenge zuweist, sind Ressourcenkonflikte in der Regel das Ergebnis einer Treiberdiskrepanz oder defekter Treiber auf Hardwareebene. Der fehlerhafte Hardwaretreiber, der die für eine Anwendung benötigten Puffer reservierte, hat den Speicher nicht freigegeben.
Wenn Virtualisierungssoftware und/oder -hardware von Drittanbietern (nicht von Cisco) im Einsatz sind, ermitteln Sie die Versionen und Treiber für mögliche Kompatibilitätskonflikte oder -defekte.
Zusammenfassung
Um festzustellen, ob KNI: Out-of-Memory-Fehler durch Prozesse auf Anwendungsebene oder durch zugrunde liegende Hardwaretreiber verursacht werden, überprüfen Sie, ob eine Degradation des DI-Netzwerks und KNI-Ausfälle im Benutzerbereich vorliegen. Liegt eine Degradation des DI-Netzwerks ohne entsprechende Degradation des KNI-Benutzerbereichs vor, kann auf die Ursache auf Hardwareebene geschlossen werden. KNI: Nicht genügend Arbeitsspeicher-Fehler und eine Entzerrung auf Hardwareebene weisen auf fehlerhafte Hardwaretreiber hin.
Ein Offload des Knotens und ein Neuladen der Host-Rechner, auf denen sich die betroffene virtuelle StarOS-Funktion auf Anwendungsebene befindet, kann die Speicherpuffer auf dem zugrunde liegenden Rechner vorübergehend leeren, was zu einer vorübergehenden Reduzierung von Fehlern und Paketverlusten führt. Dies ist jedoch keine dauerhafte Lösung! Paketverluste und KNI: Out-of-Memory-Fehler treten erneut auf, wenn der Pufferüberlauf auf dem fehlerhaften Hardwaretreiber erneut auftritt.
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
30-Apr-2024 |
Erstveröffentlichung |
1.0 |
29-Apr-2024 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)