[DK2000]

Die Auslagerungsdatei sollte eigentlich auf einer NTFS Laufwerk mit 4Kb Clustern liegen, welches sich auf einer Festplatte befinded, welches wiederum an einem eigenen ATA Kanal hängt und zu keinem RAID Verbund gehört. Clustergrößen über 4Kb sind ungünstig, da das System die ausgelagerten Speicherseite in 4Kb große Stücke verwaltet. Clustergrößen, die darüber hinaus gehen, können bei hoher Last die Performance drücken, da hier meist überflüssiger Speicher gelden werden muss, der aber nicht eigelagert wird.

Auch ist es egal, in wievie Stücke die Datei unterteilt ist. Das System merkt sich in einer Tabelle, wo welche Speicherseite innerhalb der Datei gespeichert ist und kann somit den Speicher zielgenau finden. Microsoft selber empfiehlt ja, zweckst Lastverteilung und somit Performancesteigerung die Auslagerungsdatei auf mehrere eigenständige Festplatten zu verteilen. Geringe Perforanceverluste gibt es nur, wenn sich der einzulagernde Speicher über so eine Lücke erstreckt. Allerdings bewegen sich diese Verluste in Bereiche, die man allenfalls mit irgendwelchen Benschmarks feststellen kann. Im Normalbetrieb fällt das nicht auf.

Außerdem, wenn man die Auslagerungsdatei auf einem frisch formatiertem NTFS laufwerk erstellt, hat diese 2 Fragmenten (max. 3). Wenn sie dennoch aus deutlich mehr Fragmenten besteht, sind entweder Sektoren auf der Festplatte als defekt gekennzeichnet (die werden logischerweise ausgelassen) oder die Partition war nicht frisch formatiert. Mehr als drei Fragmente hatte ich noch nie bei einer 4GB großen Auslagerungsdatei. Nagut, wenn man es geschickt antellt, dann sieht eine 3GB große Auslagerungsdatei auf einer 5GB Partition so aus:



Aber normalerweise besteht meine Auslagerungsdatein aus 2 Fragmenten. Gut, die auf der C:\ ist nur 32MB groß und immer am Stück.

Auch die Einstellung "SecondLevelDataCache"=bla bla bla ist i.d.R. überflüssig, da default der Wert 0 gesetzt ist. Damit erkennt das System automatisch die richtige Größe des L2 Caches. Überprüfen kann man das, wenn man als Administrator in der Console wmic CPU get L2CacheSize eingibt. Wenn als Ausgabe die richtige Cachegröße angezeigt wird, ist der Eintrag in der Registry überflüssig (was meist die Regel ist).

Dieser Beitrag wurde von DK2000 bearbeitet: 12. April 2005 - 15:26

[Murmel]

Zitat (max: 12.04.2005, 14:01)

Eine Auslagerungsdatei, die in mehreren Teilen auf der Festplatte liegt ist langsamer als eine in einem ganzen Teil.
<{POST_SNAPBACK}>

Wer redet denn davon? Kein Mensch spricht von sowas. Und ich hab sowas auch nicht gepostet. Geh mal meine Empfehlung für die Aufteilung der Festplatten durch und sage mir dann mal, wo dies da steht. Das steht

Zitat

1x SATA Maxtor DiamondMax 10; 300GB; 16MB Cache
IDE Port 2=Master
Erweiterte Partition=300GB
4. F:\ Cache=2GB Auslagerungsdatei

Bei jedem Post von Dir in diesem Thema erfindest Du immer mehr.
Jetzt ist es aber wirklich langsam genug.

[DK2000]

@max

Zitat

Ich hatte dir nur empfohlen, dass du dir mal eine Partition für die Auslagerungsdatei anlegst, damit du siehst, das diese sich, wenn die Partition zu groß ist, in mehrere Teile aufsplittet.

Es bezog sich auf diese Aussage, die so nicht ganz nachvollziehbar ist. Eine "zu Große" Partition für die Auslagerungsdatei gibt es eigentlich nich. Das System versucht eigentlich die Datei in einem Stück zu erstellen. Ist das nicht möglich, wird sie gesplittet, also fragmentiert. Bei NTFS meist in zwei Teile, da der reservierte Raum für die MFT im Weg ist, ab und zu auch in drei Teile, wenn die Systemwiederherstellung oder der Indexer schon irgendetwas in System Volume Information geschrieben hat. Aber bei einem Frisch formatierten Laufwerk mit Mindestgöße von Max Auslagerungsdate + 5 MB (statisch eingestellt) dürften nicht mehr als 3 Fragmente entstehen.

So, und jetzt kam ich mit den Lücken. Damit meine ich den freien oder auch belegten Platz zwischen den einzelnen Fragmenten der Auslagerungsdatei. Solange das Laufwerk wirklich frisch formatiert ist und wirklich 100% Fehlerfrei entsteht im Optimalfall keine Lücke, also Auslagerungsdatei am Stück. Ist die MFT im Weg, entsteht eine Lücke, also zwei Fragmente der Auslagerungsdatei. Normlerweise wars das. Es kann noch zu einer dritten Lücke kommen, wenn der Ordner System Volume Information oder der Mülleimer Inhalt hat (sollte man auf diesem Laufwerk deaktivieren), aber mehr dürfte nicht kommen.

Der Shot von Meiner Auslagerungsdatei ist von vorhin, aber die ist so schön am Stück, seit ich sie angelegt habe (vor gut 5 Wochen). Solange sie statisch eingestellt ist, verändert die sich nie wieder (gut, außer man geht mit irgendwelchen dummen Defrag Tool zur Sache).

Wenn Du jetzt sagst, die Datei fragmentiert Dir in Abhängigkeit einer "zu großen" Partition, dann stimmt da was nicht oder sie ist dynamisch eingestellt. Denn eigentlich ist es so, je Größer die Partition im Vergleich zu der Auslagerungsdatei ist, desto weniger Fragmente bekommt die (bei statischer Einstellung auf frisch formatierter Platte). Keine meiner beiden statischen Auslagerungsdateien sind seit der Installation fragmentiert.

[Murmel]

@ max
Fat16=keine MFT, Papierkorb deaktiviert, Swapdatei mit fester Grösse=kein Splitten, keine Defragmentierung. Und hierbei spielt es keine Rolle, ob die Swapdatei genauso gross wie dir Partition selber oder kleiner ist. Sie ist und bleibt in einem Stück.

[puppet]

Die fragmentierung der Auslagerungsdatei ist sowieso egal, da die Schreib-/lesezugriffe auf den Inhalt der Datei per Zufall und nicht linear erfolgen.
Und Windows XP kann von NTFS schneller lesen als von FAT, beim schreiben sind die Werte ungefähr gleich. Wer will kann dies ja mit iozone testen.

Es wäre (wenn überhaupt) sinnvoll die Auslagerungsdatei auf einen seperaten Datenträger zu legen, wo während der Arbeit kein Programm auf den Datenträger zugreift.
Man sollte aber beachten die Partition 4GB groß zu machen, falls man doch mal mit dem System "arbeitet" und Windows die Auslagerungsdatei vergrößern muss.

Dieser Beitrag wurde von puppet bearbeitet: 12. April 2005 - 20:05

[puppet]

Mache doch selber den Test!
Bei meinen Tests war NTFS beim lesen um 1 MByte/s schneller als FAT16, und beim schreiben waren es jeweils nur wenige KB/s unterschied.
Testumgebung:
30GB WD IDE ATA-66 5400RPM 2MB, 2GB Partition am Ende der Platte, 1GB und 2GB Filesize, FileBlockSizes von 2KB bis 1MB.

Und man sollte seinen virtuellen Speicher so einstellen das man ihn im Notfall voll ausnutzen kann (z.B. bei 512MB RAM eine Partition von 3.5GB, wie groß die File sein sollte spielt dabei wie schon gesagt von der Perfomance her keine Rolle!). Wer will schließlich schon einen Datenverlust haben wenn sein Programm abschmiert weil Windows den virtuellen Speicher nicht liefern kann weil die Partition für die Swapfile zu klein ist?

Dieser Beitrag wurde von puppet bearbeitet: 12. April 2005 - 21:01

[Murmel]

Das ist das einzige Handycap bei Fat16, die grösse der Partition=2GB, aber wer mehrere Festplatten drin hat, so wie bei mir=3x naja da kann man das ausgleichen, indem man auf der 2. und 3. jeweils am Anfang eine 2GB Fat16 Partition anlegt. Aber ich arbeite bloss mit einer Swapdatei.

[XDestroy]

Also ich habe auf meiner 160gb nur eine partition mit ntfs. letztendlich sehe ich keinen grund für partitionen. ich bin auch in der lage ohne diese darstellung von laufwerken ordnung zu halten. sonst ist da kein vorteil vorhanden. auch nicht in der anordnung der daten. das einzige was zumindest logisch vorteil bietet ist die auslagerung auf platte 2. wirkt sich aber nicht spürbar aus. habe das mit meinem letzten system ausführlich getestet und habe keinen vorteil gehabt. statt dieser fuckelei lieber nen gig ram zusätzlich rein das bringt ne ganze ecke mehr!

[Win-Fan]

Zitat (XDestroy: 13.04.2005, 13:17)

Also ich habe auf meiner 160gb nur eine partition mit ntfs. letztendlich sehe ich keinen grund für partitionen. ich bin auch in der lage ohne diese darstellung von laufwerken ordnung zu halten. sonst ist da kein vorteil vorhanden.
<{POST_SNAPBACK}>

Doch, da es bei Partitionen eigentlich weniger um die Ordnung im System geht, sondern mehr um die Sicherungsfunktion der Daten bei einem Systemabsturz. Das also die Daten, egal welcher Art, vom eigentlichen System getrennt sind. Wieviel Partitionen jeder anlegt ist natürlich immer sache des Nutzers.

[puppet]

Wenn die Platte abschmiert hilft das auch nicht mehr viel. Backups gehören auch nicht auf das eigene System, und schon gar nicht ein Backup von einer Platte auf die selbige machen. Backups haben ihren Platz auf einem anderen System.
Und Backups kann man auch in einen Ordner legen, dazu benötigt man keine extra Partition.

[Win-Fan]

Zitat (puppet: 13.04.2005, 13:35)

Wenn die Platte abschmiert hilft das auch nicht mehr viel.

Das ist natürlich richtig, aber es ging ja um einen Systemabsturz, und da macht es schon Sinn. Zumal die warscheinlichkeit eines Plattendefektes sehr gering ist.

Zitat

Backups haben ihren Platz auf einem anderen System.

Auch richtig und natürlich die bessere Lösung, nur macht es aus sicht deines Argumentes wegen des Plattendefektes dann natürlich auch nur wieder bedingt Sinn. Du siehst, wenn man immer von einem Plattendefekt ausgeht, dreht man sich im Kreis.

Zitat

Und Backups kann man auch in einen Ordner legen, dazu benötigt man keine extra Partition.

Dann kann man sich aber gleich eine Datensicherung sparen, wenn du den Ordner auf der Systempartition lassen willst. Das macht also dann gleich garkein Sinn.

Dieser Beitrag wurde von Win-Fan bearbeitet: 13. April 2005 - 12:51