OS-Optimierungen für Flash-SSDs

[7oby]

[*]Auslagerungsdatei verlagern
[...]
Das liegt einfach daran das ein 32-Bit-Programm von seinen 4GB virtuellem Speicher sowieso nur 1,8GB physikalisch nutzen kann, braucht es mehr geht dieser Teil in die Swapdatei.

Warum sollte das so sein?

Ein 32-Bit Programm im 32-Bit Windows OS hat maximal 2GB virtuellen Speicher. Mit dem Linker flag /LARGEADDRESSAWARE übersetzt, kann es 3GB virtuellen Speicher nutzen, wenn auch noch der /3GB Bootswitch (bzw. increaseuserva in BCDEDIT) mitspielt.

Wer aber die Auslagerungsdatei deaktivieren möchte, hat im Moment vermutlich eh >4GB. Sprich, wenn es ein Windows OS ist, hat er eine 64-Bit Version wie z.B. Vista 64-Bit. Dort hat jede Anwendung mit obigem Compileswitch dann 4 GB:
http://msdn.microsoft.com/en-us/library/aa366778.aspx

Wieviel Virtueller Adresspeicher von einer Anwendung adressiert werden kann (s.o. 2-4GB) hat natürlich nichts damit zu tun welche 4k Pages davon im Physikalischen Speicher liegen und welche im Swapfile. Vielmehr ist das Sache des Betriebssystem hier nach Zugriffsmustern zu entscheiden welche Pages ins Swapfile kommen und welche nicht. Dies im Gleichgewicht mit konkurrierenden Diensten wie z.B. Windows Datenträgercache und Superfetch, die prinzipiell so viel physikalischen Speicher haben wollen wie sie kriegen können.

Woher die 1,8GB Einschränkung kommen soll ist mir schleierhaft. Im Microsoft Jargon heißt die Menge an pages, die im physikalischen Speicher liegen, und einem Prozess gehören das Working Set. Ich kenne solche Einschränkungen nicht für das Working Set. Darüberhinaus gibt es auch eine API gibt um noch schneller und einfacher Speicher jenseits der 2GB anzusprechen (AWE) und explizit physikalischen Speicher (non-paged) zu fordern:
http://msdn.microsoft.com/en-us/libr...27(VS.85).aspx
Somit ist es ein leichtes für Anwendungen >1,8GB physikalisch anzusprechen.
--

Die Auslagerungsdatei zu deaktivieren ist möglicherweise auch bei 8GB Hauptspeicher nicht die beste Idee. Manche Anwendungen gehen verschwenderisch mit Hauptspeicher um (*), da ist es günstiger die Seiten wegzupagen u. den physikalischen Speicher für sinnvollere Dinge zu verwenden (und wenn es Superfetch ist). Angeblich soll sich Photoshop auch beschweren, wenn die Auslagerungsdatei deaktiviert ist.

Ich stimme also zu, dass das Auslagerungsdatei deaktivieren nicht unbedingt gut ist. Die Begründung mit den 1,8GB höre ich hingegen zum ersten Mal u. hätte gerne einen Link zum Nachlesen zu dem Thema. Auch wenn's Offtopic ist.

(*) entweder weil sie zu viel Speicher vorausschauend allokieren, ihn aber nicht nutzen. Oder aufgrund von Speicherleaks, die in C(++) schnell auftreten können wenn nicht sorgfältig analysiert und bei größeren Projekten Toolgestützt überprüft.

[Snoopy69]

Kann mir jmd erklären, warum Windows (Vista x64) trotz ausreichend Ram (4GB) auf pagefile.sys schreibt und davon liest?
Ich hab nun wie HisN auf I-Ram ausgelagert. Frage mich aber trotzdem, ob es nicht besser wäre auf 8GB aufzurüsten (kosten unter 60€) und dann pagefile.sys auf die Software-Ramdisk auszulagern. Immerhin wäre das x-fach schneller als I-Ram.

[7oby]

Kann mir jmd erklären, warum Windows (Vista x64) trotz ausreichend Ram (4GB) auf pagefile.sys schreibt und davon liest

4GB nennst Du ausreichend für Vista x64? Das ist ja weniger als 3,5GB unter Vista 32-Bit...

Selbst mit 8GB würde Vista pagen. Er tut es aus folgendem Grund:
. Geht Dir der Speicher aus, so müsste er erst speicher auf HDD auslagern (= langsam) und dann kann der freigewordene genutzt werden.

Windows ist schlauer und geht wie folgt vor:
. Von dem gesamten pageable memory lagert er schon einen Teil während dem Betrieb mit geringer Prozesspriorität auf HDD aus.
. Fordert ein Prozess mehr Ram als z.Z. verfügbar, so braucht zum großen Teil nicht ausgelagert zu werden, sondern lediglich einige Hauptspeicher Pages dem Prozess zugeordnet werden. Das funktioniert, da einige Seiten ja schon als 1:1 Kopie auf dem Hintergrundspeicher (pagefile) liegen.

Es ist also tatsächlich eine Performanceoptimierung von 2000/XP/Vista. Siehe in diesem Buch S. 819 "The Page Replacement Algorithm":
http://www.amazon.de/Modern-Operatin...dp/0130926418/

[Snoopy69]

Ok, dann erkläre mir warum Vista nicht die freien 30% Ram nutzt. Das sind ca. 1230MB freie Kapazität. Die Belegung in der pagefile.sys ist aber wesentlich weniger als 1230MB. In meinen Fall momentan ca. 310MB.

[7oby]

Weil obiges Prinzip nicht die alleinige Regel ist. Windows sorgt dafür, dass nicht ein Prozess einfach das gesamte Ram auffrisst und 99 andere Prozesse darunter leiden, indem sie sehr oft swappen müssen. Windows gibt einem Prozess nicht einfach Hauptspeicher, sondern nur innerhalb der Working Set Minimum/Maximum Pages. Fordert ein Prozess mehr, so werden zunächst die Pages des Prozesses beschnitten: Für jede Page, die der Prozess neu anlegt, wird erstmal eine andere des selben Prozesses ausgelagert. Also auch, wenn eigentlich noch genügend Ram verfügbar ist.

Minimum/Maximum Pages kann man als Administrator anpassen (weiß nicht auswendig wie, wird ein Registry Key sein). Die Grenzen sind aber ohnehin nicht statisch. In Windows sind genügend Heuristisken, die abhänig von der "Natur der Anwendung" das Paging Verhalten anpassen. Das mit den Minimum/Maximum Pages wusste ich auch gerade nicht auswendig. Hab's nachgeschlagen in besagtem Buch. Das erklärt dann warum Vista/XP auslagert auch wenn freier Speicher noch verfügbar ist. Allerdings aus einem anderen Blickwinkel als die geposteten 1,8GB.

Das funktioniert eigentlich auch sehr gut. Zumal Anwendungen auch explizit nicht pagebaren Speicher anfordern können. Der Programmierer einer Anwendung weiß womöglich noch besser welche Daten oder Code Teile er sehr häufig benötigt u. kann dafür sorgen, dass diese nicht ausgelagert werden.

Das Paging besteht aus einer Reihe von Prinzipien und von noch viel mehr Sonderfällen und Ausnahmen. Die wenigsten davon sind für XP/Vista irgendwo dokumentiert. Ist halt closed source.

Das beste was Du tun kannst (wenn Du kein Hibernation Feature benutzt): 6GB oder 8GB Ram. Das ist einfach und nützlich. Rumtweaken kann man sicher auch hier und da.

Der Prozess Scheduler ist ähnlich: Ein paar Prinzipien und sehr viele Ausnahmen. Selbst eine vermeindlich "simple" Kopierroutine in Windows ist unheimlich kompliziert. Für letzteres gibt's wenigstens auch einen Online Verweis:
http://blogs.technet.com/markrussino...4/2826167.aspx

[FischOderAal]

Wow. Dank dir für die Erklärung! Das gleiche hat mich auch immer gewundert (Festplatte am rattern wie wild und 800 MB RAM frei).

[Kannix]

Ohne zu wissen wie die interen Schreibroutine von SSDs auf feste Dateien aussieht:
Macht es vielleicht Sinn, die Auslagerungsdatei variable zu halten, zwischen 0 und bspw. 4 GB, um dafür zu sorgen, dass Änderungen innerhalb der Datei nicht immer auf die gleichen Blöcke der SSD geschrieben werden, wie es ja bei HDDs der Fall ist?

[Warbeast]

Oder vielleicht in der grösse der Erase Blöcke festlegen?

[Snoopy69]

@ 7oby

Danke

[HisN]

Ohne zu wissen wie die interen Schreibroutine von SSDs auf feste Dateien aussieht:
Macht es vielleicht Sinn, die Auslagerungsdatei variable zu halten, zwischen 0 und bspw. 4 GB, um dafür zu sorgen, dass Änderungen innerhalb der Datei nicht immer auf die gleichen Blöcke der SSD geschrieben werden, wie es ja bei HDDs der Fall ist?

Der Controller in der SSD regelt wo was hingeschrieben wird. Einen festen "Platz" auf dem Speicherträger gibt es nicht mehr.
Wenn ein Block ins Pagefile geschrieben wird, dann wandert der ganze Löschblock doch sowieso an eine andere Stelle der SSD :-)
Ob das jetzt mit dem Ändern der Pagefile-Größe was gerissen wird weiß ich nicht.

[Kannix]

Wenn ein Block ins Pagefile geschrieben wird, dann wandert der ganze Löschblock doch sowieso an eine andere Stelle der SSD :-)
.

Das war ja worauf ich hinaus wollte. Afair wird das ganze ja nicht gelöscht sondern nur aktualisiert/überschrieben.
Aber wenn das SSD-intern als löschen gehandelt wird, dann ist es ja ok ;-)

[Snoopy69]

Ob das jetzt mit dem Ändern der Pagefile-Größe was gerissen wird weiß ich nicht.

Kann man sicher überprüfen

[IndianaX2]

OK, bin auf meinem Notebook eben alle schritte durchgegangen.
Problem: Windows XP 32 will sich nicht als NTFS auf eine "aligned Partitionen" installieren, nur als FAT32.

Nun die frage, welches FS is für SSD besser?
Ein convert C: /FS:NTFS wäre ja schnell durchgeführt.

Mit dem WBEM bin ich mir noch nicht sicher, da ist noch jede menge Zeug drinnen was ziemlich mysteriös ist.

Edit: Ohne oder mit geändertem Workdir mag das ATI CC nicht!
Wobei WBEM auch nur schreibt wenn es benutzt wird => ambesten keine Monitoring sachen laufen lassen (z.b. SpeedFan & Co, mit Filemon beobachtet)

[barzefutz]

Vielen Dank an antiram für den Tipp mit dem Partiton alignment! Ich habe dazu noch ein paar Hinweise:

Benutzer von Windows Server 2003 SP1 und Windows Vista haben bereits die aktuelle Version von diskpart.exe und können dieser einfachen Anleitung folgen: http://technet.microsoft.com/en-us/l...EXCHG.65).aspx

Wer jedoch eine ältere Version von diskpart.exe hat (die in Windows XP und 2000) der bekommt eine Fehlermeldung beim Versuch den Parameter "align" zu benutzen. Es gibt aber eine Lösung. Entweder man holt sich die neue diskpart.exe von einem anderen Windows-System (habe ich nicht getestet). Ansonsten gibt es noch von Microsoft ein Windows 2000 Resource Kit, welches das Tool "diskpar.exe" (ohne t) enthält. Mit diesem Tool können auch unter XP und 2000 Partitionen ausgerichtet werden. Leider bietet MS dieses Kit nicht mehr zum Download an. Mit Google sollte man das Programm diskpar.exe aber finden können (ich will hier keinen Direktlink posten, bin mir nicht sicher ob das erlaubt ist).

Benutzung von diskpar.exe:

Programm in der Konsole öffnen: "diskpar -s x" wobei x die Nummer der SSD bzw. Festplatte ist. Diese Nummer kann man in der Datenträgerverwaltung nachschauen (wenn dort die SSD "Datenträger 2" heisst muss bei diskpar entsprechend eine 2 eingegeben werden). Dann bestätigen, und man bekommt die Option einen Startsektor für die erste Partition anzugeben. Jetzt muss man nur noch in die Datenträgerverwaltung gehen und die Platte mit dem gewünschten Dateisystem formatieren.

Ganz hartgesottene können den Startsektor auch direkt in den Master Boot Record schreiben, es müssen die CHS-Einträge des ersten und letzten Sektors für die gewünschte Partition eingetragen werden (siehe http://de.wikipedia.org/wiki/Partitionstabelle ).


Mal was zur Zuordnungseinheit des Dateisystems. Ich habe mir folgendes überlegt. Ich lasse ATTO laufen und sehe, dass ich bei den Random Writes einen sehr großen Sprung von 8k auf 16k habe (mehr als die doppelte Geschwindigkeit). Würde es dann Performancetechnisch sinn machen, die Clustergröße auf 16kb zu setzen? Oder habe ich da (mal wieder) falsch gedacht? Ich glaube fast ja, ich bringe dauernd durcheinander wie das alles zusammenhängt... und bringt es etwas, die Clustergröße auf die Größe eines erasable Blocks zu setzen?

[ulukay]

btw - hier gibts ne "freeware" ramdisk die bis zu 4gb grosse ramdisks machen kann
laeuft auch unter vista 64bit
http://www.cenatek.com/product_page_...nload_list.php
die neue beta version ...

load, save, autosave aus/in eine imagefile is moeglich!

[Freddy Mercury]

Ich habe ein paar Gedanken zum Booten, die ich gerne mit euch teilen möchte. Kurz zum Hintergrund: Habe (noch) keine SSD, benutze XP und habe mir gerade den Startvorgang angesehen, der ja mit einer (guten) SSD deutlich schneller läuft. Ich nutze selbst überwiegend Standby (S3), aber trotzdem einige Erkentnisse:

• Beim Start meines XP (2 Jahre alt, typische Vielnutzer-Installation) werden 216 MB an Daten gelesen
• Ich habe mir die Dateien per Zugriffsprotokoll angesehen:
  • Gesamt 879 Dateien (inkl. Autostart, z.B. Skype)
  • 150 Dateien sind < 1 KB
  • 204 Dateien sind 1 KB bis 10 KB
  • 262 Dateien sind 10 KB bis 100 KB
  • 226 Dateien sind 100 KB bis 1 MB
  • 37 Dateien sind > 1 MB, Spitzenreiter Skype.exe mit 22 MB
• Der Bootvorgang dauert etwa eine Minute (5.400er-Platte). Wenn davon auch nur ein Drittel auf die Lesevorgänge der Platte entfällt, ist das schon eine riesige Verschwendung! Grund: Man könnte doch die oben genannten 216 MB in eine große Datei packen, diese bei jedem Booten in den RAM laden und von dort aus weiterstarten:
  • Die Datei könnte einmalig angelegt werden und 1x pro Monat aktualisiert werden
  • Laden der Datei in den RAM beim Booten dürfte 3 Sekunden dauern
  • Fehlen Dateien im RAM, wird dieser Rest eben "normal" von der Platte geladen

Problem ist wohl, dass Windows keine solche Mechanik unterstützt? Ist doch eigentlich kein rocket science! Könnte man sowas basteln? Ich meine, auch eine SSD ist beim Zugriff auf kleine Dateien langsamer. Dafür läd sie die 200 MB aber in 2 Sekunden, und im RAM sind Wartezeiten nahe null anzunehmen.

[crysel]

Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.
Und den ganzen Kram schon im Ram zu speichern ist nicht möglich.. sobald der PC aus ist, ist der Ram wieder leer.
Beim Booten geht die meiste Zeit für die Initialisierung von Hardwareteilen oder Diensten drauf. Ich hab in meinem Notebook eine lahme 5400er gegen eine 16GB Mobi ersetzt. Booten geht zwar schneller, aber dauert trotzdem noch ca. 50Sek. und der XP-Balken muss 6mal durchlaufen. Aber nur bei 1-2 Balken zwischendurch leuchtet mal eben die SSD/HDD-Lampe auf, ansonsten langweilt die sich zu Tode.

[barzefutz]

Ich habe mal einige Tests durchgeführt mit verschiedenen Dateisystemen, Clustergrößen und Alignments.

Tests durchgeführt mit PCMark05 (File Write Bench) und einem Transcend 2GB Flash Modul.

STANDARD-AUSRICHTUNG ("krumme" 32 KB):

26.297 - fat32 16k
26.113 - fat16 64k
26.002 - fat16 32k
25.994 - fat32 512b
25.936 - ntfs 16k
25.664 - ntfs 4k
25.251 - ntfs 64k
25.196 - ntfs 512b

OPTIMIERTE AUSRICHTUNG (16 MB):

26.767 - fat16 64k
26.667 - fat32 16k
26.632 - fat16 32k
26.306 - ntfs 4k
26.161 - fat32 512b
26.069 - ntfs 64k
25.608 - ntfs 16k
25.294 - ntfs 512b


FAZIT:

Mit der optimierten Ausrichtung war alles insgesamt 1,5% schneller. FAT ist schneller als NTFS. Je höher die Clustergröße, desto höher die Geschwindigkeit.
Vielleicht stellt ja jemand ähnliche Tests an?

Bei mir war der Abstand merkbar, aber längst keine 18% wie bei antiram. Liegt das an nilfs?

Gute Nacht

[DerRob]

Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.

stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.

[HisN]

Was bei einer SSD wiederrum auf 80-240ms reduziert werden würde :-)

[crysel]

stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.

Naja, ok das hast du Recht. Aber dann müsste man erstmal eine große Datei hinbekommen.. könnte natürlich gezippt werden, dann beim Start in den Ram, dort entpacken lassen (sollte ja wesentlich schneller gehen ) und dann laden... da es sowas für den Bootvorgang aber nicht gibt --> SSD

[ulukay]

nennt sich hibernate und gibts schon lang

[7oby]

da es sowas für den Bootvorgang aber nicht gibt

So'n bißchen gibt's das schon u. wird von Microsoft ständig weiterentwickelt. Der Defragmentierer legt sich die Dateien, die er für's booten benötigt schon zusammen. Vista analysiert angeblich auch selbsständig die bootlogs u. baut das entsprechend um.

Das Problem entsteht ein klein bißchen weiter hinten im Bootprozess: Wenn die Services geladen werden bzw. spätestens beim Autostart: Die starten alle parallel und nicht staggered. Die Dateien sind auch nicht gerade klein: Viruskiller, verschiedene Updater, Skype, ... Da rennt der Schreib-/Lesekopf nur hin und her.

SSDs werden schon über kurz oder mittellang die Systemplatte ersetzen. Denn irgendwie tut sich Microsoft schwer den Bootprozess zu verkürzen - auch wenn sie ständig Verbesserungen einbauen (die aber von anderen Dingen wieder aufgefressen werden).

bg,
7oby

[Dr.Cupido]

wie finde ich heraus, wie groß meine Eraseblocks sind um mein Alignment richtig anzupassen ?

Im ersten Beitrag unter Vorbereitung kommt man auf einen Post,der auf das OCZ Forum widerum verweist, dieser Link ist jedoch für User gesperrt. Hab mich sogar extra dort angemeldet, aber auch so kann man nicht drauf zugreifen!

[antiram]

iometer nehmen und dann testen
128k; 100% random; 100% write; align I/O on 128k
256k; 100% random; 100% write; align I/O on 256k
512k; 100% random; 100% write; align I/O on 512k
1M; 100% random; 100% write; align I/O on 1M
2M; 100% random; 100% write; align I/O on 2M
4M; 100% random; 100% write; align I/O on 4M
8M; 100% random; 100% write; align I/O on 8M
16M; 100% random; 100% write; align I/O on 16M
32M; 100% random; 100% write; align I/O on 32M

die average I/O response time steigt zuerst langsam an. Ab einer bestimmsten Blockgröße (test x) verdoppelt sie sich dann immer im Vergleich zum vorherigen Blockgröße. Die Blockgröße bei test x ist die Größe der Eraseblocks.
zb.
1M Test: average I/O response time ca. 300ms
2M Test: average I/O response time ca. 600ms
4M Test: average I/O response time ca. 900ms
8M Test: average I/O response time ca. 1200ms <----- Größe der Eraseblocks = 8MB
16M Test: average I/O response time ca. 2400ms
32M Test: average I/O response time ca. 4800ms

im Anhang als iometer pattern. Bin mir aber nicht sicher obs woanders läuft weil ich es händisch editiert habe.