Max Trense wrote:
So einfach ist es eben nicht unbedingt. Striping bedeutet, dass
aufeinanderfolgende Blöcke (auf den Arbeitsspeicher übertragen sind das dann
wohl am ehesten Pages) auf unterschiedlichen physikalischen Medien befinden.
Der entscheidende Vorteil dieser Technik kommt zum Tragen, wenn eine Datei
sequentiell in den Arbeitsspeicher gelesen wird. Bei diesem Vorgang wird
jeder einzelne Block gelesen und an eine bestimmte Stelle in den
Arbeitsspeicher geschrieben. Da aber die meisten Komponenten eines Computers
Daten viel schneller übertragen können, als selbst die schnellsten
Festplatten, warten logischerweise während der Übertragung alle diese
Komponenten auf die Daten von der Festplatte. Legt man jetzt aber die
einzelnen Blöcke auf unterschiedliche Medien und ist die
Read-Ahead-Funktionalität richtig konfiguriert, kann man eben mehrere Blöcke
gleichzeitig laden. Selbst mit vielen Festplatten erreicht man so kaum die
Geschwindigkeit des Arbeitsspeichers, kann jedoch bei einer genügenden Anzahl
von Festplatten die Durchsatzrate erheblich steigern. Diese Steigerung liegt
im Regelfall bei nahezu 100%, was das Striping gerade für große Dateien recht
interessant macht.
Um das kurz auf den Punkt zu Bringen: Bei grossen Dateien, welche
sequenziell gelesen werden, wird das optimum da liegen wo der Read-Ahead
ein ganzzahliges mehrfaches der Groesse eines Stripes entspricht.
Ein Problem ist aber auch hier der Overhead. Der fällt im
Vergleich zur Performancesteigerung zwar recht gering aus, aber es gibt eben
auch Fälle, in denen es nicht möglich ist, mehrere Blöcke parallel zu lesen.
Eben dieser Fall ist bei Swap gegeben: Arbeitsspeicher wird in der Regel
nicht in zusammenhängenden Clustern benötigt, sondern meistens nur einzelne
Pages. Und das entspricht dem Laden eines einzelnen Blocks von der
Festplatte.
Kurze Frage: Warum müssen Pages, gerade bei multithreaded Anwendungen
oder MultiKern/Prozessoren, immer 'sequenziell' geswapped (Autsch, ganz
übles Neudeutsch) werden? Ich denke schon das hier mächtig
'parallelisiert' werden kann. Zudem ist die Wahrscheinlichkeit, das die
Blöcke welche gelesen oder geschrieben werden müssen auf
unterschiedlichen Platten liegen, beim Stripping (über zwei oder mehrere
Platten) nun mal nahe 50:50 (bei zwei) oder grösser (bei mehreren
Platten). Somit sollte eigentlich genau hier das Thema mit der
Verteilung des Overheads (Kopfbewegung) greifen.
Da dieser Vorgang nicht parallelisierbar ist, gibt es natürlich
auch keine Performance-Steigerung.
Nochmal. Warum nicht?
BTW. die Grösse einer Page ist nicht zufällig ein Vielfaches von 512
Byte und somit ein ideales Vielfaches der Blockgrösse, was dann wieder
ideal zum Read-Ahead passt?
Einen ähnlichen Fall gibt es bei sehr
kleinen Dateien. Natürlich könnte man nun die Blockgröße des Dateisystems auf
einen kleineren Wert konfigurieren. Das bringt allerdings wegen der Seektime
der Festplatte nicht besonders viel.
Bei der Änderung der Blockgrösse wird man bei einer nicht fragmentierten
Datei wohl keinen Unterschied messen, zumindest nicht wenn die Datei
nicht über die Zylindergrenze der Platte hinausreicht und somit ohne
Kopfbewegung gelesen wird. (und so ein Zylinder ist schon mächtig gross.
;-) )
Die Abwägung zwischen Striping oder nicht ist also wirklich nicht ganz trivial
und definitiv nicht allgemein entscheidbar ;-)
Genau dies kann ich aber aus Deinen Ausführungen eben nicht entnehmen. :-(
Wo ist da eigentlich der Unterschied zwischen zusammenhängendem Speicher
und Dateien?
Hauptsächlich in der Blockgröße und der Zugriffsmethode.
Hmm, versteh ich nicht. ;-)
Die Blockgrösse auf der Platte ist für beide gleich und bei 'ner
Datenbank gibt es bestimmt genauso viel 'Random-Access' wie beim Swappen.
Und eine Swap-Partition ist unter Unix sowieso wie alles eine Datei.
(*duckundweg*)
Gruß,
Klaus
--
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
