V-Server wiederholt nicht erreichbar

  • Der drop_caches Cronjob kann dann aus der "/etc/cron.d/kernel" entfernt werden.


    Ist bei mir nicht vorhanden, da über ISO installiert.


    Die Tips aus dem Wiki habe ich schon eingebaut, aber scheinen auch nicht zu helfen.


    Jep, haben bei mir vor einigen Tagen auch nichts gebracht.


    Gabs schon Kontakt zum Support?


    Nein, weil ich es aktuell nicht mehr reproduzieren kann, trotz altem Kernel. Ich beobachte noch weiter. Es wäre zwar schön, wenn das Problem genauso plötzlich verschwindet, wie es aufgetreten ist, aber im Moment traue ich der Ruhe noch nicht.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Nein, weil ich es aktuell nicht mehr reproduzieren kann, trotz altem Kernel. Ich beobachte noch weiter. Es wäre zwar schön, wenn das Problem genauso plötzlich verschwindet, wie es aufgetreten ist, aber im Moment traue ich der Ruhe noch nicht.

    Ich habe eben den Support angeschrieben, mal schauen ob von dort was kommt.


    Hab ich das richtig verstanden du hast einen aelteren Kernel installiert und damit laeuft es bis dato? Bei mir tritt das Problem mehrmals am Tag auf, welche Kernelversion hast du verwendet?

  • Nein, ich meinte, dass ich noch keinen neueren Kernel aus Backports installiert habe, wie ursprünglich angedeutet. Es ist immer noch der Standard Distributionskernel von Debian 8.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich will es nicht verschreien, aber weiterhin keine Probleme mehr, ohne Änderung meinerseits.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Mittlerweile wurde meine Maschine auf einen anderen Node verschoben, damit ist es etwas besser geworden, aber trotzdem stuerzen meine virtualisierten Maschinen immer noch ab. Nicht mehr ganz so haeufig, aber es ist trotzdem noch nervig :(


    Ist es bei dir jetzt stabil geblieben KB19?

  • Zumindestend laufen die VMs laut Monitoring immer noch und die MySQL-Daemons reagieren. Abstürze gab es somit keine mehr. Ich muss erst einen Blick ins Kernelprotokoll werfen, wenn ich Zeit habe. Dann kann ich sagen, ob es andere Auffälligkeiten gab.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zumindestend laufen die VMs laut Monitoring immer noch und die MySQL-Daemons reagieren. Abstürze gab es somit keine mehr. Ich muss erst einen Blick ins Kernelprotokoll werfen, wenn ich Zeit habe. Dann kann ich sagen, ob es andere Auffälligkeiten gab.


    Moin Christian,


    das freut mich, dass es bei dir jetzt wieder laeuft ohne dass du etwas gemacht hast. Ich habe mittlerweile alles probiert. Aelterer Kernel - nichts. Neuerer Kernel - nichts. Es tritt immer wieder auf :/


    Ich werde mich jetzt noch einmal an den Support wenden.


    LG Marc

  • Moin!


    Nachdem ich Mitte November schon zweimal das Problem hatte, schrieb ich direkt den Support an. Diesbzgl. kam nur die Empfehlung einen Kernel mit aktualisierten KVM Gast-Treiber zu testen. Dann war lange Zeit Ruhe - bis gestern Abend. Gleiches Verhalten, wieder hung_task. Ich bin mit meinem (geringen) Latein am Ende.


    Grüße

    [WH 4000 SE Ost. 19] – [3x 2x VPS 200 G8] – [VPS 10 G7] – [RS M Xmas 15][WH Exp. Spezial 16]

    [Adv15 RS SL A+] – [Failover IPv6-Subnet Ost. 18] – [Cloud vLAN]

  • Der Support konnte/wollte mir leider nicht weiterhelfen. Ich sollte das Rescuesystem starten, was aber ueberhaupt keinen Sinn hatte - da ich dort die virtuellen Maschinen nicht starten konnte.


    Ich habe jetzt alle virtuellen Hosts auf einen 4.4er Kernel und den Host sogar auf 4.8 Kernel gebracht. Das scheint geholfen zu haben. Ich werde berichten ob es stabil bleibt.


    Nebenbei habe ich meinen Server auf das "Nachfolgeprodukt" upgraden lassen, hat 20 Euro gekostet. Nun habe ich mehr Leistung und zahle 2 Euro im Monat weniger ^^.


    LG Marc

  • Nebenbei habe ich meinen Server auf das "Nachfolgeprodukt" upgraden lassen, hat 20 Euro gekostet.


    Ohne Wechsel auf ein anderes Hostsystem? Ich frage nur, weil das für die beschriebenen Probleme relevant sein könnte.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Mein Fehler hat sich mittlerweile wieder erledigt. Nach einem kompletten Ausfall des Nodes am Montag um 12:00 Uhr hat Netcup anscheinend das Problem beseitigt. Seitdem sinkt die Disk Latency täglich.

  • Ohne Wechsel auf ein anderes Hostsystem? Ich frage nur, weil das für die beschriebenen Probleme relevant sein könnte.

    Ob, sie ein zweites Mal meinen Server auf ein anderes Node verschoben haben weiss ich nicht. Aber jetzt habe ich statt 16 GB 24 GB RAM und 8 Kerne ;)

  • Ich habe jetzt alle virtuellen Hosts auf einen 4.4er Kernel und den Host sogar auf 4.8 Kernel gebracht. Das scheint geholfen zu haben. Ich werde berichten ob es stabil bleibt.


    Nebenbei habe ich meinen Server auf das "Nachfolgeprodukt" upgraden lassen, hat 20 Euro gekostet. Nun habe ich mehr Leistung und zahle 2 Euro im Monat weniger ^^.


    Kannst du bitte auch mal auf deinen jetzt doch deutlich größeren Server die einzelnen VMs und das Hostsystem wieder mal mit dem älteren Kernel laufen lassen? Denn mich und eventuell auch andere Besucher dieses Forums würde mal interessieren, ob es nur an dem älteren Kernel lag oder doch an was anderem.

  • Zu früh gefreut. Eine VM hängt schon wieder... :rolleyes:


    Dann installiere ich mal einen neueren Kernel (Debian Backports 4.8+77~bpo8+1) und beobachte weiter.


    Edit: Der neue Kernel ist in allen VMs und am Hostsystem aktiv. Ich bin gespannt, ob es etwas bringt…



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • KB19
    Konntest du zufälligerweise in den Logs was sehen, weshalb dir wieder einer der VM´s hängen geblieben ist?

  • Leider nicht. Am Hostsystem habe ich absolut nichts davon bemerkt, außer die hohe CPU-Auslastung. Und über VNC sah im Gast auch nichts mehr, weil entweder der Bildschirmschoner der Konsole anging oder sowieso nichts mehr angezeigt wurde. In den Logfiles stand sowieso nichts.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Jetzt häufen sich im Kernellog plötzlich andere Fehler: (nur einzelne Auszüge)


    Code
    NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [qemu-system-x86:2267]
    rcu_sched kthread starved for 4931 jiffies! g2079305 c2079304 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
    sd 0:0:0:0: [sda] tag#28 abort


    Entweder bringt der 4.8.0-0.bpo.2-amd64 Kernel nichts oder da funkt doch etwas vom netcup-Hostsystem dazwischen. Die VMs hat es bisher offenbar nicht gestört, die laufen noch fröhlich weiter. Trotzdem registrierten sie ein paar Timeouts beim Zugriff auf die virtuelle(n) Festplatten. Bis auf eine seit drei Tagen minimal gestiegene CPU-Auslastung ist noch alles im grünen Bereich.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Jetzt häufen sich im Kernellog plötzlich andere Fehler: (nur einzelne Auszüge)
    ....
    Entweder bringt der 4.8.0-0.bpo.2-amd64 Kernel nichts oder da funkt doch etwas vom netcup-Hostsystem dazwischen.


    Weißt du zufälligerweise, welche Kernelversion Netcup für seine Hostsysteme nimmt? Denn z.B. bei CentOS 7, um damit zuverlässig KVM-Server zu betreiben, wird derzeit die Kernelversion 3.10.0-514.6.1.el7.x86_64 installiert.