Posts by frostschutz

    Diese haben durchaus verschiedene physikalische CPUs, weshalb wir hier auch nur virtuelle CPUs bewerben.


    Daß es virtuelle CPUs sind wird nicht immer so 100% klar, in der Produktbeschreibung steht "Prozessorkerne: 2", nicht so wie beim Root S wo da explizit noch "virtuell" dahintersteht. (Natürlich steht "dediziert" auch nirgends). Will auch gar nicht meckern, bin ja froh daß es den Adventskalender gibt. :thumbsup: (habe hier nicht zugegriffen, schaue aber jeden Tag rein, vielleicht ist ja auch mal was für mich dabei)

    Speichern bei uns einige Daten in einer Ramdisk da es doch wichtig ist das auf diesen Daten schnell zugegriffen werden kann. Dank dem doch abrupten Update sind nun Daten seit heute um 12 Uhr weg...


    SSKM.


    Wenn die Daten wichtig sind musst du dafür sorgen, daß sie gesichert werden und nicht nur flüchtig im RAM liegen.


    Darüber hinaus wurden die Server ja nicht unerwartet per Stromausfall/Reset ausgelöscht, sondern sauber heruntergefahren. Services haben hier die Gelegenheit noch Daten zu sichern.


    Da solltest du deine Lösung für die Zukunft unbedingt nachbessern.

    Kann ich die zur Verfügung gestellten CD-ROM-/DVD-Images wie
    z.B. "Ubuntu 14.04 Server 64 Bit" nur auf einem "Root-Server L Generation
    6" oder auch auf einem "Root-Server M Generation 6" nutzen?


    Du installierst dir einen Bootloader auf die Festplatte. Wenn du nicht weißt wie das geht, machst du halt zuerst irgendeine Image-Installation.


    Dann lädst du dir Kernel und Initrd von hier: Index of /ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64


    Und dann bootest du das und installierst wie gewohnt. Die Pakete werden dann nicht von CD sondern übers Internet geladen, ansonsten dürfte es gleich sein...


    Oder aber du freundest dich mit debootstrap an.

    Du brauchst ein besseres Mikrofon (oder ich bessere Ohren) oder einen anderen Audio-Codec. Selbst ein 0815 USB-Mikrofon um 10-20€ sollte das besser hinbekommen. Deine Aufnahme klingt nach Onboard-Mikrofoneingang ohne Mic-Boost...


    Um herauszufinden was beim Befolgen der Wiki-Anleitung nicht geklappt hat, wäre es interessant den ganzen Vorgang im Terminal mal festzuhalten (per 'script' o.ä.). fdisk könnte Probleme machen, es gibt inzwischen ja auch zig verschiedene fdisk-Versionen (mit und ohne GPT-Unterstützung, mit und ohne automatisches Partitions-Alignment, ...), da muss man sich eben anpassen. Das Rettungssystem macht Anfängern vielleicht auch Probleme, weil man hier erstmal selbst sich drum kümmern muss daß es überhaupt bootet (Network steht nicht automatisch in der Liste und schon gar nicht an 1. Stelle - bei dir auch nur auf Platz #2).

    parted nimmt leider schräge Einheiten beim print, die es falsch aussehen lassen obwohl es richtig ist.


    Wenn du Partitionsalignment mit parted anschauen willst, nimm lieber:


    Code
    1. parted /dev/xyz unit mib print free
    2. parted /dev/xyz unit s print free


    Wenn du glatte MiB siehst bzw. Sektoren vielfache von 2048, dann passt es. Falls es eine erweiterte oder bios_boot Partition gibt: Es zählt nur primary und logical.


    Edit: Ups, ich hab dich glaub eh falsch verstanden, dir gings nicht ums Alignment... sorry :)


    Wenn es VirtIO ist (/dev/vda) dann kannst du problemlos im Betrieb neue Partitionen hinzufügen, der Kernel sieht diese sofort. Einzig bei /dev/sda mag er das lieber nicht so ohne Reboot dazwischen solange das Gerät in Gebrauch ist. Du kannst auch die bestehende Partition vergrößern und dann mit resize2fs das ext4-Dateisystem erweitern.

    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
    1. # dd if=/dev/vda of=/dev/null bs=1M count=512
    2. 512+0 records in
    3. 512+0 records out
    4. 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.

    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
    1. truncate -s 512M /dev/shm/foobar
    2. shred -n 1 /dev/shm/foobar
    3. 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.

    Ich steige im Moment selbst von einem Root Server S auf Root Server M um. Übertragen habe ich ganz normal mit SSH/rsync.


    Sorgen bereitet mir der hohe IO-wait. Beim entpacken eines Linux-Kernel-Tarballs bleibt die Kiste praktisch stehe.


    Überschreiben einer 512MB-Partition mit Zufallsdaten:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 164.985 s, 3.3 MB/s


    Das gleiche im Rettungssystem:


    Code
    1. rescue:~# truncate -s 512M /dev/shm/foobar
    2. rescue:~# shred -n 1 /dev/shm/foobar
    3. rescue:~# dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 12.7916 s, 42.0 MB/s


    Es liegt also allem Anschein nach am Kernel. Das Rettungssystem ist 3.2.63 - das ist mir etwas zu stabil :D -, im installierten System habe ich 3.18.1 und 3.17.7 probiert.


    Auf der LKML habe ich noch jemanden mit IO-wait-Problemen bei aktuellem Kernel gefunden: LKML: =?UTF-8?Q?Jonas_Bofj=C3=A4ll?=: Stuck in iowait regression in 3.18.1


    Ich versuche es als nächstes mit 3.14, das läuft auf meinem Root Server S...


    Edit: Und siehe da, mit 3.14.2 und ansonsten ident. Konfiguration (make oldconfig) klappts auf einmal wunderbar:


    Code
    1. # truncate -s 512M /dev/shm/foobar
    2. # shred -n 1 /dev/shm/foobar
    3. # dd bs=1M if=/dev/shm/foobar of=/dev/vda4
    4. 512+0 records in
    5. 512+0 records out
    6. 536870912 bytes (537 MB) copied, 11.8879 s, 45.2 MB/s


    Fröhliches Kernel-Bug-Hunting... ;)

    Abgesehen davon daß das eine ziemlich gruselige Art ist, etwas zu partitionieren, fehlt da schlicht der Befehl der das Dateisystem selbst vergrößert (resize2fs odgl).


    Und wenn du das nicht im Rettungssystem machst wo das Dateisystem nicht gemountet ist, wird das System die Partitionstabelle nach einem fdisk nicht aktualisieren (weil in Benutzung) und resize2fs somit auch nichts machen.