Beiträge von frostschutz

  • Nutzung der verfügbaren CD-ROM DVD Images auf Root-Server Generation 6

    Zitat von messpero

    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.

  • [How To] Partition schnell und einfach verändern

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

  • vServer - Debian [Speicher-Proble]

    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
    parted /dev/xyz unit mib print free
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.

  • Root Server M: Performanzprobleme durch Kernel-Bug?

    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.

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

  • Wechsel von vServer Pluto KVM auf Root-Server M - Fragen vor dem Kauf

    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
    # truncate -s 512M /dev/shm/foobar
# shred -n 1 /dev/shm/foobar
# dd bs=1M if=/dev/shm/foobar of=/dev/vda4 
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 164.985 s, 3.3 MB/s


    Das gleiche im Rettungssystem:


    Code
    rescue:~# truncate -s 512M /dev/shm/foobar
rescue:~# shred -n 1 /dev/shm/foobar
rescue:~# dd bs=1M if=/dev/shm/foobar of=/dev/vda4
512+0 records in
512+0 records out
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
    # truncate -s 512M /dev/shm/foobar
# shred -n 1 /dev/shm/foobar
# dd bs=1M if=/dev/shm/foobar of=/dev/vda4
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 11.8879 s, 45.2 MB/s


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

  • Partitionierung der HDD größen

    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.

  • Suche Tester: Einfache Pastebin

    Mein Firefox (30.0 Linux) weigert sich warum auch immer das Textfeld per Mittlere-Mausklick-Paste zu befüllen. Ich hab das gleiche Problem allerdings auch phpMyAdmin (im Queryeditor) und noch nicht die Ursache gefunden. Ohne JS gehts.


    Kann das jemand nachvollziehen oder ist das eine Eigenart meines Systems?

  • Meingung: Von dedizierten Server auf verteilte netCup-vServer?

    Je mehr Server du hast, desto mehr Administrationsaufwand bringt das auch mit sich.


    Webserver und Datenbank zu trennen bringt dir erstmal Performanzeinbußen. Weil dann eben der ganze DB-Traffic übers Netz gehen muss. Lokal ist es einfach viel schneller.


    Wer das machen muss weil die Kiste einfach brennt, der setzt für die Web<->DB Verbindung meistens eine eigene Leitung ein. Und die Webanwendung selbst wird dann auch daraufhin optimiert, wirklich nur das nötige von der DB abzufragen; wogegen du lokal bzw. in 0815 PHP-Scripts eher ein SELECT * FROM findest auch wenn von den hundert Spalten nur zwei oder drei tatsächlich gebraucht werden. Lokal ist das nicht so wahnsinnig schlimm, aber wenn es Netzwerktraffic verzehnfacht merkst du es sofort... besonders lustig wird es dann wenn der Webserver versucht vom DB-Server ein Backup zu ziehen (weil die PHP-Software im Administrationspanel das so anbietet). Da schickst du dann auf einmal mehrere Gigabyte über die Leitung... für Nichts