Instabiler RS 2000 G7SE 15 years

  • Hallo,


    mein neuer RS 2000 G7SE 15 years ist sehr instabil. Ich wurde bereits zweimal auf einen anderen Node verschoben. Das System, Debian Stretch unter 3.14.51-grsec, lief auf dem Root-Server M SSD v6 ohne Probleme. Dies wurde per RSync in der Recovery-Console auf das neue System kopiert und nur die IP-Addresse /etc bzw. die fstab entsprechend angepaßt.


    Da ich vermutet habe, das der Kernel mit dem neuen Server nicht richtig zusammenläuft, habe ich den Kernel auf 4.11.8 aktualisiert. Trotzdem bekomme ich noch ständig Kernel-Meldungen wie

    Code: /etc/sysctl.conf
    1. vm.dirty_background_ratio=5
    2. vm.dirty_ratio=10
    3. kernel.perf_event_paranoid=3
    4. kernel.sched_min_granularity_ns=10000000
    5. vm.swappiness=10
    6. kernel.sched_wakeup_granularity_ns=15000000
    7. kernel.sysrq=1
    8. kernel.dmesg_restrict=1

    Code: /etc/default/grub
    1. GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=noop nohz=off"

    (durch das weglassen von nohz=off gibt es keine Verbesserung)

    NC#2017070510003676 und NC#2017070310000315

  • Guten Morgen,


    ich habe Ihren Beitrag mal ins richtige Forum verschoben.


    Im Ticket schreiben Sie, dass sich das Problem durch ein Kernel-Downgrade behoben hat und wir nichts weiter unternehmen sollen. Ist das der aktuelle Stand?



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Felix,


    sorry wegen dem falschem Bereich.


    Leider ist es nicht mehr der aktuelle Stand. Kurz nach meiner Mail ist wieder ein Kernelfehler aufgetreten


  • Guten Tag,


    das die Root-Server v6 andere CPUs hatten als die G7 ist Ihnen bekannt? Je nachdem welche Software Sie einsetzen kann diese durchaus CPU-spezifisch kompiliert oder konfiguriert worden sein. Wenn Sie dann einfach das System verschieben, kann das unter Umständen zu einem solchen Verhalten führen. Bei SuSE wird der Grund des Kernelpanics recht gut erklärt: https://www.suse.com/de-de/support/kb/doc/?id=7017652


    Weitere Ursachen kann ein unsauberer Transfer sein.


    Die Ursachen eines unsauberen Transfers können Sie reduzieren, in dem Sie mit einfacheren Methoden als mit rsync transferieren. Bsp. dd oder am besten über ein Imageabbild. Eine weitere Möglichkeit wäre das System neu zu installieren, inklusive der Software und nur die statischen und Nutzer-Daten zu kopieren.


    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Felix,


    das eine andere CPU vorhanden ist weiß ich. Ich nutze jedoch nur Debian Pakete und gehe davon aus, dass diese für alle CPUs kompiliert sind.

    Den Transfer werde ich mal mit eine rsync -avcn mit dem Ursprungsserver vergleichen. Dann sollte ich ja Transferfehler finden.

  • Guten Tag,



    nachdem sich ein zweiter Kunde jetzt mit dem gleichen Problem auf dem gleichen Node gemeldet hat und wir die Probleme an Testsystemen nachstellen konnten, migrieren wir jetzt alle Systeme von den Nodes herunter, die in der gleichen Charge produziert wurden. Ihr zuvor genutzter Node war leider auch aus der selben Produktions-Charge. Hier scheint wirklich ein Fehler an den CPUs oder Mainboard vorzuliegen. Baugleiche Systemen, die auch genau den gleichen Software- und Firmwarestand nutzen jedoch aus einer anderen Charge kommen, haben nicht die hier beschriebenen Probleme.


    Wir haben generell jede Hardware mindestens 24 Stunden in einem internen Stresstest bevor sie zum Einsatz kommt. Leider waren die Fehler hier nicht ersichtlich.


    Wir bedauern, dass wir nicht früher den Fehler erkennen konnten.



    Mit freundlichen Grüßen


    Felix Preuß

  • Schlechte Nachrichten: Bei mir ist der Fehler immer noch nicht weg:


    Code
    1. [Do Jul 6 21:25:53 2017] INFO: rcu_sched self-detected stall on CPU
    2. [Do Jul 6 21:25:53 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    3. [Do Jul 6 21:25:53 2017] 3-...: (1 GPs behind) idle=989/2/0 softirq=2030585/2030587 fqs=1088
    4. [Do Jul 6 21:25:53 2017] (detected by 2, t=11699 jiffies, g=990911, c=990910, q=214)
    5. [Do Jul 6 21:25:53 2017] Task dump for CPU 3:
    6. [Do Jul 6 21:25:53 2017] swapper/3 R running task 0 0 1 0x00000008
    7. [Do Jul 6 21:25:53 2017] 000000010038da44 0000000000000000 0000000000000000 0100000000000000
    8. [Do Jul 6 21:26:21 2017] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [mysqld:2737]

    Code
    1. [Do Jul 6 21:37:04 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    2. [Do Jul 6 21:37:04 2017] (detected by 1, t=5500 jiffies, g=1026740, c=1026739, q=523)
    3. [Do Jul 6 21:37:04 2017] All QSes seen, last rcu_sched kthread activity 5419 (4298868344-4298862925), jiffies_till_next_fqs=1, root ->qsmask 0x0
    4. [Do Jul 6 21:37:42 2017] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [swapper/3:0]


    Auffällig ist auch die Munin Auswertung der CPU. Wenn es ein Kernel-Fehler gibt bricht die CPU komplett ein. Das gleiche gilt, wenn die CPU belastet wird ...

  • SCD: Wie sieht es denn aus, wenn du deinen Server für ein paar Stunden im Rettungsmodus oder mit einem frisch installierten Betriebssystem laufen läßt? Bekommst du dann auch diese Fehlermeldungen?

  • ... Den Transfer werde ich mal mit eine rsync -avcn mit dem Ursprungsserver vergleichen. Dann sollte ich ja Transferfehler finden.


    Nach dieser Mitteilung hatte ich angenommen, dass du vernünftigerweise den neuen Server erst einmal auf Herz und Nieren testest und dann wenn er wie gewünscht läuft, produktiv einsetzt.

  • Leider nicht. Wer geht auch davon aus, das der neue Server so eine Macke hat. Zum Glück gibt es noch den alten und ich kann mit etwas Aufwand zurück.

    Da der alte aber nur ein Dual-Core ist, möchte ich dies gerne vermeiden.

  • Nur ein Vorschlag: Den alten Server würde ich an deiner Stelle noch solange produktiv nutzen, bis der neue Server so läuft wie gewünscht. Denn der Vorteil ist der, dass du dann deinen neuen Server viel entspannter bzw. schmerzfreier testen kannst und du dadurch nicht so unter einem hohen Zeitdruck stehst.

  • Werde am Wochenende wahrscheinlich auch wirklich erstmal wieder zurückziehen.


    Hoffe nur das netcup das Problem im Griff bekommt, da der alte zum 01.08 gekündigt ist und sonst ein komplettes Jahr verlängert wird.

  • Hoffe nur das netcup das Problem im Griff bekommt, da der alte zum 01.08 gekündigt ist und sonst ein komplettes Jahr verlängert wird.

    Da man im ersten Monat seinen neuen Root-Server wegen der Unzufriedenheitsgarantie wieder kündigen kann, würde ich an deiner Stelle den jetzigen neuen Root-Server wieder kündigen - sofern Dieser auch eine Laufzeit von 12 Monaten hat - und einen neuen Root-Server mit einer Laufzeit von einem Monat neu bestellen. Da der Preisunterschied pro Monat nur 2 Euro beträgt.

  • Guten Morgen,



    es gibt ein wichtiges Update:


    Nachdem von der Problematik nur recht leere Nodes betroffen waren, auch die neuen die wir jetzt als Alternative bereitgestellt hatten, haben wir weitere Nachforschungen angestellt. Dabei ist herausgekommen, dass vermutlich ein Power-Save-Modus der neuen Intel (R) CPUs für das Phänomen verantwortlich sein kann. Dieser wurde durch Firmwareupdates vermutlich aktiv und konnte ab da von den Wirtssystemen gesteuert werden. Eventuell ist auch eine Änderung im Debian-Kernel dafür verantwortlich. Zuvor galt das, was wir im BIOS vorgegeben haben, nämlich das der Power-Save-Modus deaktiviert ist. Die CPUs wurden durch diese Änderung zum Teil auf 1,2 GHz herunter getaktet, wenn sie nicht genutzt wurden. Das haben wir jetzt geändert, in dem wir den Gouvernor auf "performance" gesetzt haben.


    Im Lauf des Tages rollen wir diese Änderung vorläufig auf allen neuen Systemen aus.


    Rückmeldungen sind willkommen.



    Mit freundlichen Grüßen


    Felix Preuß