Beiträge von SCD

    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
    1. [Mi Jul 12 12:50:21 2017] TCP: ens3: Driver has suspect GRO implementation, TCP performance may be compromised.
    2. [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 ?

    Mach mal bitte nach dem Neustart


    Code
    1. ip -6 route show

    Und wenn die IPv6 weg ist

    Code
    1. ip -6 route add default via fe80::1 dev ens3

    Geht es dann wieder ohne Neustart ?

    Folgende Aussagen gibt es bereits:

    Aus dem Grund raten wir selber dazu die Generation 7 bzw. Generation 7 SE zu nutzen, wenn wirklich ein sehr guter IO-Durchsatz gewünscht wird. Generation 6 ist ja nun schon etwas in die Jahre gekommen. In einigen Monaten folgt Generation 8. Die Generation wird nochmal einen großen Leistungsschub bekommen, wenn auch weniger im IO-Bereich.

    Die Generation 8 könnte ja z.B. auf CPUs von AMD laufen ;-)

    Nicht ganz richtig:

    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

    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.

    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.


    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
    1. [Mo Jul 10 12:03:13 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    2. [Mo Jul 10 12:03:39 2017] INFO: rcu_sched detected stalls on CPUs/tasks:
    3. [Mo Jul 10 12:06:46 2017] INFO: rcu_sched self-detected stall on CPU
    4. [Mo Jul 10 12:06:46 2017] INFO: rcu_sched detected stalls on CPUs/tasks:

    Und der nächste:


    Code
    1. [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)

    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
    1. Jul 9 07:41:08 srv1 kernel: [41126.876271] INFO: rcu_sched detected stalls on CPUs/tasks:
    2. Jul 9 07:46:49 srv1 kernel: [41466.118461] INFO: rcu_sched detected stalls on CPUs/tasks:
    3. Jul 9 08:02:52 srv1 kernel: [42415.823864] INFO: rcu_sched detected stalls on CPUs/tasks:
    4. Jul 9 08:03:57 srv1 kernel: [42502.464281] INFO: rcu_sched detected stalls on CPUs/tasks:
    5. 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.

    Dateien

    • cpu-day.png

      (23,13 kB, 8 Mal heruntergeladen, zuletzt: )

    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.

    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.