Instabiler RS 2000 G7SE 15 years

  • Hier die letzten Fehler nach dem letzten Reboot (Debian 4.9.30-2+deb9u2 / vm.dirty_background_ratio=5 / vm.dirty_ratio=10 / GRUB_CMDLINE_LINUX_DEFAULT="")

    Code: /var/log/kern.log
    Jul  9 07:41:08 srv1 kernel: [41126.876271] INFO: rcu_sched detected stalls on CPUs/tasks:
    Jul  9 07:46:49 srv1 kernel: [41466.118461] INFO: rcu_sched detected stalls on CPUs/tasks:
    Jul  9 08:02:52 srv1 kernel: [42415.823864] INFO: rcu_sched detected stalls on CPUs/tasks:
    Jul  9 08:03:57 srv1 kernel: [42502.464281] INFO: rcu_sched detected stalls on CPUs/tasks:
    Jul  9 08:10:17 srv1 kernel: [42866.906511] INFO: rcu_sched detected stalls on CPUs/tasks:


    Der Server hat zu diesen Zeiten nicht auf Anfragen reagiert.


    Hoffentlich wird von Netcup noch an den Fehler gearbeitet.

  • Und der nächste:


    Code
    [So Jul  9 18:36:22 2017] INFO: rcu_sched detected stalls on CPUs/tasks:

    Gerade etwas im Internet gefunden, was eventuell zutreffen könnte: Frequent CPU stalls in KVM guests during high IO on host


    Die Disk latency per device geht bei mir extrem hoch (stellenweise über eine Sekunde)

  • Hallo,


    ich habe seit etwa 11:30 ein start erhöhter IO-Wait, wobei der Server um 11:21 wohl neugestartet hat.

    Wird jetzt ein IO Last-Test auf dem Node durchgeführt ?


    Code
    [Mo Jul 10 12:03:13 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    [Mo Jul 10 12:03:39 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    [Mo Jul 10 12:06:46 2017] INFO: rcu_sched self-detected stall on CPU
    [Mo Jul 10 12:06:46 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
  • Hallo,


    ich wurde nun auf einen neuen Node mit "ein paar anderen Hardwareeinstellungen" verschoben. Seit dem habe ich keine Schwierigkeiten mehr.

    Jedoch sind die Fehler auf dem alten Node auch unregelmäßig gekommen - deshalb gebe ich noch keine Entwarnung.


    Meine Sorge ist nun, was passiert wenn der neue Node wieder stärker gefüllt wird.

    Tauchen dann die Probleme wieder auf oder sind es wirklich die anderen Einstellungen.


    Vielleicht kann sich Felix oder der Support dazu mal äußern.


  • Guten Morgen,


    wir haben die letzten Tage viel probiert um das Problem zu reproduzieren. Nachdem wir ein ähnliches Problem auf Nodes mit aktivierten Powersave-Governor nachstellen konnten, hatten wir die Hoffnung die Ursache gefunden zu haben. Für andere betroffene vServer scheint das auch die Ursache gewesen zu sein. Zumindest hat sich seit der Umstellung des Governors kein anderer Kunde mehr diesbezüglich gemeldet und auch auf unseren Testsystemen sind die Probleme nicht mehr aufgetreten. Selbst auf zu 100% gefüllten Nodes auf denen alle Testsysteme massive Last erzeugt haben, konnten wir das zuletzt geäußerte Phänomen nicht nachstellen.


    Es gibt allerdings mehrere mögliche Ursachen die wir jetzt eingrenzen konnten. Weitere Tests nehmen wir hierzu in unserer internen Testumgebung vor. Viel deutet auf ein Zusammenspiel zwischen Wirt-Kernel, Qemu und Gast-Kernel hin. Das wird auch dadurch bestätigt, dass das Problem bei Ihnen bislang nicht mehr aufgetreten ist.


    Sobald wird mehr wissen, werde ich berichten.


    Mit freundlichen Grüßen


    Felix Preuß

  • Neuer Zwischenstand:


    Keine Stalls, Stucks und dovecot jumped mehr.


    Jedoch ist ab 13:00 Uhr die Steal-Time auf über 35% (von 400%) gestiegen und hat sich jetzt auf 10% eingependelt.

    Vor 13 Uhr war die unter 1%.


    Die Disk latency hat sich seit 13 Uhr auf 170m auch leider verdoppelt.

  • Guten Tag,



    es freut uns zu hören, dass die Stucks jetzt nicht mehr auftreten. Zur Sicherheit haben wir gerade den von Ihnen aktuell genutzt Node mit Testsystemen künstlich ans oberste Limit getrieben. Der Test wird gleich beendet sein.



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo,


    laut munin war der Test um 16:30 beendet. Wenn Sie dies stimmt, kann ich bestätigen, dass die Maßnahmen ein voller Erfolg waren.

    Keine Fehler im Kernel-Log und auch kein jumped von Dovecot. Nun kann ich wohl wieder ruhiger schlafen ;)


    Nun warte ich auf die Antwort vom Ticket 2017070110004422

  • Guten Tag,

    ich hatte mich ebenfalls über den E-Mail-Support mit dem gleichen Problem bei Ihnen gemeldet. Leider besteht das Problem bei mir nach wie vor. Mein Server sollte auch auf eine andere Node migriert werden. Wie ist denn da der aktuelle Stand?


    2017-07-17 10_31_25-VNC Console.png

  • Guten Tag,



    die Problemursache konnte erfolgreich beseitigt werden. Sollten die Probleme in Einzufällen nochmal auftreten, wenden Sie sich bitte direkt an unseren Support.


    Vielen Dank!



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo,


    hier ein Langzeitbericht: Der Server läuft nun knapp 64 Tage stabil.


    Es gibt nur zwei Meldungen im Kernel-Log die mir etwas komisch vorkommen, jedoch keine sichtbaren Auswirkungen haben:


    Code
    [Mi Jul 12 12:50:21 2017] TCP: ens3: Driver has suspect GRO implementation, TCP performance may be compromised.
    [Di Sep 12 06:45:01 2017] hrtimer: interrupt took 19561754 ns


    Leider hat sich die Disk-Latency aber erheblich verschlechtert. Sie liegt im Durchschnitt bei 200 ms und stellenweise bei 1s.


    ----


    Der Server v22016103897838572 meines Arbeitgebers, welchen ich ebenfalls betreue und aus der gleichen Reihe stammt hat jedoch ähnliche Probleme wie meiner früher:



    Jede dieser Meldungen hatte eine Load von über 100 zur Folge weshalb der Server nicht verfügbar war.


    Er wurde vor 42 Tagen migiert, was leider einen Ausfall von knapp einer Stunde verursacht hat (auf dem alten Node wurde er schon beendet und erst nach etwa Stunde auf den neue Host gestartet - Meldung war damals "Server Informationen konnten nicht ermittelt werden".


    Wurde eventuell die Host-Anpassungen von meinen Node v22017072950850975 bei Host vom v22016103897838572 nicht durchgeführt ?

  • Hallo,


    das Problem ist leider wieder da :(


    Ich vermute einen Zusammenhang mit dem aktuellen Kernel-Upgrade (https://www.debian.org/security/2018/dsa-4120) von Debian Strech, da es nach einspielen und Reboot aufgetreten ist. Eine Migration auf einen anderen Host hat schon stattgefunden (NC#2018022510002521).



  • Am neuen Kernel liegt es schonmal nicht. Trotzdem Downgrade ist der Fehler heute wieder aufgetreten.

    Auffällig ist die Uhrzeit: Immer 18:47 (auf dem neuen Host) und 11:48 (auf dem alten Host).

    Sieht irgendwie nach einen Cron-Job aus, der auf dem Wirt läuft ?!?

  • Moin allerseits,


    bei mir tritt das Problem auch auf. Habe einen RS 1000 gemietet. Uhrzeit war 00:41 Uhr. Bin noch relativ neu und habe deshalb nichts außer einem TS3 laufen.

    Code
    $ cat /etc/os-release
    PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
    [...]


    Ich hoffe, dass sich das Problem irgendwie beheben lässt, der Server wird bald produktiv genutzt.


    Gruß


    s4Ne

  • Hallo,


    ich bin mir nicht ganz sicher, was Du mit Systemeinstellungen meinst. An den zwei genannten Dateien habe ich nichts geändert. Aktuell habe ich nicht mal eine .service-Datei für TS3 angelegt, sondern das Ding mit eingeschränkten Rechten in einer screen-Sitzung laufen. Ansonsten auch nur normale Umkonfigurationen zur Systemhärtung, z. B. /etc/ssh/sshd_config. Nichts, von dem ich erwarten würde, dass es einen solchen Fehler verursacht.


    Interessanterweise trat der Fehler bis jetzt auch nicht mehr auf, ist also nicht so periodisch, wie von Dir beschrieben.


    Gruß


    s4Ne