Tuning für parallele Plattenzugriffe

Hast Du Probleme mit Hardware, die durch die anderen Foren nicht abgedeckt werden? Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
MacLux
Beiträge: 11
Registriert: 06.08.2007 14:26:14

Tuning für parallele Plattenzugriffe

Beitrag von MacLux » 06.08.2007 14:43:19

Hallo,

hab hier ein 8-Kern-System mit Debian Etch. Im Rechner befindet sich ein internes RAID im Stripe-Modus mit Redundanz-Platte. Extern angeschlossen an einen PCIx-SCSI-Controller (Adaptec) ist ein 2TB EasyRaid mit 8 SATA-Platten (ReiserFS) auf dem jede Menge Videosequenzen bestehend aus (grösstenteils) Einzelframes abgelegt sind.

Leider ist der Datendurchsatz auf diese Bild-Daten nicht doll. hdparm (-tT) zeigt zwar folgendes an:

Timing cached reads: 6034 MB in 2.00 seconds = 3018.73 MB/sec
Timing buffered disk reads: 114 MB in 3.01 seconds = 37.81 MB/sec

Beim 8fach-parallelen Zugriff mit 8 Instanzen unserer Software rudert jedoch spätestens der dritte Prozess nur noch auf 30 bis 40 Prozent Kernauslastung herum. xosview zeigt auch für die Kerne immer nur einige wenige Spitzen an. Oftmals scheinen die Kerne für Bruchteile von Sekunden "gar nichts" zu tun. Allerdings muss man sagen, dass auch meine bisherigen Versuche, die Daten von den internen Platten einzulesen, ähnliche Ergebnisse zeigten. Evtl. dauert es von den internen Platten etwas länger bis die Prozesse von 100 Prozent Kernauslastung wegkommen.

Es gab auch für beide Fälle (extern und intern) kaum Performance-Unterschied, egal ob ich die Prozesse wie im Normalfall aus den notwendigen Perl-Scripts startete oder direkt an der Shell.

Nun hab ich im direkten Vergleich noch ein (hardware-mässig) identisches System mit Windows Server 2003, das ebenfalls über ein externes RAID verfügt (NTFS). Auf diesem System funktioniert der Zugriff absolut hoch-performant und unter voller Kernauslastung. Der Source-Code für die Datenzugriffe in unserer Software ist für Linux und Windows identisch.

Es sei noch erwähnt, dass die 8-Kern-Unterstützung generell zu funkionieren scheint. Starte ich einen "make -j8", sind alle Kerne ganz fleissig am Rödeln im Bereich 90 bis 100 Prozent.

Ich frage mich, ob vielleicht der Treiber für das externe RAID auf dem Debian bzw. auch irgendeine Konfiguration für die internen Plattenzugriffe noch getuned werden könnte, um die Kernauslastung nicht durch evtl. langsame Plattenzugriffe zu beeinträchtigen. Wie könnte ich die Ursache für das Ausbremsen finden? Welche Massnahmen würdet Ihr vorschlagen?

Grüsse,
Mac

PS: Nicht wundern. Wer sich heute in mehreren Linux-Foren herumtreibt, wird diese Anfrage nahezu identisch mehrmals wiederfinden. Hoffe das ist ok. Ergebnisstreuung sozusagen... ;)

Benutzeravatar
Ryven
Beiträge: 277
Registriert: 10.10.2003 09:20:52

Beitrag von Ryven » 06.08.2007 14:47:23

Toll, dann hast du schlecht gesucht.
Schaut dir blockdev dann, damit kanns du den Read-ahead des Kernels hochdrehen und an die Hw anpassen.
Es weiteren probier die Scheduler für die Platten durch. Die liefern teilweise gut messbare Unterschiede.

Ryven

MacLux
Beiträge: 11
Registriert: 06.08.2007 14:26:14

Beitrag von MacLux » 06.08.2007 14:55:48

Vielen Dank für den Tipp.

Ist 4096 für den Read-Ahead ein guter Wert (im Moment 256)? Oder nach welchen Kriterien sollte man das bestimmen?

Ist /etc/init.d/rc der geeignete Ort, um das dauerhaft festzulegen?

Gruss,
Mac

Benutzeravatar
mistersixt
Beiträge: 6601
Registriert: 24.09.2003 14:33:25
Lizenz eigener Beiträge: GNU Free Documentation License

Beitrag von mistersixt » 06.08.2007 15:51:29

Oft sieht man 8192 als sehr gute Werte, aber probier es doch einfach mit hdparm (hdparm -t /dev/[device]) aus (beispielsweise mit 2048, 4096, 8192, 16384).

Gruss, mistersixt.
--
System: Debian Bookworm, 6.5.x.-x-amd64, ext4, AMD Ryzen 7 3700X, 8 x 4.0 Ghz., Radeon RX 5700 XT, 16 GB Ram, XFCE

Benutzeravatar
Ryven
Beiträge: 277
Registriert: 10.10.2003 09:20:52

Beitrag von Ryven » 13.08.2007 00:52:06

Den Wert für read-ahead muss man austesten. Vom verlauf her ist der Periodisch gedämpft. Der erste Max-Hügel ist der beste.

Ich leg mir da eine Datei an in /etc/init.d/blockdev

Wie gesagt, test auch die Scheduler durch, du wirst überrascht sein. ;-)

Ryven

MacLux
Beiträge: 11
Registriert: 06.08.2007 14:26:14

Beitrag von MacLux » 13.08.2007 08:31:35

Ryven hat geschrieben:Den Wert für read-ahead muss man austesten. Vom verlauf her ist der Periodisch gedämpft. Der erste Max-Hügel ist der beste.

Ich leg mir da eine Datei an in /etc/init.d/blockdev

Wie gesagt, test auch die Scheduler durch, du wirst überrascht sein. ;-)

Ryven
Hab mit dem Wert auch schon herumgespielt und einen halbwegs befriedigenden gefunden. Gib mir noch mal bitte ein paar Hinweise zu "den Schedulern". Mir sagt das im Moment nicht viel, und Google-Ergebnisse bringen mir alles Mögliche.

Gruss,
Mac

Spasswolf
Beiträge: 3472
Registriert: 30.11.2005 10:32:22
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Wald

Beitrag von Spasswolf » 13.08.2007 11:39:15

Um für sda z.B. den deadline io-Scheduler auszuwählen:

Code: Alles auswählen

echo deadline > /sys/block/sda/queue/scheduler
Mehr dazu hier: http://www.wlug.org.nz/LinuxIoScheduler

MacLux
Beiträge: 11
Registriert: 06.08.2007 14:26:14

Beitrag von MacLux » 14.08.2007 08:16:14

Wow! Mit "deadline" geht der ja ab wie Pfiffi! :) Vielen Dank für den Tipp.

Gruss,
Mac

MacLux
Beiträge: 11
Registriert: 06.08.2007 14:26:14

Beitrag von MacLux » 15.08.2007 14:13:13

Achja, wo mache ich die Auswahl des Schedulers eigentlich am besten persistent? Soll ja nach dem Reboot immer noch gesetzt sein...

Gruss,
Mac

Antworten