Plötzlich 100% auf allen Kernen, aber kein Thread über 0.7% ?

  • Hallo Zusammen,


    ich habe grad vor Schreck erst mal meinen RS2000 runtergefahren.. 8|


    Was ist denn da los?


    Egal ob top, htop oder - wie im Screenshot - bashtop, überall habe ich 100% CPU-Auslastung, obwohl die Kiste quasi im Idle ist und die Threads max 0.7% haben (abwechselnd).


    Auch nach mehreren Reboots bzw. runterfahren aller Container bleibt das so. :/


    Gruß, Kris


    Screenshot 2022-04-20 115620.jpg

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

  • Zur hilfreichsten Antwort springen
  • VPS oder RS? Sorry, steht eh da… X/


    Da ich die Ausgabe von bashtop nicht kenne: Weißt Du noch, was an der CPU-Auslastung anteilsmäßig angeblich am Höchsten war? (Kernel, IRQ, Steal, IO, …)


    Boote das System doch mal übers SCP ins Rettungssystem und wirf dort einen Blick auf htop.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 ()

    Gefällt mir 1
  • Das Rettungssystem funktioniert nicht, vielleicht weil ich nicht den Standardport für SSH nutze..


    Hab nochmal normal gebootet und htop gemacht...

    Screenshot 2022-04-20 123921.jpg


    Von dem Prozess php-fpm: pool www gibt es mehrere. Ich habe nur Docker-Container und keine anderweitigen Webserver installiert. Selbst wenn ich alle Container stoppe, bleiben die Prozesse aktiv.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

  • Das Rettungssystem funktioniert nicht, vielleicht weil ich nicht den Standardport für SSH nutze..

    Das Rettungssystem (nicht der Recovery-Modus Deines eigenen Systems!) ist ein eigenständiges OS, das übers Netzwerk gebootet wird. Das muss funktionieren, sofern Netzwerk als erste Boot-Option ausgewählt und es im SCP aktiviert wird.


    Laut der Farbe in htop ist das von steal/guest. Wenn das im Rettungssystem genauso aussehen sollte, läuft da irgendwas am Hostsystem schief. Falls nicht, muss man weiter nach der Ursache suchen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

    Gefällt mir 3
  • Ist aber alles von eben und ohne dass ich zwischendurch was verändert habe.


    Übrigens laufen alle meine Anwendungen subjektiv normal, also "ohne Bremse".


    Ich habe mal ein Ticket aufgemacht.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

  • Ist aber alles von eben und ohne dass ich zwischendurch was verändert habe.

    So war es auch nicht gemeint! Sorry für die missverständliche Formulierung :)


    Eher so: Das passt nicht zusammen, da schrillen die Alarmglocken. Muss nicht sein, aber das sieht definitiv komisch aus.


    Ich habe mal ein Ticket aufgemacht.

    Ohne einmal ins Rettungssystem gebootet zu haben? Mutig…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 ()

    Gefällt mir 1
  • So war es auch nicht gemeint! Sorry für die missverständliche Formulierung :)


    Eher so: Das passt nicht zusammen, da schrillen die Alarmglocken. Muss nicht sein, aber das sieht definitiv komisch aus.


    Ohne einmal ins Rettungssystem gebootet zu haben? Mutig…

    Bin halt neu hier.. ich konnte jetzt das Rettungssystem starten.

    Ich wette die erste Antwort wird sein: "Kann man das im Rescue System nachstellen?"

    kann man nicht, da sieht bei htop alles normal aus.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

    Gefällt mir 1
  • Dann muss irgendwas mit deiner Installation Murks sein. Weißt du denn was du zuletzt geändert hast?
    Lass mich raten... garnix? :)

    Genau, garnix :wacko:


    Zumindest nicht in der letzten Woche. Und das Phänomen war gestern Abend noch nicht.

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

  • Hast du mal geguckt, ob es irgendwelche SSH Logins gab, die nicht von dir kamen?

    Gab es nicht, sollte auch nicht möglich sein, da Login nur per Zertifikat..

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11

    Gefällt mir 1
  • Also mpstat zeigt ja auch 6 running processes. Mach doch mal top und toggle die Sortierung nach CPU-Last mit 'P'.

    Und 'pidstat 1' sollte die Prozesse anzeigen.


    Nette Liste: https://netflixtechblog.com/li…milliseconds-accc10403c55

    Bei top sind ein paar PIDs, alle vom user 911 (müsste Docker sein?!), die wechseln sich ab, immer um die 10% CPU-Last.. Prozess ist bei allen php-fpm7


    Aber das läuft ja schon seit Wochen unverändert so..

    Mach doch bitte mal `

    Code
    ps ax -o pid,ni,cmd

    `

    und guck nach Prozessen mit positivem „nice“-Wert.

    Die meisten haben 0 , eine Handvoll -20 und 2 positive:


    Code
     55   5 [ksmd]
     56  19 [khugepaged]

    RS 3000 G9.5 SE auch genannt OST22 L - 24 GB RAM, 8 Kerne, AMD Epyc, 960 GB SSD

    Webhosting 8000 SE BF22

    Neues Spielzeug: VPS 1000 ARM G11