Probleemoplossing Hoog CPU-gebruik door SNMP-proces
Inleiding
Dit document beschrijft een gestructureerde benadering voor probleemoplossing en het oplossen van een hoog CPU-gebruik naar het SNMP-proces op een 9800 draadloze LAN-controller.
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- Draadloze controller: C9800-80-K9 met 17.09.03
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Logboekverzameling
Het identificeren van CPU-gebruikspatronen Bij het ontvangen van een rapport van hoog CPU-gebruik dat is gekoppeld aan het SNMP-proces, is de eerste manier van handelen om gedetailleerde logbestanden te verzamelen over een gespecificeerd tijdskader. Dit zal helpen bij het vaststellen van een patroon of trend in CPU-gebruik, wat essentieel is om de tijden aan te geven waarop het SNMP-proces het meest actief en bron-intensief is.
Alvorens met de logboekinzameling te beginnen, is het noodzakelijk om specifieke informatie te verzamelen die wordt gebruikt om het proces van het oplossen van problemen te steunen. Begin met het verzamelen van weinig informatie over het probleem.
- Ondervindt het systeem spikes of wordt het altijd veel gebruikt?
- Wat is het benuttingspercentage in beide gevallen?
- Wat is de frequentie van een hoog CPU-gebruik?
- Hoe vaak elke SNMP-server de WLC aan het pollen is?
- Wie zijn de beste talkers?
Verzamel de opdrachtoutput van 9800 WLC met intervallen van twee minuten over een periode van tien minuten. Deze gegevens kunnen worden gebruikt om problemen met een hoog CPU-gebruik te analyseren, met name die welke betrekking hebben op het SNMP-proces.
#terminal length 0 #show clock #show process cpu sorted | exclude 0.0 #show process cpu history #show processes cpu platform sorted | exclude 0.0 #show snmp stats oid #show snmp stats hosts
Logboekanalyse
Na het verzamelen van deze logboeken, moet u ze analyseren om de impact te begrijpen.
Laten we eens kijken naar voorbeelden van CPU-gebruikslogboeken en het SNMP-proces identificeren dat de meeste CPU’s verbruikt.
WLC#show process cpu sorted | exclude 0.0 CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 250 621290375 58215467 10672 58.34% 39.84% 34.11% 0 SNMP LA Cache pr <-- High utilization 93 167960640 401289855 418 14.50% 11.88% 9.23% 0 IOSD ipc task 739 141604259 102242639 1384 8.57% 6.95% 7.21% 0 SNMP ENGINE 763 7752 34896 222 4.00% 3.41% 1.83% 5 SSH Process 648 6216707 181047548 34 0.72% 0.37% 0.31% 0 IP SNMP 376 3439332 51690423 66 0.40% 0.36% 0.25% 0 SNMP Timers 143 3855538 107654825 35 0.40% 0.35% 0.23% 0 IOSXE-RP Punt Se 108 6139618 17345934 353 0.40% 0.30% 0.34% 0 DBAL EVENTS
De uitvoer van het cpu van het showproces is gesorteerd | sluit 0.0 uit-opdracht geeft aan dat het SNMP-proces inderdaad een onevenredig aantal CPU-bronnen verbruikt. Met name de SNMP LA Cache per proces is de meest CPU-intensieve, gevolgd door andere SNMP-gerelateerde processen.
De volgende reeks opdrachten zal ons helpen om terug te boren naar het SNMP-proces voor hoog gebruik.
WLC#show snmp stats oid time-stamp #of times requested OID 11:02:33 Austral Jun 8 2023 27698 bsnAPIfDBNoisePower <-- Frequently polled OID 11:02:23 Austral Jun 8 2023 1 sysUpTime 11:02:23 Austral Jun 8 2023 17 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 1 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 6 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:19 Austral Jun 8 2023 24 clcCdpApCacheApName 11:02:19 Austral Jun 8 2023 1 clcCdpApCacheDeviceIndex 11:02:19 Austral Jun 8 2023 9 cLApCpuAverageUsage 11:02:19 Austral Jun 8 2023 1315 cLApCpuCurrentUsage 11:02:19 Austral Jun 8 2023 2550 bsnAPIfDBNoisePower
De output van de show snmp stats oid opdracht onthult de frequentie waarmee verschillende OIDs worden opgezocht. Een bepaalde OID, bsnAPIfDBNoisePower, valt op door zijn uitzonderlijk hoge aantal verzoeken. Dit suggereert dat agressieve polling van deze OID waarschijnlijk bijdraagt aan het hoge CPU-gebruik zoals waargenomen bij de WLC.
Laten we proberen te begrijpen wat de OID bsnAPIfDBNoisePower doet en zijn data-opslagtijden.
Navigeer naar SNMP Object Navigator en zoek in de OID "bsnAPIfDBNoisePower".
OID-zoekresultaat
Nu begrijp je dat het object bsnAPIfDBNoisePower de ruiskracht van elk kanaal rapporteert zoals gerapporteerd door elke AP. Gezien het grote aantal kanalen en AP's dat door de WLC wordt beheerd, kunnen de SNMP-gegevens die door deze OID worden gegenereerd aanzienlijk zijn. Wanneer WLC een groot aantal APs dient, kan het volume van gegevens die door het krijgen van dit OID worden geproduceerd immens zijn. Dit kan leiden tot een hoog CPU-gebruik omdat de WLC deze uitgebreide SNMP-verzoeken verwerkt.
Op dezelfde manier moet je het gedrag van de specifieke OID begrijpen die agressief wordt gepolled.
De volgende opdracht zal u helpen de SNMP-servers te kennen die de WLC aan het pollen zijn.
WLC#show snmp stats hosts Request Count Last Timestamp Address 77888844 00:00:00 ago 10.10.10.120 330242 00:00:08 ago 10.10.10.150 27930314 00:00:09 ago 10.10.10.130 839999 00:00:36 ago 10.10.10.170 6754377 19:45:34 ago 10.10.10.157 722 22:00:20 ago 10.10.10.11
Deze opdracht geeft een lijst van SNMP-servers, samen met hun verzoektellingen en de laatste tijdstempel van hun opiniepeilingsactiviteit.
Je kunt zien dat er meerdere verschillende servers zijn die de 9800 WLC aan het pollen zijn. Als u kijkt naar de complete logbestanden gegevens verzameld tijdens de laatste 10 minuten kunt u ook hun pollingfrequentie meten.
Nu kunt u naar elke server gaan en zien hoe vaak de beledigende OID wordt opgezocht. In dit voorbeeld wordt de OID om de 30 seconden gepolijst, wat aanzienlijk vaker is dan nodig. Aangezien de WLC RF/RRM gegevens elke 180 seconden ontvangt, resulteert het pollen van de OID elke 30 seconden in onnodige verwerking en draagt bij aan een hoog CPU-gebruik.
Zodra de beledigende OID en de server zijn geïdentificeerd, kunnen we meerdere verschillende oplossingen proberen om de belasting op de WLC te verminderen.
- Verlaag de opiniefrequentie op de SNMP-server.
- Als de OID niet nodig is voor het gebruik van de bediening, schakelt u de polling van die OID uit op de SNMP-server.
- Als u geen controle over de SNMP-server hebt, kunt u de SNMP-weergave gebruiken om de aanstootgevende OID te blokkeren.
SNMP-weergaveconfiguratie
Definieer een nieuwe weergave die de OID uitsluit die u wilt blokkeren. U wilt bijvoorbeeld de OID 1.3.6.1.4.1.14179.2.2.15.1.21 blokkeren, een nieuwe weergave maken en de OID aan de weergave toevoegen.
snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded <-- This is the OID of bsnAPIfDBNoisePower
snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.
snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.Tip voor probleemoplossing
- Basisgebruik van CPU’s: documenteer de normale CPU-gebruiksniveaus wanneer het SNMP-proces geen hoog gebruik veroorzaakt.
- SNMP-configuratie: controleer de huidige SNMP-configuratie-instellingen, inclusief community-strings, versie (v2c of v3) en toegangslijsten.
- SNMP Best Practice: Gebruik het best practice-document 9800 WLC en stem zo dicht mogelijk bij de voorgestelde configuratie voor SNMP.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Frequentie van SNMP-peiling: Bepaal hoe vaak de WLC wordt opgevraagd door SNMP-vragen, aangezien een hoge frequentie kan bijdragen aan een hogere CPU-belasting.
- Netwerktopologie en SNMP-managers: Begrijp de netwerkinstallatie en identificeer alle SNMP-managers die met de WLC communiceren.
- System Uptime: controleer de tijd die is verstreken sinds de laatste herstart om te zien of er een correlatie is tussen uptime en CPU-gebruik.
- Recente veranderingen: Let op alle recente veranderingen in de WLC-configuratie of het netwerk die kunnen samenvallen met het begin van een hoog CPU-gebruik.
- Met de 9800 WLC is de nadruk gelegd op telemetrie. Telemetrie werkt in een "push"-model waarbij WLC relevante informatie naar de server stuurt zonder dat er vragen hoeven te worden gesteld. Als uw SNMP-vragen WLC CPU-cycli verbruiken en operationele problemen veroorzaken, is het beter om naar Telemetry te gaan.
Conclusie
Door methodisch het analyseren van CPU-gebruiksgegevens en het correleren met SNMP-opinieactiviteiten, kunt u problemen oplossen en oplossen met hoge CPU-gebruiksproblemen die door SNMP-processen worden veroorzaakt op Cisco 9800 WLC. Post-implementatie controle is essentieel om het succes van de probleemoplossing inspanningen te bevestigen en optimale netwerkprestaties te handhaven.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
29-Jul-2024 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)