Hohe Kernel Last!! Woher?

[PatiB87]

Hey,

ich nutze ein aktuelles Debian auf einem Intel-NUC.
Darauf läuft Virtualbox und darin 5 VMs, jeweils auch wieder mit Debian.
Das ganze betreibt meine Haussteuerung plus eine VM für PiHole.

Nun habe ich plötzlich in htop auf dem NUC eine sehr hohe Kernel-Last auf beiden CPUs! Ca. 50% "roter Balken" / Kernel Last.
Ebenfalls haben 4 meiner 5 VMs dieses Problem! Die haben wiederum nur eine CPU zugeteilt und haben selbst nach reboot ca. 40-50% Last auf dieser einen CPU durch Kernel.
Mit htop komme ich selbst mit Hilfe von Shift-k nicht weiter.
Die 5. VM hat das Problem nicht und ich weiß nicht warum...

Wie finde ich heraus, wo diese Last herkommt?
Habt ihr Tipps? Brauche dringend Hilfe, alles wird dadurch spürbar langsam!

Viele Grüße
Patrick

[snyborg]

du siehst in der VM mit htop nicht, was da CPU verbrät?

Warum?

[PatiB87]

Das ist genau die Frage. Er zeigt in den VMs zB rot 40-50% an, aber selbst mit Shift-K sehe ich keinen Eintrag, der was verbraucht. Wie kann das sein?

[PatiB87]

Update:
Ich habe jetzt auch mal mit "top" statt "htop" reingeguckt... auch mit mit "sudo" (dachte, es zeigt dann vielleicht mehr).
Top sagt, die Last käme nicht von "sy" (Kernel), sondern "si" (Software Interrupts).

Ist das vielleicht ein hilfreicher Tipp?

EDIT:
Dazu habe ich grade gelesen:

If CPU "sy" time is high, this can often indicate that there are some large directories (say a user's "spam" mail directory) with hundreds of thousand or millions of entries, or other large directory trees. Another common cause of high "sy" CPU time is the system firewall: iptables. There are other causes of course but these seem to be the primary ones.

Könnte es also sein, dass irgendwelche Log-Directories zu groß geworden sind?
iptables haben die VMs nicht installiert.

[wanne]

Klingt stark nach irgend welcher I/O, die nicht hinter her kommt.
Das irgend welche Nutzt dir jetzt vermutlich wenig. Aber ein Tipp ist es mal.

[PatiB87]

Da hätte ich dann die Vermutung Ethernet, denn sonst haben die VMs nichts.
Aber bei einer CPU Last von 40% und laut iftop gehen da nur Kilobytes im peak rein/raus - was auch Sinn macht.

Ich habe noch eine andere Vermutung: Der Host könnte Swappen... aber warum sollte ich das in den VMs im htop sehen?

[wanne]

Der Host könnte Swappen...

Das macht eine menge I/O... free -h aufm Host wäre hilfreich.

aber warum sollte ich das in den VMs im htop sehen?

Siehst du ja nicht wirklich. Du siehst nur dass der Kernel die ganze Zeit arbeitet. Das der beim "Arbieten" nur auf I/O wartet ist natürlich nicht ablesbar.

[PatiB87]

Hey,

erstmal Danke für deine Antwort!

Free auf dem NUC gibt das hier:

total used free shared buff/cache available
Mem: 2,8Gi 2,3Gi 236Mi 1,0Mi 293Mi 316Mi
Swap: 1,9Gi 176Mi 1,8Gi

Auf einer der betroffenen VMs das hier:

total used free shared buff/cache available
Mem: 483Mi 77Mi 143Mi 5,0Mi 262Mi 388Mi
Swap: 509Mi 0B 509Mi

EDIT / Nachtrag:
Habe den NUC und die VMs neu gestartet, scheint nicht geholfen zu haben.

Hier das free einer betroffenen VM:

total used free shared buff/cache available
Mem: 483Mi 60Mi 280Mi 1,0Mi 142Mi 409Mi
Swap: 509Mi 0B 509Mi

Hier das der einen nach wie vor NICHT betroffenen VM:

total used free shared buff/cache available
Mem: 483Mi 134Mi 207Mi 2,0Mi 140Mi 333Mi
Swap: 509Mi 0B 509Mi

Der NUC selbst schien das Problem auch nicht zu haben bevor ich die VMs gestartet habe. Heißt, die Kernel-Last, die der NUC-htop anzeigt kommt scheinbar NUR aus den VMs.


Damit haben wir aber doch schon einen ganz guten Hebel um zwischen einer betroffenen und einer nicht-betroffenen VM zu vergleichen, oder?

[MSfree]

Free auf dem NUC gibt das hier:

Code: Alles auswählen

              total        used        free      shared  buff/cache   available
Mem:          2,8Gi       2,3Gi       236Mi       1,0Mi       293Mi       316Mi
Swap:         1,9Gi       176Mi       1,8Gi

Wieso hat der nur 2.8GiB RAM? Das sollten wohl eher an die 4GiB sein.
Hast du dem NUC im BIOS zuviel Graphikspeicher spendiert?

[PatiB87]

Ich glaube ich habe da tatsächlich 1x2GB und 1x1GB drin.. Der kam mit 1x2GB und ich hatte noch ein 1GB Dimm über.
Ist sicher keine Performancemaschine, ist auch nur ein DualCore Celeron.

Aber das Problem ist ja in den VMs. Warum ziehen 4 CPU wie blöd und eine nicht?

Ich überlege, ob das nicht seit dem Kernel-Update von vor 2-3 Wochen passiert sein kann?
Wenn ich nachher dazu komme, werde ich mal eine VM auf den Prüfstand nehmen und mal einen Sicherungspunkt von vor dem Update wiederherstellen.


Habt ihr noch andere Tipps? Man muss doch irgendwie sehen können, WAS das System da tut?!

[reox]

schau mal mittels dstat ob du nicht einfach hohe io-wait hast. Die 4. spalte ansehen was dort steht.

[PatiB87]

Hey, danke für den Tipp.

Hier die Ausgabe von dstat von der NICHT betroffenen VM:

Code: Alles auswählen

--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
  0   0 100   0   0|3483B 1580B|   0     0 |   1B   24B| 343    66 
  2   0  98   0   0|   0     0 |  10k 1996B|   0     0 | 410   185 
  1   0  99   0   0|   0     0 |2061B  436B|   0     0 | 305    49 
  0   0 100   0   0|   0     0 |1652B  436B|   0     0 | 334    79 
  1   1  99   0   0|   0     0 |5064B 1212B|   0     0 | 381   156 
  1   0  99   0   0|   0     0 |2805B  342B|   0     0 | 315   108 
  0   0  99   1   0|  20k   44k|2724B  342B|  20k    0 | 333    98 
  0   1  99   0   0|   0     0 |1216B 1176B|   0     0 | 317    73 
  0   0 100   0   0|   0     0 |1757B  436B|   0     0 | 301    72 
  0   0  99   1   0|   0     0 |1890B  436B|   0     0 | 308    70 
  1   0  99   0   0|4096B    0 |4208B 1392B|4096B    0 | 350   141 
  0   0 100   0   0|   0  4096B|2726B  452B|   0     0 | 316    89 
  0   0 100   0   0|   0     0 | 786B  444B|   0     0 | 296    40 
  0   0 100   0   0|4096B    0 |1489B 1152B|4096B    0 | 318    71 ^C

Und hier von einer betroffenen VM:

Code: Alles auswählen

--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 31   0  69   0   0|3051B  484B|   0     0 |   0     0 |2037   205 
 33   0  67   0   0|   0     0 | 157k 1198B|   0     0 |2030   242 
 35   0  65   0   0|   0     0 | 175k  436B|   0     0 |2197   233 
 33   0  67   0   0|   0     0 | 174k  436B|   0     0 |2217   222 
 27   0  73   0   0|   0     0 | 168k  436B|   0     0 |2126   179 
 36   3  26  35   0|  16k   18M| 175k  436B|   0     0 |2182   269 
 31   0  69   0   0|   0   544k| 175k  452B|   0     0 |2235   223 
 28   0  72   0   0|   0     0 | 165k  444B|   0     0 |2087   210 
 30   0  70   0   0|   0     0 | 172k  676B|   0     0 |2184   214 
 33   0  67   0   0|   0     0 | 176k  436B|   0     0 |2230   205 
 22   1  73   4   0|   0    24k| 139k  436B|   0     0 |1832   158 
 26   0  74   0   0|   0     0 | 157k  444B|   0     0 |2015   167 
 27   0  73   0   0|   0     0 | 179k  436B|   0     0 |2253   172 
 29   1  70   0   0|   0     0 | 157k  556B|   0     0 |2037   192 ^C

Hier steht jetzt die Last unter "usr", aber wie gesagt: unter top steht sie unter "si":

Code: Alles auswählen

top - 14:42:07 up 19:12,  1 user,  load average: 0,03, 0,04, 0,01
Tasks:  69 total,   2 running,  67 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,3 us,  0,3 sy,  0,0 ni, 65,5 id,  0,0 wa,  0,0 hi, 33,9 si,  0,0 st
MiB Mem :    483,4 total,    186,0 free,     65,4 used,    232,0 buff/cache
MiB Swap:    510,0 total,    510,0 free,      0,0 used.    404,1 avail Mem 

[PatiB87]

Ich glaube grade in "top" gesehen zu haben, dass, auch wenn die Prozente nicht stimmen, eine Dauerlast von "ksoftirqd" bei den betroffenen VMs ausgeht, bei den nicht-betroffenen wiederum nicht...

[reox]

Offenbar gibts dazu auch bugreports zB https://www.virtualbox.org/ticket/10611
bzgl Virtualbox und software interrupt loads findet man schon sachen... Evt fehlt irgendwas in der virtualisierung?
Bin mir nicht sicher was genau die software interrupts da sind und ob die unter /proc/interrupts oder /proc/softirqs auftauchen - du könntest aber mal das file beobachten, um einzugrenzen wo die herkommen.
Vielleicht kann man auch mit mpstat noch was herausfinden...

[PatiB87]

Aha, wir kommen der Sache näher! :O
Ich werde auch mal schauen, vielleicht sind ja irgendwelche Virtualisierungs-Settings zwischen den Maschinen unterschiedlich oder so.

[reox]

Das muss gar nicht sein - es kann einfach sein, dass irgendein Programm das provoziert.
Ich hatte mal einen vserver wo ich nach einiger zeit hohe STEAL werte hatte. Laut Kundensupport lag es an meiner VM. Ein Neustart hat da aber immer abhilfe geschaffen...

Offenbar ist /proc/softirqs eh die richtige Datei zum ansehen.
Mach zB mal ein

Code: Alles auswählen

while :; do cat /proc/softirqs; sleep 10; done

und überprüfe ob nach ein paar iterationen irgendeiner der Werte signifikant größer ist.
Evt lässt sich so eingrenzen, was genau die softirqs verursacht.

Gibts dafür vllt auch ein tool, dass das besser darstellt?

Das hier ist vllt relevant: http://outofsync.net/wiki/index.php?tit ... t_Handlers
Hat die VM viel Netzwerklast? Was für einen Netzwerkmodus verwendest du? Ich hab lang kein Virtualbox mehr verwendet aber gibts dort auch sowas wie virtio?

[PatiB87]

Hey,

das ist ja schon mal interessant.
Ich habe das Netzwerk der VMs so eingestellt, dass sie direkt im LAN als Rechner zu sehen sind, also gebrückt.

Mh, ja, Netzwerkarbeit leisten alle, sozusagen, aber dass das bei den anderen VMs so viel höher sein soll finde ich schon komisch. :/

Hmm..
Wenn ich deine Zeile Code ausführe sehe ich, dass das NET_RX bei der NICHT betroffenen VM um 100 pro 10s steigt, bei der betroffenen um 20.000....

[reox]

Wenn ich deine Zeile Code ausführe sehe ich, dass das NET_RX bei der NICHT betroffenen VM um 100 pro 10s steigt, bei der betroffenen um 20.000....

Dann scheint die betroffene wohl um einen faktor 200 mehr Pakete zu bekommen.
Ist das tatsächlich so? Was rennt denn da drauf?
Du kannst mal mit iptraf oder iftop oder vnstat oder ... schauen woher der traffic kommt. Iptraf hat den vorteil, dass es auch die pakete zählen kann - hier gehts wohl genau darum.

Ich habe das Netzwerk der VMs so eingestellt, dass sie direkt im LAN als Rechner zu sehen sind, also gebrückt.

Bei Virtualbox kannst du ja verschiedene Netzwerkkartentreiber auswählen. Hat das irgendeinen Einfluss?
Ich meinte eigentlich ob es bei Virtualbox auch Netzwerkkartentreiber gibt die nicht in Software emuliert sind - jedenfalls gibts die virtio sachen auch dort: https://www.virtualbox.org/manual/ch06.html
Schau mal ob "Paravirtualized network adapter (virtio-net)" für alle VMs aktiviert ist.

[PatiB87]

PLOT TWIST:
Auf einmal ist die Last deutlich niedriger bzw. die "rote" Kernellast in htop einfach WEG...

Ich liebe es...
Was war es? => KEINEN Schimmer.
Was hab ich geändert => 1-2 Router im LAN ersetzt um mehr WLAN-Power zu haben. Die VMs hängen zwar nicht im WLAN, aber vielleicht haben diese Router ja auf den VMs irgendwie die ganze Zeit Ports abgefragt oder weiß der Geier...
Vielleicht wurde ich auch gehackt, wer weiß...

Wirklich frustrierend, so ein doch relativ schwerwiegendes Problem aus dem Nichts zu haben und es einfach wieder verschwinden zu sehen.

Ich danke euch sehr für die Hilfe! Wenn es wieder auftritt werde ich den Thread nochmal wiederbeleben.

[reox]

PLOT TWIST:
Auf einmal ist die Last deutlich niedriger bzw. die "rote" Kernellast in htop einfach WEG...

zwischendurch neu gestartet?

Glaube nicht das es an Netzwerkkomponenten lag, dann hätten ja alle VMs das abbekommen (vermutlich)

[PatiB87]

Ich habe zwischendurch als Test alles neugestartet. Router, VMs, VM-Supervisor, die verbundenen Geräte, alles...

Der Router hat aber, wie ich nun festgestellt hab, auch tatsächlich schon gesponnen. Auf 2,4GHz war sein WLAN nicht verbindbar, auf 5GHz lief super.

Ein guter Schritt zum Debuggen ob diese Kernel-Last vom LAN kam wäre noch gewesen:
1. IPs der VMs ändern (tauschen?) => Man sieht ob die Anfragen IP-Abhängig waren
2. Den VM-Supervisor aus dem LAN nehmen und sich mal direkt mit nem Laptop dran hängen um zu sehen, ob die Last/Zugriffe damit verschwinden.

Aber nun ist der Spuk ja scheinbar vorbei.
Mein gesamtes Netzwerk funktioniert nun wieder so wie man es erwartet und wie es soll.

[reox]

Ich habe zwischendurch als Test alles neugestartet. Router, VMs, VM-Supervisor, die verbundenen Geräte, alles...

Ja ok - damit hast du das Experiment unterbrochen

Ich kann mir gut vorstellen, dass das Problem durch einen Neustart temporär gelöst werden kann. Wenn es nochmal auftaucht weißt du aber was du alles testen kannst.
Kannst natürlich auch mal testen was passiert wenn du die VM mit vielen Paketen konfrontierst. hping3 ist da ein nettes spielzeug - musst nur aufpassen es nicht zu übertreiben, ein Windows XP/7 fror damit immer gerne ein

[PatiB87]

Nein, ich meinte: Ich habe schon Do/Fr, als die Probleme auftraten nach und nach alles neugestartet. Das gesamte LAN inkl. DHCP-Addressvergabe hat tatsächlich gesponnen bis der Speedport Smart 1 (welcher auf 2,4GHz auch schon gesponnen hat) aus dem LAN raus war.

Das wiederum teste ich quasi am Supervisor gelegentlich, da läuft ein iPerf3-Server mit dem ich hier und da meine Netzwerkperformance messe. Aber ja, auch gute Idee!