Gute RAID-Controller sind leider teuer, die günstigeren Modelle haben meist keine BBU (bzw. moderne Pendante wie Adaptecs ZMM) und die ganz billigen stellen de facto immer nur ein Fake-RAID bereit.
Das kommt drauf an wo man billig ansetzt. Ein "billiger" RAID Controller ist für mich schon der Adaptec 6405E und der liegt bei ca. 140 € netto und ist ein richtiger RAID Controller. Aber Ich denke du meinst hier sicher diese 30 € Dinger die 500 RAID Level können.
Es gibt in verschiedenen Foren verschiedene Ansichten, die sich teil wiedersprechen, z.B. Performance auf ein und demselben System unter Nutzung von Raid 5 / 10, z.B. auch wenns um Recovery eines Raid nach Hardware-Defekt geht. Das kann ja je nach Konfiguration dann ein defekter Kontroller oder z.B. auch das Board sein. Oft ist nämlich beschrieben, dass selbst ein baugleicher Hardware Kontroller nicht garantiert, dass ich mein Hardware-Raid ohne Datenverlust wieder bekomme.
Das Thema Performance ist leider immer reltiv. Es kommt letztlich auf den Anwendungszweck an, auf den du das System auslegst. Werden viele verschiedene I/O Anfragen gestartet, wie groß sind die Anfragen, mit welcher Block Sizes arbeiten die Festplatten ... es gibt hier sehr viel zu beachten. Da wir in den letzten Wochen ein Problem bei einem vServer Host hinsichtlich der Read Performance hatten, habe ich mich hier sehr tief in die Materie eingelesen und ich kann dir sagen, es gibt hier zig Stellschrauben die bei Anwendungszweck A besser und bei Anwendungszweck B schlechter sind. Das fängt bei dem I/O Cache mit Hilfe von RAID Controllern an und hört bei der Block Size der Festplatte auf.
Wenn du hier einen Performancetest durchführen möchtest, würde ich dir empfehlen, dass du dir für einen Test immer die Selben Commands zurechtlegst die auf deinen Verwendungszweck einigermaßen passen. Alles Andere würde das Ergebnis verfälschen. Wir haben für unsere Systeme folgende Leistungstests als Referenz in den letzten Wochen als für uns optimal deklariert:
Schreiben von 4x 1 GB großen Files:
dd if=/dev/zero of=/root/testfile bs=1G count=4 oflag=direct
Schreiben von 4000x 512 Byte großen Files:
dd if=/dev/zero of=/root/testfile bs=512 count=4000 oflag=direct
Messen der IOPS des Festplatten Arrays:
ioping /dev/sdX
Direktes Lesen des RAID Arrays ohne Cache:
hdparm -tT --direct /dev/sdX
Zu den Schreiben der 4x 1 GB großen Files gibt es folgendes hinzuzufügen. Im Tutorial von Thomas Krenn -
https://www.thomas-krenn.com/de/wiki/Linux_I/O_Performance_Tests_mit_dd - wird hier nur 1x 1 G geschrieben. Neue RAID Controller mit BBU / Caches verfügen aber meist bis zu 3 GB Cache. Gerade die von LSI modifizierten Modelle von Supermicro Cachen daher bis zu 3 GB. Um hier auch beim direct Write einen richtigen Referenzwert zu erhalten, sollte man daher einen Wert über der Größe des RAID Controller Caches wählen so dass nicht alles aus dem Cache geladen wird und am Ende dort 800 MB/s steht.
Beim Einsatz von dd gibt es zudem zu beachten, dass dd erstmal einen Prozess auf der CPU erstellt. Die Leistung die dd daher liefert beim schreiben, ist mit von der CPU Leistung abhängig. Wenn du also eine schwache CPU hast, kann es sein, dass sich das bis zu 100 MB/s auf den dd Prozess auswirkt. Wir haben das getestet. Taktet eine 2620v2 CPU mit 1200 Mhz - also im Stromsparmodus - bekommt man mit dd im Vergleich zu einem Takt mit 2100 Mhz eine Abweichung von 50-100 MB/s bei der Lese- und Schreibperformance. Du solltest daher darauf achten, dass die CPU nicht durch ein Heruntertakten zur Energieeffizienz beeinflusst wird. Man kann aus dem Betriebssystem heraus mit Hilfe des Tools Governor das CPU Scaling auf Performance oder Energiesparen umstellen, so kannst du beide Varianten testen.
Wenn du dann dein optimales Setup gefunden hast, kannst du noch Feintuning betreiben. Das z.B. durch spielen mit den I/O Scheduler des Linux Betriebssystems. Bei Debian wäre das:
cat /sys/block/sda/queue/scheduler
Jeder I/O Scheduler geht anders mit der Verarbeitung der I/O Anfragen um. Auch hier muss ich sagen hat das Thomas Krenn sehr gut erklärt -
https://www.thomas-krenn.com/de/wiki/Linux_I/O_Scheduler - Je nach Anwendungszweck kannst du hier noch das Ein oder Andere Prozent Performance herauskitzeln.
Auch kannst du ein wenig mit NCQ spielen. Manche Hardwarekonstellationen bewirken, dass NCQ beim Betriebssystem deaktiviert ist. Mit
echo 1 > /sys/block/sda/device/queue_depth
Kannst du den queue depth testweise einmal deaktivieren, mit z.B.
echo 31 > /sys/block/sda/device/queue_depth
kannst du diesen aktivieren bzw. die Größe des Caches festlegen. Das bringt auch ein Quantum Leistung.
Das erstmal grundsätzlich als Input, ich hoffe, Ich konnte dir damit noch etwas weiterhelfen. Schaue dir zuletzt auch einmal die BIOS Einstellungen an. Verschiedene BIOS Einstellungen gerade bei der QPI - Nachfolger des FSB BUS Systems - bringen hier auch noch ein paar % z.B. ISOC aktivieren für virtuelle Systeme.
