Verständnis der von vManage für vEdge 5000/2000/1000/100B und vEdge Cloud-Plattformen gemeldeten hohen CPU-Auslastung
Inhalt
Einleitung
In diesem Dokument wird beschrieben, warum in vManage für vEdge 5000/2000/1000/100B- und vEdge Cloud-Plattformen eine hohe CPU-Auslastung gemeldet wird, obwohl die Leistung der Plattformen normal ist und keine hohe CPU-Auslastung gemeldet wird, wie im oberen Teil dargestellt.
Verständnis der hohen CPU-Auslastung, die auf vEdge 5000/2000/1000/100B- und vEdge-Cloud-Plattformen gemeldet wird
Mit der Version 17.2.x und späteren Versionen kann eine höhere CPU- und Speicherauslastung für vEdge- und vEdge Cloud-Plattformen beobachtet werden. Dies wird auf dem vManage Dashboard für ein bestimmtes Gerät festgestellt. In einigen Fällen führt dies auch zu einer erhöhten Anzahl von Warnungen und Warnungen in vManage.
Erläuterung
Der Grund für die gemeldete hohe CPU-Auslastung, wenn das Gerät normal, niedrig oder nicht ausgelastet ist, liegt in einer Änderung der Formel, die zur Berechnung der Auslastung verwendet wird. Bei den Versionen 17.2 wird die CPU-Auslastung auf der Grundlage des Lastdurchschnitts von Systemstatus auf dem vEdge anzeigen berechnet.
vManage zeigt die CPU-Nutzung eines Geräts in Echtzeit an. Es ermittelt den 1-Minuten-Durchschnitt [min1_avg] und den 5-Minuten-Durchschnitt [min5_avg] auf der Grundlage historischer Daten. Load Average umfasst definitionsgemäß verschiedene Dinge und nicht nur CPU-Zyklen, die zur Nutzungsberechnung beitragen. Beispielsweise werden die E/A-Wartezeit, die für den Prozess ausstehende Zeit und andere Werte berücksichtigt, wenn Sie diesen Wert für die Plattform angeben. In diesem Fall ignorieren Sie die Werte, die im obersten Befehl von vShell für die CPU-Zustände und CPU-Werte angezeigt werden.
Im Folgenden finden Sie ein Beispiel dafür, wie die CPU-Auslastung, also der Lastdurchschnitt von 1 Minute, berechnet und im vManage-Dashboard angezeigt wird:
Wenn Sie die Last aus einer vEdge-CLI überprüfen, wird Folgendes angezeigt:
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 diesem Fall wird die CPU-Auslastung auf Basis des Lastdurchschnitts/der Anzahl der Kerne (vCPUs) berechnet. In diesem Beispiel verfügt der Knoten über vier Kerne. Der Lastdurchschnitt wird dann um den Faktor 100 konvertiert, bevor Sie durch die Anzahl der Kerne dividieren. Wenn Sie den Lastdurchschnitt aus allen Kernen mit 100 multiplizieren, erhalten Sie einen Wert von ~310. Teilen Sie diesen Wert durch 4 Erträge, eine CPU mit 77,5 % CPU, die mit dem Wert übereinstimmt, der im Echtzeitdiagramm in vManage angezeigt wird um den Zeitpunkt, an dem die CLI-Ausgabe erfasst wurde, und wie im Bild dargestellt.
Um die Lastdurchschnitte und die Anzahl der CPU-Kerne im System anzuzeigen, kann die Ausgabe von top von vShell auf dem Gerät abgerufen werden.
Im vorliegenden Beispiel enthält der vEdge 4 vCPUs. Der erste Kern (Cpu0) wird für die Steuerung verwendet (erkennbar an der geringeren Benutzerauslastung), während die restlichen 3 Kerne für Daten verwendet werden:
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
Um die Anzahl der CPUs aus der vEdge-CLI abzurufen, kann der folgende Befehl verwendet werden:
vEdge# show system status | display xml | include total_cpu
<total_cpu_count>4</total_cpu_count>
Ein weiteres Beispiel für die Berechnung des Werts, der in vManage auf vEdge 1000 angezeigt wird, finden Sie hier. Nachdem Sie top von vShell ausgegeben haben, ist l daran interessiert, die Last für alle Kerne anzuzeigen:
top - 18:19:49 up 19 days, 1:37, 1 user, load average: 0.55, 0.71, 0.73
Da ein vEdge 1000 nur über einen CPU-Kern verfügt, beträgt die hier angegebene Last 55 % (0,55 x 100).
Hohe CPU-Auslastung mit fp-um-Prozess
Manchmal bemerkt man auch von oben, dass der fp-um Prozess hoch läuft und bis zu 100% CPU zeigt. Dies wird für die CPU-Kerne erwartet, die für die Datenebenenverarbeitung verwendet werden.
Vom oben genannten Befehl aus arbeiten 3 Kerne mit 100 % CPU, und 1 Kern zeigt die normale Auslastung an:
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 ...
Dieser erste Kern (Cpu0) wird für die Steuerung verwendet und die drei verbleibenden Kerne werden für Daten verwendet. Wie Sie in der Prozessliste sehen können, verwendet der fp-um Prozess diese Ressourcen.
fp-um ist ein Prozess, der einen Polling-Modus-Treiber verwendet, d. h., dass er den zugrunde liegenden Port ständig nach Paketen abfragt, sodass er jeden Frame verarbeiten kann, sobald er empfangen wird. Dieser Prozess behandelt die Weiterleitung und entspricht der Fast-Path-Weiterleitung in vEdge 1000, vEdge 2000 und vEdge 100. Dies Die poll-mode-Architektur wird von Intel für eine effiziente Paketverarbeitung auf der Basis des DPDK-Frameworks (Data Plane Development Kit) verwendet. Da die Paketweiterleitung in einem engen Loop implementiert ist, bleibt die CPU jederzeit bei oder nahe bei 100 %. Obwohl dies erfolgt, wird keine Latenz durch diese CPUs eingeführt, da dieses Verhalten erwartet wird.
Hintergrundinformationen zum DPDK-Polling finden Sie hier.
Die vEdge Cloud- und vEdge 5000-Plattformen verwenden dieselbe Weiterleitungsarchitektur und zeigen in dieser Hinsicht dasselbe Verhalten. Hier ist ein Beispiel eines vEdge 5000, der von der oberen Ausgabe gezogen wird. Er verfügt über 28 Kerne, von denen 2 (CPU0 und CPU1) für die Steuerung verwendet werden (wie der vEdge 2000) und 26 für Daten verwendet werden.
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 ist der Load Average immer hoch, da 26 der 28 Prozessoren aufgrund des fp-um Prozesses zu 100% laufen.
Schlussfolgerung
Die gemeldete CPU-Auslastung in vManage für Versionen vor 17.2.7.x entspricht nicht der tatsächlichen CPU-Auslastung, sondern wird auf Basis des Lastdurchschnitts berechnet. Dies kann zu Verwirrung beim Verständnis des gemeldeten Werts führen und zu Fehlalarmen im Zusammenhang mit einer hohen CPU-Auslastung führen, während die Plattform normal mit normalem, niedrigem oder gar keiner tatsächlichen Datenverkehrs-/Netzwerklast arbeitet.
Dieses Verhalten wird mit den Versionen 17.2.7 und 18.2 geändert, sodass der CPU-Wert jetzt auf der Basis des cpu_user-Werts von oben genau angegeben werden kann.
Dieses Problem wird auch in den Versionshinweisen zu Version 17.2 erwähnt.
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)