Begrijp het hoge CPU-gebruik dat door vManage wordt gerapporteerd voor vEdge 5000/2000/1000/100B- en vEdge Cloud-platforms
Inhoud
Inleiding
In dit document wordt beschreven waarom u mogelijk een hoog CPU-gebruik ziet dat wordt gerapporteerd in vManage voor vEdge 5000/2000/1000/100B- en vEdge Cloud-platforms, ondanks dat de prestaties van de platforms normaal zijn en er geen hoge CPU wordt gerapporteerd zoals bovenaan wordt weergegeven.
Begrijp het hoge CPU-gebruik dat wordt gerapporteerd op vEdge 5000/2000/1000/100B- en vEdge-cloudplatforms
Met de 17.2.x en latere versies kan een hoger CPU- en geheugenverbruik voor vEdge- en vEdge Cloud-platforms worden waargenomen. Dit wordt opgemerkt op het vManage Dashboard voor een bepaald apparaat. In sommige gevallen leidt dit ook tot een toename van het aantal waarschuwingen en waarschuwingen in vManage.
verklaring
De reden voor het gerapporteerde hoge CPU-gebruik wanneer het apparaat normaal presteert met normale, lage of geen belasting, is te wijten aan een verandering in de formule die wordt gebruikt om het gebruik te berekenen. Met de 17.2-releases wordt het CPU-gebruik berekend op basis van het laadgemiddelde van de systeemstatus op de vEdge.
vManage toont real-time CPU-gebruik voor een apparaat. Het haalt het 1-minutengemiddelde [min1_avg] en het 5-minutengemiddelde [min5_avg] op basis van historische gegevens. Load Average omvat per definitie verschillende dingen en niet alleen CPU-cycli die bijdragen aan de gebruiksberekening. Zo wordt bijvoorbeeld de wachttijd voor IO, de verwerkingstijd en andere waarden in aanmerking genomen wanneer u deze waarde voor het platform presenteert. In dit geval negeert u de waarden die worden weergegeven voor de CPU-statussen en CPU-waarden in de bovenste opdracht van vShell.
Hier is een voorbeeld van hoe het CPU-gebruik, dat in feite het laadgemiddelde van 1 minuut is, wordt berekend en weergegeven in het vManage-dashboard:
Wanneer u de belasting van een vEdge CLI controleert, ziet u dit:
vEdge# show system status | include Load Load average: 1 minute: 3.10, 5 minutes: 3.06, 15 minutes: 3.05 Load average: 1 minute: 3.12, 5 minutes: 3.07, 15 minutes: 3.06 Load average: 1 minute: 3.13, 5 minutes: 3.08, 15 minutes: 3.07
Load average: 1 minute: 3.10, 5 minutes: 3.07, 15 minutes: 3.05
In dit geval wordt het CPU-gebruik berekend op basis van Load-Average / # of Cores (vCPU's). In dit voorbeeld heeft de node 4 kernen. Het belastingsgemiddelde wordt vervolgens met een factor 100 geconverteerd voordat u deelt door het aantal kernen. Wanneer je het laadgemiddelde uit alle kernen haalt en vermenigvuldigt met 100, kom je uit op een waarde van ~310. Neem deze waarde en deel deze door 4 rendementen, een CPU-waarde van 77,5% CPU, die overeenkomt met de waarde die wordt gezien in de realtime-grafiek in vManage die is vastgelegd rond de tijd dat de CLI-uitvoer werd verzameld en zoals weergegeven in de afbeelding.
Om de laadgemiddelden en het aantal CPU-cores in het systeem te zien, kan de uitvoer van de bovenkant worden geraadpleegd via vShell op het apparaat.
In het voorbeeld hier bevat de vEdge 4 vCPU's. De eerste kern (Cpu0) wordt gebruikt voor Control (gezien door het lagere gebruikersgebruik), terwijl de overige 3 kernen worden gebruikt voor Data:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 694 root 20 0 1908m 204m 131m S 1 2.8 15:29.95 ftmd 496 root 20 0 759m 72m 3764 S 0 1.0 1:31.50 confd
Om het aantal CPU's uit de vEdge CLI te krijgen, kan deze opdracht worden gebruikt:
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
Een ander voorbeeld van de berekening voor de waarde die in vManage op vEdge 1000 wordt weergegeven, wordt hier gegeven. Nadat u top van vShell hebt uitgegeven, is l geïnteresseerd om de belasting voor alle kernen weer te geven:
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
Aangezien een vEdge 1000 slechts één CPU-kern beschikbaar heeft, is de hier gerapporteerde belasting 55% (0,55 * 100).
Hoog CPU-gebruik met fp-um proces
Je kunt ook soms van bovenaf opmerken dat het fp-um-proces hoog loopt en tot 100% CPU laat zien. Dit wordt verwacht op de CPU-kernen die worden gebruikt voor gegevensvlakverwerking.
Van de bovenste opdracht waarnaar eerder is verwezen, werken 3 kernen met 100% CPU en toont 1 kern normaal gebruik:
top - 01:14:57 up 1 day, 3:15, 1 user, load average: 3.06, 3.06, 3.08 Tasks: 219 total, 5 running, 214 sleeping, 0 stopped, 0 zombie Cpu0 : 1.7%us, 4.0%sy, 0.0%ni, 94.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 56.0%us, 44.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 54.2%us, 45.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 59.3%us, 40.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 7382664k total, 2835232k used, 4547432k free, 130520k buffers Swap: 0k total, 0k used, 0k free, 587880k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 978 root 20 0 3392m 664m 127m R 100 9.2 1635:21 fp-um-2 692 root 20 0 3392m 664m 127m R 100 9.2 1635:18 fp-um-1 979 root 20 0 3392m 664m 127m R 100 9.2 1634:51 fp-um-3 ...
Deze eerste kern (Cpu0) wordt gebruikt voor Control en de drie resterende kernen worden gebruikt voor Data. Zoals u kunt zien in de proceslijst, gebruikt het fp-um-proces deze bronnen.
FP-UM is een proces waarbij een poll-mode driver wordt gebruikt, wat betekent dat het de onderliggende poort voor pakketten constant zit en peilt, zodat het elk frame kan verwerken zodra het wordt ontvangen. Dit proces is geschikt voor forwarding en is gelijk aan fast-path forwarding in de vEdge 1000, vEdge 2000 en vEdge 100. Deze poll-mode architectuur wordt door Intel gebruikt voor efficiënte pakketverwerking op basis van Data Plane Development Kit (DPDK) framework. Omdat packet forwarding in een strakke lus wordt geïmplementeerd, blijft de CPU te allen tijde op of dicht bij 100%. Hoewel dit wordt gedaan, wordt er geen latentie geïntroduceerd via deze CPU's, omdat dit verwacht gedrag is.
Achtergrondinformatie over DPDK-polling vindt u hier.
De vEdge Cloud- en vEdge 5000-platforms gebruiken dezelfde doorstuurarchitectuur en vertonen in dit opzicht hetzelfde gedrag. Hier is een voorbeeld van een vEdge 5000 die uit de bovenste uitgang is getrokken. Het heeft 28 kernen, waarvan er 2 (Cpu0 en Cpu1) worden gebruikt voor Control (zoals de vEdge 2000) en 26 worden gebruikt voor Data.
top - 02:18:30 up 1 day, 7:33, 1 user, load average: 26.24, 26.28, 26.31 Tasks: 382 total, 27 running, 355 sleeping, 0 stopped, 0 zombie Cpu0 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 0.7%us, 1.3%sy, 0.0%ni, 98.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu2 : 79.4%us, 20.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu3 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 73.4%us, 26.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu16 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu17 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu18 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu19 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu20 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu21 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu22 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu23 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu24 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu25 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu26 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu27 :100.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32659508k total, 10877980k used, 21781528k free, 214788k buffers Swap: 0k total, 0k used, 0k free, 1039104k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2028 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-3 2029 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-4 2030 root 20 0 12.1g 668m 124m R 100 2.1 1897:12 fp-um-5 2031 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-6 2032 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-7 2034 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-9 2035 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-10 2038 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-13 2040 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-15 2041 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-16 2043 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-18 2045 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-20 2052 root 20 0 12.1g 668m 124m R 100 2.1 1897:18 fp-um-27 2033 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-8 2036 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-11 2037 root 20 0 12.1g 668m 124m R 100 2.1 1897:21 fp-um-12 2039 root 20 0 12.1g 668m 124m R 100 2.1 1897:09 fp-um-14 2042 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-17 2044 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-19 2046 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-21 2047 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-22 2048 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-23 2049 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-24 2050 root 20 0 12.1g 668m 124m R 100 2.1 1897:22 fp-um-25 2051 root 20 0 12.1g 668m 124m R 100 2.1 1897:23 fp-um-26 1419 root 20 0 116m 5732 2280 S 0 0.0 0:02.00 chmgrd 1323 root 20 0 753m 70m 3764 S 0 0.2 1:51.20 confd 1432 root 20 0 1683m 172m 134m S 0 0.5 0:58.91 fpmd
Hier is het laadgemiddelde altijd hoog omdat 26 van de 28 processors 100% draaien vanwege het fp-um-proces.
Conclusie
Het gerapporteerde CPU-gebruik in vManage voor 17.2.x-releases vóór 17.2.7 is niet het werkelijke CPU-gebruik, maar wordt in plaats daarvan berekend op basis van het laadgemiddelde. Dit kan leiden tot verwarring bij het begrijpen van de gerapporteerde waarde en leiden tot valse alarmen met betrekking tot hoge CPU terwijl het platform normaal werkt met normale, lage of geen werkelijke verkeer / netwerkbelasting.
Dit gedrag wordt gewijzigd / gewijzigd met de 17.2.7 en 18.2 releases, zodat de CPU-lezing nu nauwkeurig kan zijn op basis van de cpu_user-lezing van bovenaf.
De kwestie wordt ook genoemd in de 17.2 release notes.
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)