Regelmäßige IO Probleme

  • Bitte lasst daher unserem Support via Kontaktformular oder direkt an mail@netcup.de folgende Informationen zukommen:


    Ich kann das Problem auf einem RS in unregelmäßigen Abständen bestätigen. Zwischen 20-30sek absoluter Stillstand. Ist allerdings recht selten mittlerweile.

    Ticket aufgegeben, IO-Wait von 100 % mit 200 kB_read/s bei einem `git grep` in /etc.

    Danke für die Rückmeldungen!

    Eine Bitte: Wenn ihr solche Probleme habt, macht ein Ticket auf, so wie Lars beschrieben hat.


    Ich habe meinen (RS)Server jetzt schon mehrmals "auf Links gedreht"; Ich habe keine I/O intensiven Anwendungen, Backup habe ich momentan auch aus(!)

    Das Problem zieht sich trotzdem jetzt seit Monaten hin. Je nach momentaner Instanz läuft es ok (kaum wahrnehmbar, 2-3 mal am Tag) bis hin zu >100 Mal pro tag (=Katastrophe)

  • Danke für diese Infos hier. Ich habe seit Monaten genau dieses Problem: mein Server steht jeden Tag mehrmals für 30-60 Sekunden nahezu still, obwohl sich da nur ein paar Container langweilen. Ein uptime zeigt in diesen Momenten regelmäßig ein Load von mindestens Zweistellig an.

    Habe schon an mir selbst gezweifelt.

    Hi, ich habe auch einen Server, der kaum echte load hat aber 24% Auslastung. Netcup hat ihn schon ein paar mal hin und hergeschoben aus eigenem Antrieb. Habe bisher nie ein Ticket gesendet.

    Auf dem Server sind einfach ein paar Ärztewebseiten drauf. Jedenfalls fast kein Traffic, oder soetwas wie lange cronjobs.

    Wie empfiehlst du dies am besten zu messen/zu dokumentieren?

  • Hi, ich habe auch einen Server, der kaum echte load hat aber 24% Auslastung. Netcup hat ihn schon ein paar mal hin und hergeschoben aus eigenem Antrieb. Habe bisher nie ein Ticket gesendet.

    Auf dem Server sind einfach ein paar Ärztewebseiten drauf. Jedenfalls fast kein Traffic, oder soetwas wie lange cronjobs.

    Wie empfiehlst du dies am besten zu messen/zu dokumentieren?

    Hi! Empfehlen möchte ich lieber nichts. Würde das lieber dem Netcup-Support überlassen.


    Ich bin aber gerne bereit, hier für den NC-Support alle nötigen Daten zu liefern.

    Ich selber betreibe ein Monitoring (check_mk) und mein weiter oben gezeigtes Skript als temporäre Not-Lösung. Beides zeigt übereinstimmend das gleiche Problem an.

  • Hi! Empfehlen möchte ich lieber nichts. Würde das lieber dem Netcup-Support überlassen.


    Ich bin aber gerne bereit, hier für den NC-Support alle nötigen Daten zu liefern.

    Ich selber betreibe ein Monitoring (check_mk) und mein weiter oben gezeigtes Skript als temporäre Not-Lösung. Beides zeigt übereinstimmend das gleiche Problem an.

    Naja, du bist ja schon viel weiter in der Erforschung dieses Phänomens.
    Was mich interessieren würde.. Falls meine ~24% CPU Auslastung mit diesem Problem zusammenhängen. Würde ich dies über strace bzw. iostat sehen?
    Also strace -o output.txt git grep <your_search_term> /etc

    Oder tritt es zu sporadisch auf?

  • Naja, du bist ja schon viel weiter in der Erforschung dieses Phänomens.
    Was mich interessieren würde.. Falls meine ~24% CPU Auslastung mit diesem Problem zusammenhängen. Würde ich dies über strace bzw. iostat sehen?
    Also strace -o output.txt git grep <your_search_term> /etc

    Oder tritt es zu sporadisch auf?

    Ich würde das vor allem über den iowait Wert messen. Am besten mit Hilfe eines Monitoring Tools. Daran erkennt man es eigentlich am besten. Falls du kein Monitoring (Icinga, Check_MK, Zabbix, ...) hast, kannst du auf dem Server auch direkt mittels top oder glances überprüfen. Da musst du aber direkt live dabei sein, wenn das Problem auftritt. Daher wäre die Lösung über ein Monitoring Tool die bessere Wahl. Mit strace wirst du da wenig Erfolg haben.

  • Das kann doch echt nicht sein, dass WIR hier Netcup drauf stoßen müssen dass mit IHREN Servern was nicht stimmt!? Gibts da null Monitoring?

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Traurig 1 Danke 1 Gefällt mir 3 Haha 1
  • Kurze Rückmeldung: Mein Server wurde gestern nochmals verschoben.

    Seitdem habe ich kein Hänger mehr beobachten können. Gefühlt läuft es seitdem "wie geschmiert".


    An dem seltsamen Bild im Monitoring hat sich allerdings nichts geändert - Load-Peaks habe ich jetzt fast im Stundentakt:


    pasted-from-clipboard.png


    Mit dem jetzigen Zustand kann ich bisher ruckelfrei Arbeiten. Sobald ich mein Monitoring anpasse, fällt "der Zustand" vermutlich überhaupt nicht mehr auf.

    Ich werde das noch 1-2 Tage weiter beobachten, und dann dem Support mein Sammelsurium an Log-Files als Rückmeldung geben.

    Sofern der Zustand so bleibt wie jetzt, kann ich das als "optische" Ausreißer im Monitoring abhaken.

  • Vielleicht wäre es dafür von Vorteil, wenn ihr das Rettungssystem mal aktualisiert. Momentan basiert es auf Debian oldoldoldoldstable, sodass man keinerlei Tools wie bspw. hdparm nachinstallieren kann.

    Hallo bjo,


    vielen Dank nochmals für dein Feedback.


    Das Rettungssystem wurde nun auf die aktuelle Version von "grml" aktualisiert.