Problemen met hoog CPU-gebruik oplossen dankzij SNMP-proces
Inleiding
Dit document beschrijft een gestructureerde aanpak voor het oplossen van problemen en het oplossen van een hoog CPU-gebruik voor het SNMP-proces op een 9800 Wireless LAN-controller.
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
- Draadloze controller: C9800-80-K9 actief 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 Na ontvangst van een rapport van hoog CPU-gebruik gekoppeld aan het SNMP-proces, is de eerste manier van handelen om gedetailleerde logs over een bepaald tijdsbestek te verzamelen. Dit zal helpen bij het vaststellen van een patroon of trend in CPU-gebruik, wat essentieel is voor het aanwijzen van de tijden waarop het SNMP-proces het meest actief en arbeidsintensief is.
Voordat u begint met het verzamelen van logs, is het noodzakelijk om specifieke informatie te verzamelen die wordt gebruikt om het probleemoplossingsproces te ondersteunen. Begin met het verzamelen van weinig informatie over het probleem.
- Ervaart het systeem pieken of constant hoog gebruik?
- Wat is in beide gevallen het bestedingspercentage?
- Wat is de frequentie van het hoge CPU-gebruik?
- Hoe vaak wordt de WLC door elke SNMP-server gepolst?
- Wie zijn de topsprekers?
Verzamel de opdrachtuitvoer van 9800 WLC met intervallen van twee minuten gedurende een periode van tien minuten. Deze gegevens kunnen worden gebruikt om problemen met het hoge CPU-gebruik te analyseren, met name die met betrekking tot 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
Logs-analyse
Na het verzamelen van deze logs, moet u ze analyseren om de impact te begrijpen.
Laten we eens kijken naar een voorbeeld van CPU-gebruiklogs en het SNMP-proces identificeren dat de meeste CPU 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 showproces gesorteerd | 0.0 uitsluiten geeft aan dat het SNMP-proces inderdaad een onevenredige hoeveelheid CPU-bronnen verbruikt. Concreet is het SNMP LA Cache pr-proces het meest CPU-intensief, gevolgd door andere SNMP-gerelateerde processen.
De volgende set commando's gaat ons helpen om het SNMP-proces voor hoge benutting te verkennen.
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 uitvoer van de opdracht show snmp stats oid geeft de frequentie weer waarmee verschillende OID's worden gepolst. Een bepaalde OID, bsnAPIfDBNoisePower, valt op door het uitzonderlijk hoge aantal verzoeken. Dit suggereert dat agressieve polling van deze OID waarschijnlijk bijdraagt aan het hoge CPU-gebruik dat op de WLC wordt waargenomen.
Laten we proberen te begrijpen wat de OID bsnAPIfDBNoisePower doet en de opslagtijden van gegevens.
Navigeer naar SNMP Object Navigator en zoek de OID "bsnAPIfDBNoisePower".
Zoekresultaat OIDDus nu begrijpt u dat het object bsnAPIfDBNoisePower de ruiskracht van elk kanaal rapporteert zoals gerapporteerd door elk toegangspunt. Gezien het grote aantal kanalen en toegangspunten dat door de WLC wordt beheerd, kunnen de SNMP-gegevens die door deze OID worden gegenereerd, aanzienlijk zijn. Wanneer de WLC een groot aantal toegangspunten bedient, kan het volume van gegevens dat wordt gegenereerd door deze OID te peilen enorm zijn. Dit kan leiden tot een hoog CPU-gebruik omdat de WLC deze uitgebreide SNMP-verzoeken verwerkt.
Op dezelfde manier moet u het gedrag begrijpen van de specifieke OID die agressief wordt ondervraagd.
De volgende opdracht zal u helpen de SNMP-servers te kennen die de WLC pollen.
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 bevat een lijst met SNMP-servers, het aantal aanvragen en de laatste tijdstempel van hun pollingactiviteit.
U kunt zien dat er meerdere verschillende servers zijn die de 9800 WLC pollen. Als u kijkt naar de volledige logboekgegevens die in de afgelopen 10 minuten zijn verzameld, kunt u ook hun stemfrequentie meten.
Nu kunt u naar elke server gaan en zien hoe vaak de overtredende OID wordt gepolst. In dit voorbeeld wordt de OID elke 30 seconden gepolst, wat aanzienlijk frequenter is dan nodig. Aangezien de WLC elke 180 seconden RF/RRM-gegevens ontvangt, resulteert het peilen van de OID elke 30 seconden in onnodige verwerking en draagt het bij aan een hoog CPU-gebruik.
Zodra de overtredende OID en de server zijn geïdentificeerd, kunnen we meerdere verschillende oplossingen proberen om de belasting op de WLC te verminderen.
- Verminder de polling frequentie op de SNMP-server.
- Als de OID niet nodig is voor het gebruik van de bewerking, schakelt u de polling van die OID uit vanaf de SNMP-server.
- Als u geen controle hebt over de SNMP-server, kunt u de SNMP-weergave gebruiken om de overtredende OID te blokkeren.
SNMP View-configuratie
Definieer een nieuwe weergave die de OID die u wilt blokkeren, uitsluit. 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 koppelen.
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
- Basislijn CPU-gebruik: documenteer de normale CPU-gebruiksniveaus wanneer het SNMP-proces geen hoog gebruik veroorzaakt.
- SNMP-configuratie: bekijk de huidige SNMP-configuratie-instellingen, inclusief communitytekenreeksen, versie (v2c of v3) en toegangslijsten.
- SNMP Best Practice: Gebruik het 9800 WLC best practice document en match de voorgestelde configuratie voor SNMP zo dicht mogelijk.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Frequentie van SNMP-polling: Bepaal hoe vaak de WLC wordt ondervraagd door SNMP-query's, omdat een hoge frequentie kan bijdragen aan een verhoogde CPU-belasting.
- Netwerktopologie en SNMP-managers: begrijp de netwerkconfiguratie en identificeer alle SNMP-managers die interactie hebben met de WLC.
- Uptime van het systeem: Controleer de tijd die is verstreken sinds de laatste herstart om te zien of er een correlatie is tussen uptime en CPU-gebruik.
- Recente wijzigingen: let op recente wijzigingen in de WLC-configuratie of het netwerk die kunnen samenvallen met het begin van een hoog CPU-gebruik.
- Met 9800 WLC is de focus gelegd op telemetrie. Telemetrie werkt in een "push"-model waarbij WLC relevante informatie naar de server verzendt zonder dat deze hoeft te worden opgevraagd. Als uw SNMP-query's WLC-CPU-cycli gebruiken en operationele problemen veroorzaken, is het beter om naar Telemetry te gaan.
Conclusie
Door de gegevens over het CPU-gebruik methodisch te analyseren en te correleren met SNMP-pollingactiviteiten, kunt u problemen met het hoge CPU-gebruik oplossen die worden veroorzaakt door SNMP-processen op de Cisco 9800 WLC. Monitoring na de implementatie is essentieel om het succes van de inspanningen voor probleemoplossing te bevestigen en om optimale netwerkprestaties te behouden.
Gerelateerde informatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
29-Jul-2024
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)