Beiträge von SCD

  • Das längste Thema

    Folgende Aussagen gibt es bereits:

    Zitat von [netcup] Felix

    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.

    Zitat von [netcup] Felix

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

  • Mining auf vServer erlaubt?

    Nicht ganz richtig:

  • Instabiler RS 2000 G7SE 15 years

    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

  • Instabiler RS 2000 G7SE 15 years

    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.

  • Instabiler RS 2000 G7SE 15 years

    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.

  • Instabiler RS 2000 G7SE 15 years

    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:

  • Instabiler RS 2000 G7SE 15 years

    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)

  • 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.

  • Instabiler RS 2000 G7SE 15 years

    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.

  • Instabiler RS 2000 G7SE 15 years

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

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

  • Instabiler RS 2000 G7SE 15 years

    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.