Beiträge von SCD

    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
    [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:

    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)

    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.

    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.

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

    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.

    Hallo Felix,


    sorry wegen dem falschem Bereich.


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


    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
    vm.dirty_background_ratio=5
    vm.dirty_ratio=10
    kernel.perf_event_paranoid=3
    kernel.sched_min_granularity_ns=10000000
    vm.swappiness=10
    kernel.sched_wakeup_granularity_ns=15000000
    kernel.sysrq=1
    kernel.dmesg_restrict=1

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

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

    NC#2017070510003676 und NC#2017070310000315

    Was möglich wäre, ist eine persönliche Statusübersicht im CCP. Das bedarf allerdings ein wenig Arbeit bei uns.

    Wie wäre es mit einem RSS-Feed ?


    Durch die Anmeldung per HTTP-Auth könnten dann gleich die persönlichen Meldungen angezeigt werden.

    Und eine automatische Weiterverarbeitung steht auch nichts im Wege ;)

    Mein Plan ist/war eigentlich am 31.07 ein Komplett-Backup zu erstellen und am 01.08. den neuen Server zu bestellen.


    Auf diesen erfolgt dann ein Restore des Komplett-Backups, Anpassung der IP-Adressen und per RSync werden die letzten Änderungen vom gekündigten Server (home / mail / mysql / logs) kopiert. Anschließend wird die DNS geändert (TTL wird hier ein paar Tage vorher auf 60 gesetzt) und eine Weiterleitung der alten IP auf die neue (iptables) angelegt.


    Netcup stellt ja den neuen Server am gleichen Tag bereit. So sollte der Umzug in ein bis zwei Stunden erledigt sein und der tatsächliche Ausfall sich auf vielleicht 15 Minuten beschränken.


    Hallo,


    ich habe einen Server wegen eines Produktwechsels gekündigt. Im CCP steht:


    Für dieses Produkt ist eine Kündigung zum 02.08.2017 vorgemerkt


    Welche Aussage stimmt nun

    1. der Server wird am 01.08.2017 um 23:59:59 deaktiviert
    2. der Server wird am 02.08.2017 um 23:59:59 deaktiviert
    3. der Server wird am 02.08.2017 irgendwann im Laufe des Tages deaktiviert
    4. ...

    Hallo,


    habe das seit gestern das gleiche Problem. Nutze einen Server als Monitoring und der schlägt öfter Alarm:


    22:20 Uhr, 22:55 Uhr, 23:06 Uhr, 0:27Uhr, 1:17 Uhr, 1:51 Uhr, 3:42 Uhr, 5:06 Uhr, 6:12 Uhr


    Ich lasse jetzt auf den Server (noch im Normal-Mode) MTR laufen. Als Gegen-Server einen weiteren bei Netcup. Mal sehen was passiert.

    Zu dem habe ich eine andere Art Frage, wird für den DDoS Schutz eigentlich ein gesonderter Vertrag mit dem Kunden geschlossen oder ist dieser bereits bei allen Verträgen ein Bestandteil?

    Ist immer dabei. Bei mir wurde dieser schon aktiv, obwohl kein gesonderter Vertrag abgeschlossen wurde.