Read Ahead - für welche Zwecke nützlich/ungünstig

[maltris]

Für welche Zwecke ist Read Ahead erwiesenermaßen nützlich und für welche eher ungünstig?

- Datenbankserver
- Hypervisor
- Storage-Server

Bislang war meine gängige Methode "Standardeinstellung", was meist aktiviertes Read Ahead bedeutet. Ich möchte aber nun abhängig vom Zweck ein bisschen optimieren.

 

[d4f]

Readahead ist desto sinnvoller je sequentieller deine Reads sind. Für grosse Dateien ist es somit optimal, für ein kompletter Dump eines Emailpostfaches (viele einzelne Dateien quer über die Platte verteilt ist es (fast) unnütz.
Allerdings ist readahead generell recht "intelligent", wie diese Diskussion in der Postfix Mailingliste hervorbringt: http://www.postgresql.org/message-id/a1ec7d000809111207x3f5aefb9ybc66c556c532084b@mail.gmail.com
Es erkennt wohl kleine / zufällige Anfragen und überspringt diese entsprechend dann so dass die Platte keine von vornerein sinnfreie Blöcke liest.

StorageServer sind wegen oft grossen Dateien deshalb für readahead sehr geeignet, während Datenbankserver oft wenig Vorteile ziehen aber zu betonen bleibt dass sie keinen Nachteil haben (sollten). Bei Virtualisierung hängt es vollständig davon ab was in der virtuellen Maschine gemacht wird - im Mischbetrieb ist es in jedem Fall an zu raten, nur wie viele MB er buffern soll bleibt immer zu experimentieren.

[EDIT]
Nach Rubrik zu urteilen geht die Frage wohl eher um den platteninternen Buffer statt das eigentliche Readahead ( http://man7.org/linux/man-pages/man2/readahead.2.html ). Dieser bringt eigentlich technisch keine Nachteile da dort Blöcke reingeschoben werden welche der Kopf eh mitliest während er auf die korrekte Position schwingt und kann mit etwas Glück die nächste Anfrage bereits aus dem Buffer bedienen.

 

[elias5000]

... da dort Blöcke reingeschoben werden welche der Kopf eh mitliest während er auf die korrekte Position schwingt und kann mit etwas Glück die nächste Anfrage bereits aus dem Buffer bedienen.

Ist das nicht einfach NCQ oder geht das noch darüber hinaus? Wenn es mehr liest als in der Queue ansteht würde mich mal interessieren, wie die Platte "weiß", was da zusätzlich gelesen werden soll. Im Gegensatz zum System hat sie ja keinen Kontext zu den Dateien.

 

[d4f]

Ist das nicht einfach NCQ oder geht das noch darüber hinaus?

NCQ ist eine controllerinterne Verschiebung der Reihenfolge der wartenden Befehle. Wenn Befehl #5 bspw auf dem Arbeitsweg des Kopfes vor #2 kommt, wird dieser trotz späterer Anfrage bevorzugt. Durch die Positionierung des Kopfes über #5 wird Befehl #2 also tatsächlich ausgebremst, im _Durchschnitt_ werden die möglichen IOPS jedoch gut erhöht.
Dieses Wikipedia-Bild erklärt es sehr gut: https://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/NCQ.svg/300px-NCQ.svg.png


"Read ahead" respektive "Read behind" Buffering dagegen liest einfach alles mit was der Kopf beim Positionieren und nach Abschluss des Lesevorgangs eh noch mitkriegt. Es verbraucht im Gegensatz zu NCQ also keine Arbeitszeit (der Kopf ist ja eh da) und kann Antworten für direkt umliegende Sektoren später direkt aus dem Buffer beantworten.

Kurzum; beide Techniken sollten im Normalbetrieb aktiv sein und beide ergänzen sich prächtig.

 

[elias5000]

D.h. die Platte nimmt dann z.B. nach dem Positionieren auf die Spur einfach stumpf alle Blöcke mit, die so an ihr vorbei ziehen bis die gewünschten Sektoren vorbei rotieren? Mir war gerade nicht bewusst, wie groß die Caches mittlerweile geworden sind...

 

[d4f]

Soweit entsprechenden Dokumentationen sowie Wikipedia entnehmbar ist, ja. Allerdings wird nur sehr wenig über die Firmware und Logik der Festplattencontroller preisgegeben so dass der tatsächlich für solche Buffer genutzte Speicher potentiell nur einen kleinen Bruchteil des Controllerbuffers ausmachen kann.

 

[Deleted member 11740]

NCQ ist schon was feines. Das scheint auch bei SSDs Performance zu bringen, obwohl diese komplett anders arbeiten als rotatorische Medien.

 

[d4f]

Jap =)
SSD's benutzen NCQ übrigens genau umgekehrt wie Festplatten. Während HDD's versuchen die Befehle so zu legen dass die Anfragen möglichst nahe beieinander liegen, gehen SSD-Controller die einzelnen Module / Channels gleichzeitig belasten so dass mehrere Anfragen gleichzeitig bearbeitet werden können.

 

[maltris]

Das ist doch mal ein Thread mit Qualität!

Vielen Dank für die zahlreichen Antworten.

Die Diskussion darf gerne weitergehen!

 

[Deleted member 11740]

Teil 1:
Naja, man könnte sich noch über Puffergrößen unterhalten (sehr wichtig). Wenn man z.B. mit dd etwas kopiert, hängt die Geschwindigkeit unter anderem auch von der Puffergröße ab. Wählt man eine zu kleine Puffergröße, erhöhen sich automatisch die IOPS. Eine zu große Puffergröße wirkt sich auch negativ aus.

Teil 2:
Arbeitet man viel mit sockets und filedescriptors (Webserver z.B.), sollte man sich sendfile(2) ansehen. Mal ein Beispiel aus meiner Lieblingssprache: https://pypi.python.org/pypi/pysendfile

Wenn der Webserver, den man verwendet, das implementiert hat, ist man auf der guten Seite. Wenn dann noch libev/libevent genutzt wird, hat man den Nginx

Sehr interessanter Artikel zu dem Webserver: https://t37.net/nginx-optimization-understanding-sendfile-tcp_nodelay-and-tcp_nopush.html

 

[d4f]

Da landen wir dann aber neben dem eigentlichen Thema da wir hier im Hardware-Subforum sind und die Themenvorschläge allesamt das Betriebssystem betreffen

Dass sich mit entsprechendem Performancetuning und Eigenentwicklungen aus 0815-Umgebungen ein Hochleistungssystem bauen lässt hatte mir das ehemalige PHP-Friends Freehostingprojekt eindrucksvoll bewiesen. Immer wenn man dachte "jetzt ist das System am Ende" konnte man an obskuren Treiber und Kernelparameter (ohne wirkliche Dokumentation) noch was drehen oder durch intelligentes Buffern/Cachen die Last reduzieren. Dass am Ende so ziemlich jedes relevante System teilweise oder vollständig Marke Eigenbau(TM) wurde zeigt dabei nur wie schlecht die Standardeinstellungen und Standardprodukte eigentlich optimiert sind.

In jedem Fall ist es aber besser HDD-Anfragen zu vermeiden (noatime, Ram-Cache) als zu optimieren. Sprich: es kann günstiger und effektiver sein in mehr RAM oder SSD-Caches zu investieren als in schnellere Festplatten oder entsprechendes Tuning.