Performance Probleme mit Supermicro Server

[papa_joe 10]

Hallo Leute.

 

Wir haben hier einen Backup-Server W2K3 R2 mit folgender Ausstattung:

- Supermicro X8SIL-F mit Intel Xeon X3440 CPU

- 4GB ECC reg. RAM

- 1x 80GB WD SATA Systemplatte (WD)

- 1x 320GB Maxtor SATA HD für temp. Zeugs

- 3x 1,5TB WD15EADS SATA HD intern für's Backup

- 1x 1,5TB WD15EADS SATA HD zum täglichen Wechsel

- alle Platten hängen am internen Intel-Controller im AHCI-Modus

 

Über Nacht sichern unsere Server ihre Daten auf eine der drei 1,5TB Platten (je nach Woche). Sobald sie damit fertig sind, wird diese Platte am Tag komplett auf die vierte 1,5TB Platte kopiert (nennen wir es "Wechselbackup") und diese wird dann täglich gewechselt. Soweit die Theorie.

 

Praktisch habe ich ein Performance Problem und suche derzeit verzweifelt nach der Ursache :(.

 

Die Probleme:

- Beim kopieren über Netzwerk kommt der Datenfluß immer wieder ins stocken - die Netzwerkauslastung (GBit) pendelt meist zwischen 30 Sekunden Last und dann wieder 10 Sekunden nichts. Während der "Pausen" ist im Perfmon nichts als Langeweile zu sehen.

- wenn ich während des Wechselbackup, was ja "nur" ein schnöder Kopiervorgang ist, von einem anderen Rechner Daten auf eine andere (unbelastete) Platte auf dem Backup-Server kopiere, dann kommt das Wechselbackup vollkommen zum Stillstand und erst wenn der Kopiervorgang über's Netz abgeschlossen ist geht es mit dem lokalen kopieren weiter

 

Um die Switche (Netgear GS748T) auszuschließen habe ich den Backup-Server testweise per Kreuzkabel mit meinem PC verbunden, aber es bleibt bei dem Ergebniss. Netzwerk-Traffic und lokale Festplattenzugriffe scheinen sich gegenseitig nicht besonders zu mögen. Ich habe auch verschiedene Intel Matrix Storage Treiber versucht, da ich mit der mitgelieferten Version 8.9.1023 so meine liebe Not mit angeblich und sporadisch fehlerhaften Platten hatte (siehe hier: Random drive fails with new Matrix...). Ich bin jetzt wieder auf V8.8.1009 und bin wenigstens diese Probleme wieder los. Ich habe außerdem neue Intel-Chipsatz-Treiber (V9.1.1.1013) und Netzwerktreiber (V11.1.6.0) direkt von der Intel-Seite geladen, aber auch diese brachten keine Verbesserung :(. Den Modi des OnBoard SATA Controllers habe ich bereits mit Modus IDE, Intel AHCI und Intel RAID ausprobiert, jeweils auch ohne signifikante Veränderung - wobei der Datendurchsatz im einfachen IDE-Modus generell stabiler, aber dafür deutlich langsamer ist.

 

Ich glaube nun nicht dass jemand mit ähnlicher Hardware das selbe macht, aber vielleicht ist jemandem ja trotzdem sowas schonmal untergekommen. Vielleicht bin ich auch zu anspruchsvoll, aber ich meine sowas sollte doch so ein Serverboard abkönnen :confused: . Ich habe hier leider nicht unendliche Möglichkeiten Hardware zu tauschen, ich hoffe einfach erstmal auf Tipps :(.

 

PS: Wenn jemand noch eine anderen Link für Supermicro Treiber kennt, als die ständig überlastete Supermicro FTP-Seite, dann wäre ich dafür auch sehr dankbar.

[justin0102 10]

Ich würde tippen, dass der OnBoard-HDD-Controller das Nadelöhr ist.

Ein einfacher 4-Port SATA-RAID-Controller würde vielleicht Abhilfe schaffen.

[zahni 521]

Ich habe'ne Wiele überlegt, ob ich antworten soll.

 

Nur soviel: Das Sicherungskonzept solltest Du vielleicht nochmal überdenken.

 

Diese SATA-Contoller sind für sowas absolut nicht geeignet.

Was Du noch prüfen kannst, ob im BIOS der SATA-ACHI-Modus aktiviert ist.

Aber Achtung: Wenn der nicht aktiviert ist und Du stellst das um, bootet Windows nicht mehr, da für den AHCI-Modus ein anderer Treiber gebraucht wird.

 

Ich kenne das Board jetzt nicht, aber vielleicht hängen beide Controller (SATA und NIC) auf dem selben PCI-Bus. Das ist dann eher nicht gut.

Ist im OS ACPI mit APIC aktiviert, oder wurde da was umgestellt ? Diese sinnfreien Tips das zu ändern, geistern noch immer durchs Internet.

 

Für den Einsatz im Server empfehle ich einleistungsfähiges SAS-RAID (Controller mit Prozessor und OnBoard Schreibache mit Batterie).

Wenn Du unbedingt auf HD sichern willst, hänge 'ne USB-HD dran.

Ansonsten spricht nichts gegen LTO4 & Co.

 

-Zahni

[papa_joe 10]

Schön dass Du geantwortet hast :) !

 

Mir ist klar das es wahrscheinlich bessere Backup-Möglichkeiten gibt, aber diese Konstellation hat bisher sehr zuverlässig funktioniert. Erst jetzt nach Umstellung der Hardware und vor allem dem Einsatz größerer Platten kommt es zu dem Phänomen.

 

Ich meine, jeder einfache Desktop-PC sollte doch einen linearen Kopiervorgang und noch Zugriff auf eine andere Platte bewerkstelligen können. Die Bandbreite der Bussysteme liegt jedenfalls weit über dem was 1 oder 2 Festplatten bringen können.

 

Ich habe heute einen weiteren Test gemacht, wonach ich auch nicht mehr dran glaube dass der onBoard Controller so "schlecht" ist. Ich habe das System mit einer Ubuntu 9.10 Live-CD gestartet und dann die Kopiervorgänge zum Laufen gebracht. Per SMB habe ich von 2 verschiedenen Servern gleichzeitig auf je eine der 1,5TB Platten kopiert und gleichzeitig die 3. 1,5TB HD lokal auf die 4. 1,5TB kopiert. Ergebniss: Gigabit LAN war voll ausgelastet (2x ca. 45 MB/s) und lokal lief der Kopiervorgang zur gleichen Zeit ebenfalls mit ca. 60 MB/s. Genauso soll es sein - aber eben nicht nur unter Linux, sondern auch unter Windows :suspect:. Einziger gravierender Unterschied: Unter Linux ist die CPU seeehr beschäftig (60-70%), unter Windows fast gar nicht. Ich denke unter Linux wird der Controller mit einer Art generischem Treiber angesteuert wobei der unter Windows Intel-spezifisch ist.

 

Grundlegend ist damit aber gezeigt, dass es der Controller oder die OnBoard Bandbreiten nicht der begrenzende Faktor sein können. Hier muß doch der Windows Treiber buggy sein :o.

 

Das Rätsel geht weiter :)

[papa_joe 10]

Obwohl ich ja eigentlich gar kein Raid brauche, sondern nur einzeln ansprechbare Platten, würde ich zu einem "echtem" Raid-Controller wie z.B. dem Adaptec Raid 3405 greifen, wenn das mein Problem dauerhaft beheben würde - ich bezweifle das nur neben :(.

 

Ich hänge mal noch das Block-Diagramm vom Mainboard an. Evtl. kann damit ja jemand was anfangen.