Root Server M: Performanzprobleme durch Kernel-Bug?

    Ich habe mir Anfang Januar einen Root Server M zugelegt (das 5.49€-Angebot, Root-Server M v5a1 24M). Leider scheint das Gerät allergisch gegen Kernel neuer als 3.15 zu sein. Der Server bleibt oft stundenlang mit 100% IO-Wait hängen.


    Mir ist es relativ egal, ob ein vServer langsam ist. Ich habe keine Gameserver und auch kein Gentoo drauf, meine Ansprüche sind niedrig. Aber ich möchte doch dann und wann mal ein Systemupdate machen oder einen Tarball entpacken können ohne daß sich der Server stundenlang verabschiedet. Und ich verschenke ungerne >90% der möglichen Performanz unnötig an einen Kernel-Bug, und bei einer alten Kernel-Version bleiben ist auf lange Sicht für mich auch keine Option.


    Mein Test sieht folgendermaßen aus:


    1) Image übers Controlpanel installieren. Distribution egal (Debian, Ubuntu, Archlinux). Minimale Partitionierung. Ggf. Pakete aktualisieren.
    2) Mit parted (o.ä.) im unpartitionierten Speicher eine 512MiB große vda4-Partition erstellen (mit MiB-Alignment).
    3) 512MiB Datei im RAM erstellen und auf die Partition schreiben.

    Code
    truncate -s 512M /dev/shm/foobar
shred -n 1 /dev/shm/foobar
dd bs=1M if=/dev/shm/foobar of=/dev/vda4


    Ab Kernel 3.2.x (Rescuesystem) bis einschließlich Kernel 3.14/3.15 bekomme ich bei diesem Test 30-50MiB/s. Ab Kernel 3.16 aufwärts (einschließlich 3.19-rc4) sind es 2-3MiB/s und das System kommt dabei fast zum Stillstand. Dabei ist es egal zu welcher Tageszeit der Test durchgeführt wird, ob die Kernel selbst compiliert sind oder z.B. aus dem Ubuntu Kernel Mainline Repository stammen.


    Das sind jetzt lineare Writes und damit relativ harmlos. Aber sobald die Zugriffe zufälliger werden (z.B. ein kernel.tar.xz entpacken) kann man erstmal ins Elsaß fahren und einen Flammkuchen essen gehen. Da geht dann praktisch gar nichts mehr.


    Ein git bisect hat mich zu diesem Commit geschickt: blk-mq: split make request handler for multi and single queue · 07068d5 · torvalds/linux · GitHub


    Das muss aber nicht unbedingt stimmen da die bisect-Zwischenstände ihre ganz eigenen Krankheiten haben (Kernel Panics usw.). Und für einen einfachen git revert gibt es ein paar Konflikte. Ich komme da auch nicht wirklich weiter - bin halt weiters kein Kernel-Entwickler. Auf der LKML habe ich nur eine Problembeschreibung gefunden die meiner ähnelt - aber die dort angegebene Kernel-Version passt nicht: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1


    Bevor ich mir jetzt einen armen unschuldigen Kernel-Entwickler schnappe und diesem auf die Nerven gehe, wollte ich mal fragen, ob das Problem auch bei anderen (M v5a1) auftritt oder nicht?


    Bei meinem Root Server S ist es z.B. nicht der Fall, da läuft alles wunderbar (>50MiB/s)... lokal in einer eigenen KVM-Instanz kann ich das Problem auch nicht reproduzieren, dazu müsste man wohl im Detail wissen, wie der Netcup-Host aufgebaut ist.

    Darüber bin ich auch gestolpert.
    Ich hab einen der Adventskalender xmas Rootserver und hatte am Anfang auch enorme Probleme mit IO-Wait und einem 3.17er Kernel.
    Irgendwann hab ich dann auf 3.14 gewechselt und es wurde deutlich besser. Auch nicht wirklich perfekt, aber ich habs auf den super niedrigen Preis geschoben, dafür hab ich auch nicht viel mehr erwartet. Interessanter weise wurde es aber jetzt am vergangenen Donnerstag um ziemlich genau 12:30 Uhr nochmal deutlich besser ohne das ich was geändert hätte, sieht aus als hätte netcup was am Hostsystem getan. Keine Ahnung ob das mit dem Kernelbug(?) zu tun hatte oder ob nur der Hosts durch verschieben von VMs entlastet wurde.
    Man finded diverse Leute die Probleme mit neuen Kerneln und KVM haben, aber irgendwie kommen alle immer zu unterschiedlichen Schlüssen. Aber es scheint auf jeden Fall ein Problem mit dem virtio-blk Treiber zu geben. Wenn ich irgendwann dazu komme probiere ich nochmal einen neuen Kernel ob sich was geändert hat, aber eigentlich bin ich erstmal mit 3.14 zufrieden.

    Guten Tag,



    wir können das hier genannte Kernel-Problem bei Root-Servern nachstellen, für die wir SATA-Festplatten einsetzen. Bei den SSDs und SAS-Varianten funktioniert der neue Kernel einwandfrei. Hier gibt es nach wie vor einen schnellen Zugriff auf die Festplatten.


    Bzgl. des Problems muss wohl wirklich auf ein Update des Kernels gewartet werden. Alternativ können Sie sich auch an unseren Support wenden. Dieser kann zusammen mit Ihnen versuchen eine Lösung zu finden. Bitte verweisen Sie auf diesen Forenbeitrag, wenn Sie sich an den Support wenden.



    Vielen Dank!



    Mit freundlichen Grüßen


    Felix Preuß

    Bug Report ist hier: Bug 91691 – Extremely slow disk I/O, high iowait in 3.16 and newer kernels, unless blktrace is running


    VIel herausgekommen ist dabei bis jetzt noch nicht. Wenn man blktrace laufen läßt ist die Performanz auf einmal besser. Aber das kanns ja auch nicht sein.


    Gerade habe ich mal testweise Debian Jessie-rc1 installiert. Das kommt mit einem 3.16er Kernel. Da sieht es dann so aus:


    Code
    # dd if=/dev/vda of=/dev/null bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 1640.51 s, 327 kB/s


    Mir bleibt also nichts übrig, als bei einem alten Kernel zu bleiben. Anders läuft auf der Kiste nichts.


    Vor ein paar Jahren hatte ich schonmal einen Kernel-Bug, mit einem Firewire-Gehäuse das der Linux-Treiber nicht erkennen wollte. Da habe ich dem Kernelentwickler Root-Zugriff auf die Kiste gegeben und der hat das direkt am System debuggt und behoben. Das gleiche habe ich hier auch angeboten (Root-Zugang zum VServer), der Entwickler ist darauf leider nicht eingegangen. Ich weiß auch nicht mal, ob der Bisect überhaupt die richtige Stelle gefunden hat...


    felix, wenn das Problem auf Netcup-Seite reproduzierbar ist, bist du wohl in der besseren Position diesem Kernel-Bug auf die Schliche zu kommen. Ich bin hier mit meinem Latein am Ende.

    Guten Morgen,



    wir können bereits folgende Lösung anbieten: Statt VirtIO stellen wir eine echte SATA-Schnittstelle bereit. Über diese besteht das Problem bei den neuen Kernel nicht. Bei Interesse schreiben Sie bitte einfach den Support mit Verweis auf diesen Beitrag an.



    Vielen Dank!


    Gruß Felix Preuß