erstes resumee meiner Systemprobleme

Hallo,

in den letzten Wochen gab es bei mir viel Frust und Unverständnis über Compi und seine Freunde. Jetzt nachdem sich die Nebelschwaden langsam auflösen wird es auch wieder etwas verständlicher.
Falls dem einen oder anderen das Verhalten seines Freundes auch spananisch vorkommt...

• Eine sterbende Platte kann nicht nur Fehler auf dem gleichen Strang produzieren, sondern auch auf dem Nachbar-Kanal.
  Bislang dachte ich, wenn ich an jedem Kabel nur ein IDE-Gerät hänge, müssten die Probleme isoliert sein.
  Dadurch dass in 2 Kisten sich jeweils ein Platte verabschiedete, konnte ich schlechte Performance an einer gesunden Platte (WD) in 2 verschiedenen Umgebungen beobachten (Murphy in Vollendung!).
  

  
  

• ethereal, bing und wie sie alle heißen sind gut, um den Status quo zu dokumentieren, aber richtig weiter gebracht hat mich erst das kleine Tuhl netio.
  Dadurch, das dig und Co, bing und alle anderen keine Fehler anzeigten, dachte ich, meine Konfiguration wäre in Ordnung. Erst netio zeigte auf, dass dem nicht so war und mit etwas nachdenken lies sich das Problem auch wieder logisch lösen (mein größtes Problem im Compi-Umfeld ist, wenn ich etwas nicht logisch nachvollziehen kann. Dann gerät mein Weltbild schnell ins Wackeln).
  

  
  

• Ausschalten von ACPI-Interrupt-Routing und verhindern von "share IDE Interrupt" brachte eine deutliche Performance-Steigerung bei Plattenzugriffen, auch wenn "nur" auf eine Platte zugegriffen wurde.
  

  
  

• Einsatz von debian als Server-system brachte eine gleichbleibende Leistungssteigerung. Sowohl bei Suse, als auch bei Gentoo fiel mir auf, dass eine Kopieraktion schnell (teilweise mit 80MB/s) anfing und dann ebenso schnell einbrach, um dann im Schritttempo vor sich hinzudümpeln.
  Offensichtlich wurden bei debian an entscheidender Stelle die Buffer-Verwendung, bzw. das Festplatten-Handling optimiert.
  Jetzt habe ich über den ganzen Kopierverlauf eine gleichbleibenden Übertragungsrate (ca. 23-30 MB/s) bis zum Schluss.
  Vielleicht läßt sich dieser Effekt bei entsprechender Kenntnis der Parameter auch auf den anderen Systemen erreichen - dies ist jedoch bei mir nicht der Fall - und so bin ich froh, dass es ein "voroptimiertes" System gibt, mit dem ich zumfrieden bin.
  

  
  

• Verwendung von sync/async beim Exportieren von nfs-Laufwerken.
  Der Sinn war mir zwar schon länger klar, aber so richtig bewusst wurde er mir erst jetzt, als ich konkrete Messungen durchführte.
  Dieser Effekt lässt sich auch sehr schön unter Verwendung von mc beobachten.
  Mit sync (und einer etwas gemütlicheren Platte, vielleicht auch noch SW-Raid) läuft der Kopierjob durch und dann steht der mc bei 100% und wartet auf das Ende von Commit. Das kann dann durchaus nochmal genauso lange dauern, wie das eigentliche Kopieren. Allerdings kann man dann sicher sein, dass die Daten auch auf Platte sind.
  

  
  

  Bei Verwendung von async läuft die Kopieraktion schneller und das Commit viel schneller ab. Allerdings sind die Daten noch beim Server im Speicher (und noch nicht auf Platte) und könnten bei einem Crash verloren gehen. So kann man gezielt Performance oder Sicherheit den Vorzug geben.
  

P.S. Alle genannten Kopieraktionen beziehen sich auf Dateien >= 1GB, sodass weder Cache noch Hauptspeicher für die Datei ausreicht.