ltsp3 ist bei Schreiboperationen langsamer

[Rüdiger Kupper]

ltsp3 ist immer und deutlich langsamer beim Update, so als

• wäre die Internetanbindung langsamer, oder
• würde der Rechner langsamer laufen

Ich finde das komisch. Irgend eine Idee?

[Rüdiger Kupper]

Er ist auch beim Regenerieren der Client-Chroot deutlich langsamer als die anderen, und da spielt die Internetanbindung keine Rolle.
-> Fazit: ltsp3 läuft langsamer.

[Rüdiger Kupper]

Querverweis: comment:130:ticket:666

Ergebnisse der Server-Benchmarks: LtspServerBenchmark

[Rüdiger Kupper]

Die ​"Disk"-Suite spricht eine klare Sprache: Ltsp3 ist bei 14 von 20 Tests der schlechteste der sieben Server, was die Festplattenperformance angeht. (Ltsp1 ist übrgens bei 12 von 20 der beste.)
Ltsp3 fällt eklatant aus der Reihe beim postgreSQL-Test und schneidet allgemein bei Schreiboperationen schlecht ab.

Wir sollten die Platten und den Controller in ltsp3 überprüfen.

[Rüdiger Kupper]

Auch der SMART-Selbsttest braucht auf ltsp3 länger als auf den anderen. Aber er endet ohne Fehler. Die Platten sind also nicht defekt, sondern einfach nur langsam.

[bau]

Test: Ich tausche jetzt den ltsp3 und den ltsp1 aus (Platten baue ich um). Dann ist die Flimmer-Hardware in Raum 5.36 (138). Bitte den Speedtest dann nochmals ausführen.

[Rüdiger Kupper]

Okay. Ich hab noch ein paar andere Benchmarks laufen lassen, Ergebnisse hier: LtspServerBenchmark. Der postgreSQL-Test ist der einzige, der so radikal abweicht, aber das reproduzierbar.

[Rüdiger Kupper]

Okay, Test läuft.

[Rüdiger Kupper]

Na, da war ich wohl etwas schnell, die Maschinen waren zwischendurch wieder weg. Sag bescheid, wenn Du fertig bist :-).

[Rüdiger Kupper]

Test läuft wieder, ltsp3 (der *neue* liegt schon wieder hinten! => Platten?!

[Rüdiger Kupper]

Ergebnis des PostgreSQL-Tests:
​PostgreSQL-Test (ltsp1new ist der ehemalige ltsp3 und umgekehrt.)

[Rüdiger Kupper]

Ergebnis ist eindeutig: der neue ltsp3 (also die Maschine, die zuvor ltsp1 war), ist wieder deutlich schlechter. Da die einzige Komponente, die gleich geblieben ist, die Platten sind, muss es folglich an denen liegen. (Vielleicht auch nur eine der zwei. Bei Leseoperationen hat ltsp3 nicht schlechter abgeschlossen. Bei Leseoperationen nimmt das RAID-1 das Ergebnis der schnelleren Platte. Nur bei Schreiboperationen muss auf beide Platten geschrieben werden.)

[bau]

OK: Test2, ich werde die eine Platte (welche auch immer das ist, laut Murphy wird es die falsche sein) auf faulty setzen, rausziehen, eine Ersatzplatte reinschieben, partitionieren und ins Raid reinbringen. Dann kannst du den Test nochmals laufen lassen (ich melde mich). Ach ja: Das geflimmer ist auch bei der Ersatzmaschine vorhanden - es liegt also nicht an der Hardware sondern an der Stromversorgung in diesem Raum.

[Rüdiger Kupper]

Beim SMART-Test hatte ich den Eindruck, dass es die /dev/sdb-Platte ist, die Schwierigkeiten hatte. Also tausch mal die aus.

[bau]

MIST: das ging wieder mal gründlich schief. Ich habe /dev/sdb1 faulty gesetzt und aus dem Array removed - kein Problem, dann habe ich die untere Platte gezogen, leider war es mal wieder die obere. Ich muss das mal genauer ansehen, wie die verkabelt sind. Einmal ließ er sich mit degradiertem Array booten, da musste ich aber feststellen, dass er die SATA-Platten nur dann hot-pluggen kann, wenn die beim Booten schonmal da waren??? Das kann doch nicht sein - oder? Ich muss doch eine Platte reinstecken können und die ist dann mal da? Was muss man dem System dazu denn noch sagen?

Auf jeden Fall lässt sich der Server jetzt erstmal nicht mehr booten - ich bin morgen mit der Familie in Tübingen (Fehlermeldungen ignorieren) - am Samstag könnte ich wieder nach ihm sehen - bist du im Lande?

[Rüdiger Kupper]

SATA ist generell hot-plug-fähig, es muss also gehen, eine Platte einfach einzustecken, und sie tut. --??

Aufgabe: Wir müssen die Platten kennzeichnen: Es muss klar sein, welche sda und welche sdb ist.

Ich werde den ltsp3 also neu aufsetzen. Welche Platten sind denn zu Zeit drin?

[Rüdiger Kupper]

Setup-Skript ist durchgelaufen, aber Rechner ließ sich remote danach nicht neu booten. Irgendwo hängt's, bitte überprüfen.

[bau]

Ich habe nachgelesen, dass der Kernel von Ubuntu 12.04 anscheinend Probleme mit dem HotPlug hat. Es gibt da aber ein Paket (scsi-tools / rescan-scsi-bus / siehe ​http://ubuntuforums.org/archive/index.php/t-1998055.html) mit welchem man den bus neu auslesen lassen kann.

Ich werde mal checken, dass an jedem Server sda oben und sdb unten ist.

Der Rechner hat anscheinend vom USB-Stick gebootet. ich werde ihn nachher mal neu starten.

[Rüdiger Kupper]

Replying to bau:

Der Rechner hat anscheinend vom USB-Stick gebootet. ich werde ihn nachher mal neu starten.

Tsss, dabei hab ich noch extra im BIOS die Bootreihenfolge umgestellt, bevor ich gegangen bin. Anscheinend hält sich er Rechner nicht daran, sondern bootet einfach immer vom USB-Stick, wenn einer eingesteckt ist. Oder ich hab die BIOS-Einstellungen nicht verstanden...

Vielleicht ist der Rechner aber auch einfach wieder beim Hochfahren hängengeblieben, das Problem gibt es ja auch noch. Jedenfalls sollte der Server nach einem Neustart wieder wie neu sein.

[Rüdiger Kupper]

Aus dem Forumseintrag:

I have checked the MB and AHCI is enabled.

Das sollten wir auch nochmal tun! Das Gigabyte-Board von ltsp4 lief z.B. im IDE-Kompatibilitätsmodus, das habe ich gestern auf AHCI umgestellt. (Einige "alte" Betriebssysteme, wie z.B. XP können nicht per AHCI booten, daher kommen fast alle BIOS mit dem voreingestellten IDE-Modus. Der ist aber gegenüber AHCI eingeschränkt.)

[bau]

ltsp3 läuft jetzt wieder mit der Ersatzplatte.
Bitte den Benchmark-Test durchführen - mal sehen, ob die sdb der Kandidat war :-)

[Rüdiger Kupper]

Test läuft.

[Rüdiger Kupper]

Okay, da haben wir wohl danebengegriffen (Murphy lässt grüßen)!
Die Sache ist offensichtlich: Die anderen LtspServer sind bereits seit Stunden fertig mit dem Test, ltsp3 läuft immer noch, und mit katastrophalem Bild:

PostgreSQL pgbench 8.4.11:
    pts/pgbench-1.4.0
    Test 1 of 1
    Estimated Trial Run Count:    3
    Estimated Time To Completion: 1 Hour, 13 Minutes
        Started Run 1 @ 10:29:50
        Started Run 2 @ 11:51:06
        Started Run 3 @ 13:47:07

Der Test besteht aus drei Durchläufen, auf den anderen Servern braucht jeder Lauf etwa 15 Minuten. Auf dem ltsp3 dauerte der erste Durchlauf 21 Minuten, der zweite bereits fast zwei Stunden! Ich glaube, wir brauchen das Ende des dritten Laufs gar nicht mehr abzuwarten.

[Rüdiger Kupper]

Korrektur, ich hab mich verschaut:
Der erste Durchlauf brauchte 1:21 Stunden, der zweite knapp zwei Stunden.

=> Jetzt also bitte die andere Platte austauschen :-(.

[bau]

OK, dann kommt morgen mal mein Talent ran, diesmal die richtige Platte rauszuziehen und im laufenden Betrieb syncen zu lassen (es ist die obere :-) ) Ich melde mich, sobald das System zum Test freigegeben ist.

[bau]

OK, das funktioniert ganz prima:

• obere Platte als fail setzen (muss sein, sonst kann ich sie nicht aus dem Array removen)
• obere Platte removen
• rausziehen
• Bei der neuen Platte habe ich vorher in einem anderen Rechner mit

   mdadm --zero-superblock /dev/sdX1
  

  die Raid-Zugehörigkeit zerstört und mit

   dd if=/dev/zero of=/dev/sdX bs=512 count=1
  

  die Partitionstabelle gelöscht.
• Platte in oberen Schacht rein (wird gleich als /dev/sda erkannt)
• Neue Partitionstabelle schreiben:

   sfdisk /dev/sda | sfdisk -d /dev/sdb
  

• Und wieder ins Raid einhängen

   mdadm --manage /dev/md127 --add /dev/sda1
  

Jetzt synct der Rechner grade sein Raid-Array wieder, sobald das fertig ist, kannst du den Benchmarktest laufen lassen. Ich bin begeistert: Das Ganze funktioniert während dem laufenden Betrieb!

[Rüdiger Kupper]

So solls auch sein :-). Ich verstehe aber nicht, wieso Du die Platte zunächst auf fail setzen musstest. Es muss doch auch erlaubt sein, eine funktionstüchtige Platte aus dem RAID zu entfernen.

[Rüdiger Kupper]

Okay, der Sync ist fertig. Ich starte mal den Test.

[bau]

mdadm beschwert sich, wenn ich die Platte removen möchte, sie sei noch Busy. Erst, wenn sie fail ist, dann lässt er sie raus. Wahrscheinlich, dass man die nicht aus versehen rauszieht.
Ich werde die Platte jetzt mal in den noch freien Rechner packen und mal sehen, ob man davon booten kann - irgendwie müsste das ja gehen!

[bau]

Test: Die als fail gesetzte Platte hat eingebaut direkt in die initramfs-busybox gebootet, dort konnte ich das Raid mit

  mdadm --manage --run /dev/md127

starten und die busybox per STRG-D verlassen, wonach das System einwandfrei bootete. Natürlich habe ich mangels Netzwerkkabel keinen Desktop erreichen können, aber damit könnte man das Raid auch wieder im laufenden Betrieb zusammensetzen lassen. :-)

[Rüdiger Kupper]

Alles klar! Testergebnis normal, sogar im Vergleich eher gut: ​http://openbenchmarking.org/result/1302218-AR-PGBENCH3L55,1302217-AR-PGBENCH3L85,1302219-AR-PGBENCH3L34,1302212-AR-PGBENCH3L36,1302217-AR-PGBENCH3L34,1302210-AR-PGBENCH3L86&obr_scalar=y
Die A-Platte war defekt.

Ich schlage vor, wie schicken die Platte zurück und verweisen auf die Seite, wo wir die Testergebnisse dokumentiert haben: LtspServerBenchmark.

Alternativ können wir natürlich auch probieren, die Platte zu low-level-formatieren, vielleicht fängt sie sich.

[Rüdiger Kupper]

Stammten die 320GB-Platten eigentlich auch von Mindfactory?

[bau]

Ja, die gesamte Hardware war von Mindfactory.

[bau]

Ich habe nun die 500GB-Platte wieder durch eine 320GB ersetzt.

[Rüdiger Kupper]

Wenn ich auf dem ltsp3 "lvs" aufrufe, erhalte ich folgende Fehlermeldung:

linadmin@LTSP138:~$ sudo lvs
  /dev/dm-6: read failed after 0 of 4096 at 0: Eingabe-/Ausgabefehler

Das sieht nicht ganz sauber aus. Hat das etwas mit dem Plattenwechsel zu tun?

[bau]

Was ist /dev/dm-6 ??
Wenn ich das RAID anschaue, ist das OK:

 cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md127 : active raid1 sdg1[2] sda1[3]
      312568696 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

Ein neu booten wäre sicherlich mal nötig, denn die Platte läuft als sdg und der smartd schaut täglich nach sdb. Ich werde das mal machen.

[bau]

Nach einem reboot ist auf dem ltsp3 alles wieder in Ordnung, die zweite Platte wird nun wieder als sdb erkannt und der Fehler bei lvs kommt nicht mehr