Beiträge von frostschutz

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.

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.

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:

# 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:

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 -, 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:

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

Das ist ja noch gruseliger als vorher... jetzt wird da schon stillschweigend irgendwelcher Krempel nachinstalliert, also wirklich

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.

Was geht denn nicht?

Du hast LVM.

Du versuchst da, fsck auf ein LVM PV anzuwenden, statt auf ein wie auch immer geartetes Logical Volume (LV). Da kannst du froh sein wenn es mit einer Fehlermeldung aussteigt. fsck mit -y und -f ist nicht selten eine tödliche Kombi.

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?

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

Zitat von dergeberl

genau runtergeladen, angeschaut und dann gestartet

^ als nobody

Zitat von ensky_eu

Ihr müsst lediglich folgenden Command in eure Konsole einfügen:

Code

wget http://data.ensky-media.net/bench.sh -O - -o /dev/null|bash

Wenn ich sowas sehe frage ich mich immer, interessierst du dich jetzt tatsächlich für die Benchmarks, oder willst du einfach wissen wieviel Chancen ein Linux Virus heutzutage so hat? Denn jeder, der das so ausführt, hat dann womöglich einen. Du weißt bei dem Befehl ja nicht, was in dem Script dringestanden hat. Wenn du es dir vorher oder nachher nochmal runterlädst, mußt du ja nicht das gleiche Script bekommen. Das kann der Webserver ja bei jedem Request aufs neue entscheiden, was er diesmal ausliefert.

Ist auch der Grund warum ich den Calibre-Installer nicht mag ( calibre - Download for linux ) der macht das gleiche mit Python und sudo... und Calibre hatte schonmal einen eingebauten local root exploit.

Meine Ergebnisse (Root Server S)

ENSKY MEDIA Benchmark v2.1




 visit: www.ensky-media.net




 Allgemeine Informationen 




 CPU :  Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
 Anzahl der Kerne :  1
 CPU Taktfrequenz :  2393.996 MHz
 Arbeitsspeicher : 998 MB
 SWAP : 639 MB
 Uptime :   22 days, 22:47,       




 Netzwerk Benchmark 




 Download Geschwindigkeit: ENSKY MEDIA (DE, Frankfurt am Main): 22.0MB/s 
 Download Geschwindigkeit: Colo Bunker (DE, Bonn): 48.2MB/s 
 Download Geschwindigkeit: Thinkboard (DE): 10.2MB/s 
 Download Geschwindigkeit: QSC (DE): 14.2MB/s 




 Festplatten Benchmark 




 I/O Geschwindigkeit :  236 MB/s

Kommt drauf an wie das Ding konfiguriert ist, und das solltest du im Idealfall wissen. Wenn die Netzwerkkonfiguration per DHCP läuft mußt du wahrscheinlich nur wenig ändern, ansonsten etwas mehr.

Es kann sein daß du die /etc/network/interfaces und /etc/hosts anpassen musst, ebenso die Konfiguration deines Webservers. Einfach mal /etc/ nach deiner alten IP greppen...

Zitat

Dass die Domains nicht sofort auf die neue IP-Adresse verweisen

Das geht meist recht flott. Wenn man vorher die TTL etwas runterschrauben könnte...

Daß Domains auch mal ihre IP ändern ist letztendlich ein ganz normaler Vorgang, die wenigsten machen deswegen mit Proxy herum.

Viel Erfolg beim Umzug.

Mein VServer (S) ist auch sehr flott eingerichtet worden - gestern Samstag 19:00 die Einzugermächtigung inkl. Persokopie (viel hilft viel) gemailt, und heute Sonntag 11:00 Uhr hatte ich schon die Zugangsdaten. Sehr schön.