Root-Server "self-detected stall on CPU"

    Hallo! Beim einloggen in's SCP habe ich nun wiederholt einen Satz Meldungen wie diese auf der virtuellen Konsole vorgefunden:

    netcup_cpu_stall.png

    Negative Auswirkungen auf den Betrieb konnte ich keine festellen. Trotzdem wüsste ich gerne, was es damit auf sich hat, und ob ich etwas dagegen tun kann oder sollte. Generell bin ich mit Linux gut vertraut, allerdings nicht mit Kernel-Interna. Auf dem Server läuft Debian 10.10.

    Zitat von Bachsau

    Trotzdem wüsste ich gerne, was es damit auf sich hat, und ob ich etwas dagegen tun kann oder sollte.

    Auf deinem virtuellen Server kannst du nach meiner Meinung leider nichts machen, da jeder vCore ein Prozess auf dem Wirt ist.

    Ist der Wirt vereinfacht gesagt überlastet, so beantwortet er auch die Anfragen nach einem oder mehreren vCores gerade nicht und deine virtuelle Maschine zeigt dann über die Konsole einen sogenannten Time Out (CPU-Time) an.

    Aber eventuell irgendwann bekommt auch deine virtuelle Maschine ihre sogenannte CPU-Time. Wenn nicht, wird sie einfach vom Wirt als als störenden Prozeß pro vCoure gesehen und im ungünstigsten Fall einfach abgeschossen.

    Um das Problem beseitigt zu bekommen, solltest du am besten ein Ticket eröffnen.

    Afaik können solche Meldungen auch bei einer Live-Migration auf ein anderes Hostsystem auftauchen.

    Auszug einer Mail aus den letzten Tagen:

    Zitat

    […]

    um die Stabilität Ihres Systems weiterhin kontinuierlich gewährleisten zu können, ist es dringend nötig, dass wir Ihren Server vXXXXXXXXXX auf ein anderes Wirtssystem verschieben.

    Wir führen dies zum Schutz Ihrer Daten und zur Gewährleistung des regulären Betriebs Ihres Servers durch. Die Migration ihres Servers startet binnen der nächsten 24 Stunden. Dabei wird Ihr Server einmalig neu gestartet.

    Wir empfehlen grundsätzlich, Snapshots zu entfernen, wenn diese nicht benötigt werden. Im Regelfall erlaubt uns dies, Ihren Server live umzuziehen, so dass kein Neustart erforderlich ist. In Ausnahmefällen ist es dennoch notwendig, dass wir einen solchen durchführen, dann informieren wir Sie selbstverständlich zuvor, so wie in diesem Fall.

    Man beachte den letzten Absatz. Ich verstehe den so, dass man solche Mails gar nicht erhält, wenn eine Live-Migration möglich ist. ;)

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

    Wenn man die Kerne nicht dauerhaft frei hält, kann es sicher immer mal eine kurze Zeit dauern, bis Takte verfügbar sind, selbst bei einem Root-Server. Die Leistung wird zwar zugesichert, aber ich glaube nicht, dass Netcup die Leistung ungenutzt lässt, wenn sie von der VM gerade nicht benötigt wird. Ich war/bin mir nur nicht sicher, ob diese "Stalls" von außerhalb kommen, oder ob es evtl. (Kernel-)Parameter gibt, die ich optimieren kann. Hier steht einiges dazu, vor allem auch "To diagnose the cause of the stall, inspect the stack traces. The offending function will usually be near the top of the stack." Allerdings ist besagter Stack Trace nicht gerade ergiebig:

    Entweder bin ich zu blöd, das zu verstehen, oder es gibt keine "offending function", weil die Verzögerung tatsächlich von außerhalb der VM kommt. Dass er in einer VM läuft, weiß der Kernel aber, wie man aus den Boot-Meldungen ersehen kann:

    Code
    Aug 24 22:29:41 aster kernel: [    0.000000] Hypervisor detected: KVM
Aug 24 22:29:41 aster kernel: [    0.102426] Booting paravirtualized kernel on KVM

    Daher denke ich, dass er sich eigentlich anpassen müsste, falls sowas für eine VM normal ist. Übrigens treten diese Meldungen ein bis zwei mal pro Woche auf, so dass man Live-Migration wohl ausschließen kann.

    Zitat von Bachsau

    Übrigens treten diese Meldungen ein bis zwei mal pro Woche auf, so dass man Live-Migration wohl ausschließen kann.

    Ok, das spricht dann doch etwas gegen meine Vermutung. Bei einem VPS würde ich es nicht gänzlich ausschließen, aber bei einem RS wäre das mit dieser Häufigkeit in der Tat unüblich.

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