Windows - Virtueller Speicher?

[Manu]

Hallo


ich hab vorhin eine Fehlermeldung erhalten und zwar steht da:

Dem System steht nicht mehr genügend virueller Speicher zur Verfügung. Vergrössern Sie die Auslagerungsdatei für den virtuellen Speicher...


Wo kann ich den vegrössern? Und wie hoch sollte der etwa sein?

Danke schon mal

[Manu]

Habe es jetzt gefunden. Also da steht:

Gesamtgrösse der Auslagerungsdatei für alle Laufwerde: 768 MB

Wenn die da auf ändern klicke steht u.a.:

Laufwerk C:
Verfügbarer Speicherplatz: 15340 MB

Anfangsgrösse (MB): 768
Maximale Grösse (MB): 1536


Wie muss ich es jetzt einstellen um diesen Fehler zu vermeiden?

[mofa84]

normal sollte das schon reichen, oder bei welcher Anwendung kam das?

Nur wenn du mit großen Grafiken usw. arbeitest brauchst du mehr.

Aber sonst stell halt mal als Anfangs- und max. Größe 2048MB ein.

[Manu]

Hi

um Videos zu Bearbeiten (das braucht wohl schon ziemlich enorm viel, denke ich).

Danke, also Du meinst das anfangs und maximal auf 2048 MB?


Vielleicht noch einige Daten zum Rechner:

AMD 2400+
2 mal 256 MB Kingston ValueRam
Asus A7N8X Deluxe Mainboard
Maxtor DiamondMax 7200rpm IDE 120GB HD
...

[mofa84]

Original geschrieben von Manu
Hi

um Videos zu Bearbeiten (das braucht wohl schon ziemlich enorm viel, denke ich).

Danke, also Du meinst das anfangs und maximal auf 2048 MB?


Vielleicht noch einige Daten zum Rechner:

AMD 2400+
2 mal 256 MB Kingston ValueRam
Asus A7N8X Deluxe Mainboard
Maxtor DiamondMax 7200rpm IDE 120GB HD
... ja, bei Videos brauchste schon einiges.

Ich würd die Größe der Auslagerungsdatei deswegen konstant machen weil die sich sonst fragmentiert was wiederum bremst.

[..,-]

Original geschrieben von mofa84
Ich würd die Größe der Auslagerungsdatei deswegen konstant machen weil die sich sonst fragmentiert was wiederum bremst.
Sie kann theoretisch fragmentiert werden. Na und? Wenn so viel ausgelagert wird, schneckt die Maschine sowieso schon vor sich hin, eine eventuelle Fragmentierung merkst du da überhaupt nicht mehr.

Wer zahlreiche Gigabytes an ungenutztem Festplattenspeicher rumliegen hat, der kann das natürlich gerne tun, aber einen Vorteil bringt es nicht, das sind alte Ammenmährchen.

[Denniss]

Bei größeren Videobearbeitungen empfiehlt sich eher eine speicheraufrüstung denn 512MB sind da recht wenig

[mofa84]

Original geschrieben von ..,-
Sie kann theoretisch fragmentiert werden. Na und? Wenn so viel ausgelagert wird, schneckt die Maschine sowieso schon vor sich hin, eine eventuelle Fragmentierung merkst du da überhaupt nicht mehr.

Wer zahlreiche Gigabytes an ungenutztem Festplattenspeicher rumliegen hat, der kann das natürlich gerne tun, aber einen Vorteil bringt es nicht, das sind alte Ammenmährchen. ich hab erst ne Datei von einer Platte auf die andere kopiert (ca. 700MB), und es hat ewig gedauert, im Vergleich zum Rest, und anschließen hab ich gesehen dass die verdammt fragmentiert war, trotz NTFS!
Also ganz so schlimme Ammenmärchen sind das nicht!

[Zool]

Also bei NTFS gibt es genauso viel Defragmentierung wie bei FAT32/16.


Zum defragmentieren des Pagefiles empfielt sich OO-Defrag Pro oder als Freeware Alternative Pagedefrag http://www.sysinternals.com

[mofa84]

Original geschrieben von Zool
Also bei NTFS gibt es genauso viel Defragmentierung wie bei FAT32/16.[/url] M$ behauptet bei NTFS wäre es kaum nötig zu defragmentieren, inwiefern das stimmt kann ich allerdings nicht sagen.

[..,-]

Original geschrieben von mofa84
ich hab erst ne Datei von einer Platte auf die andere kopiert (ca. 700MB), und es hat ewig gedauert, im Vergleich zum Rest, und anschließen hab ich gesehen dass die verdammt fragmentiert war, trotz NTFS!
Also ganz so schlimme Ammenmärchen sind das nicht!
Wer sagt, dass da ein Zusammenhang besteht? Windows kopiert große Datein sowieso nicht "am Stück", indem es sie komplett in den Arbeitsspeicher lädt.

[x-dragon]

Original geschrieben von mofa84
M$ behauptet bei NTFS wäre es kaum nötig zu defragmentieren, inwiefern das stimmt kann ich allerdings nicht sagen. Hab mal eben schnell gesucht:

"Vorteile von NTFS gegenüber FAT
...
- Schreibt Dateien „intelligent“ um so Fragmentierung zu verhindern, FAT schreibt Dateien einfach nur hintereinander
...
http://www.pc-special.net/?idart=1565"

[mofa84]

Original geschrieben von ..,-
Wer sagt, dass da ein Zusammenhang besteht? Windows kopiert große Datein sowieso nicht "am Stück", indem es sie komplett in den Arbeitsspeicher lädt. wenn ich aber von einer physischen platte auf die andere kopiere muss der lesekopf aber theoretisch nicht ständig hin- und her, also muss es an der defragmentierung liegen. und wenn ich dann im defrag schau zeigt mir das an dass diese Datei über 2000 Fragmente hat.

[..,-]

Original geschrieben von mofa84
wenn ich aber von einer physischen platte auf die andere kopiere muss der lesekopf aber theoretisch nicht ständig hin- und her, also muss es an der defragmentierung liegen. und wenn ich dann im defrag schau zeigt mir das an dass diese Datei über 2000 Fragmente hat.
Von welcher Datei redest du jetzt bitte? Von der Auslagerungsdatei oder von der kopierten Datei? ???

[mofa84]

Original geschrieben von ..,-
Von welcher Datei redest du jetzt bitte? Von der Auslagerungsdatei oder von der kopierten Datei? ??? von der kopierten - weil du behauptet hast das mit Fragmentation wäre nicht mehr aktuell.

[..,-]

Original geschrieben von mofa84
von der kopierten - weil du behauptet hast das mit Fragmentation wäre nicht mehr aktuell.
Neee, nee. Natürlich gibt es auch unter NFTS noch Fragmentierung. Sowohl Fragmentierung des freien Speichers (was an sich völlig harmlos ist und nur dann zum Problem wird, wenn nicht mehr genügend zusammenhängender Plattenplatz da ist, um eine neue Datei an einem Stück speichern zu können), als auch Fragmentierung von Dateien. Und dass eine fragmentierte Datei immer langsamer zu lesen und zu schreiben ist, ist ja klar.

Nur ausgerechnet die (unter Umständen auftretende) Fragmentierung der Auslagerungsdatei kann man als Argument getrost vergessen. Wenn so massiv ausgelagert werden muss, dann macht es den Braten ohnehin nicht mehr fett. Dafür jederzeit extra ein oder gar mehrere Gigabyte für eine permanent große Auslagerungsdatei zu opfern, lohnt sich einfach nicht.

Im Gegenteil, es erhöht sogar das Risiko, dass Dateien fragmentiert werden, weil die Platte schneller voll wird. Und bei einer zu 90% vollen Platte wird die Mühle nunmal kreuzlangsam, egal, was mit der Auslagerungsdatei ist.

[Lokadamus]

mmm...

Da erhebe ich mal spontan Einspruch ... mit Norton kannst du unter Fat 32 (ich weiss nicht, wie gut es mit NTFS arbeitet) sehr schön die komplete Auslagerungsdatei an den Anfang oder an das Ende der HDD verlegen. Dadurch braucht der Kopf nicht mehr soviel springen und kann die ganzen Daten nacheinander ablegen, was ansonsten noch länger dauern würde ... ihmo bringt es etwas, wobei es natürlich noch auf die restliche Auslastung des System kommt, wenn die HDD aber schnell arbeiten soll, führt kein Weg daran vorbei, die Auslagerungsdatei fest zu setzen und zu defragmentieren, ansonsten springen die Köpfe mehr durch die Gegend und das kostet Zeit, fällt aber bei 2 MB Cache an der HDD nicht so schnell auf ...

[mofa84]

Original geschrieben von Lokadamus
fällt aber bei 2 MB Cache an der HDD nicht so schnell auf ... dazu möcht ich mal sagen dass ich mehr wie 2MB Cache sowieso nicht für sonderlich sinnvoll halte bzw. 8 nicht mehr bringen - die aktuellen Platten haben mehr als 40MB/s und das bei über 200GB Kapazität, was soll da in 8MB Cache zwischengespeichert werden?

Die 2MB Cache hatte ich schon bei meiner 2,1GB Seagate, seitdem hat sich (bei manchen Platten) der Cache vervierfacht und die Kapazität verhundertfacht.

[Lokadamus]

mmm...

Ich denke, der Cache wird so genutzt, wie Smartdrive arbeitet, es wird einfach die Datei weiter eingelesen, als wirklich gerade benötigt wird ... macht beim kopieren/move/delete keinen Sinn, aber beim alltätglichen Arbeiten von grossen Grafiken, Powerpointpräsentationen und ähnlichen Sachen würde es zu einem ruhigeren Laufverhalten der HDD führen, weil die Datei schon teilweise geladen wird und bei Anfrage gibs die Daten schon, während der Kopf noch zum nächsten Fragment geht ... genau weiss ich es nicht, aber alles andere macht keinen Sinn, weil die meisten Dateien doch schon grösser sind als 2 MB ...

[..,-]

Original geschrieben von Lokadamus
Da erhebe ich mal spontan Einspruch ... mit Norton kannst du unter Fat 32 (ich weiss nicht, wie gut es mit NTFS arbeitet) sehr schön die komplete Auslagerungsdatei an den Anfang oder an das Ende der HDD verlegen. Dadurch braucht der Kopf nicht mehr soviel springen und kann die ganzen Daten nacheinander ablegen, was ansonsten noch länger dauern würde ... ihmo bringt es etwas, wobei es natürlich noch auf die restliche Auslastung des System kommt, wenn die HDD aber schnell arbeiten soll, führt kein Weg daran vorbei, die Auslagerungsdatei fest zu setzen und zu defragmentieren, ansonsten springen die Köpfe mehr durch die Gegend und das kostet Zeit, fällt aber bei 2 MB Cache an der HDD nicht so schnell auf ...

Logisch, dass ich dagegen gleich mehrfach Einspruch erheben muss.

Wieso sollte eine Position der Auslagerungsdatei ganz am Anfang oder am Ende (erstaunlich das beides gleich gut sein soll...) in irgendeiner Weise die Zeit für die Bewegung der Köpfe minimieren können? Solange du nicht vorher genau weißt, wo sich die Köpfe gerade befinden, wenn Windows zufällig der physische Speicher ausgeht, (und das weißt du ganz sicher nicht ...) geht dieser Ansatz bereits voll in die Hose.

Wenn man annähme, dass die Zugriffe über die Plattenkapazität mit etwa gleichverteilter Häufigkeit stattfinden, dann wäre der beste Platz für die Auslagerungsdatei gerade in der Mitte der Platte, aber auf keinen Fall am Anfang oder am Ende.

Diese seltsame Strategie der Platzierung der Auslagerungsdatei hat mit den Latenzen durch die Kopfbewegungen folglich gar nichts zu tun. Für den Anfang der Platte spräche ja noch, dass dort die Dauertransferrate am Höchsten ist, aber ob die beim Zugiff auf die Auslagerungsdatei überhaupt entscheidend ist (oder nicht doch eher die Zugriffszeit) hängt ganz von der Art der Auslastung der Auslagerungsdatei ab. Auch wenn es sich um eine einzige Datei handelt, wird sie noch längst nicht immer vollständig sequentiell eingelesen. Im übrigen ist dieser "Optimierungsansatz" natürlich davon abhängig, dass man auch brav an die Notwendigkeit einer festen Größe glaubt. Als Beweis für diese Notwendigkeit taugt er nicht.


Auch hat der Festplattencache auf die Latenz durch springende Köpfe bei stark fragmentierten Dateien oder jeder Benutztung (!!) der Auslagerungsdatei nun überhaupt keinen Einfluss.

Zum einen wäre eine Firmware, die die Köpfe der Platte hüpfen lässt, obwohl sie die benötigten Daten im Cache hat, schlicht untauglich.

Zum anderen schau dir doch bitte mal das Größenverhältnis an: Wir reden hier von 2 bis maximal mickrigen 8 MB Cache (der auch noch in Lese- und Schreibcache unterteilt ist und von dessen Größe oft in Wirklichkeit noch die Firmware abgezogen werden muss) gegen Auslagerungsdateine von vielen hundert Megabyte. Denn wenn schon eine Auslagerungsdatei fester Größe, dann bitte auch so groß, dass der Rechner nicht mitten im Programm wegen Speichermangel abkackt.

Über die (nicht gegebene) Effizienz von Festplattencaches in Zeiten, in denen selbst Windows einen hocheffektiven (und viel, viel schnelleren) Datenträgercache per RAM zur Verfügung stellt, finden sich hier im Forum (Suche) ohnehin schon genug Beiträge, z.B. von Endorphine.

[Lokadamus]

mmm...

1.) Ich meine, die beste Übertragungsrate hast du am Anfang einer HDD (der Kreis ist dort am kleinsten), darum an den Anfang ...
2.) Genau in der Mitte wäre ein Fehler, woher willst du wissen, das genau davor die Sektoren von einer Datei beendet wird und diese nicht noch mehr Sektoren braucht ? ansonsten hast du wieder nen Jump vom Lesekopf, der nicht sein muss ...
3.) Am Ende kannst du sie auch packen, wenn du der Auslagerungsdatei eine feste Grösse gibt, schliesslich wird die Datei nicht weiter verschoben weil nicht grösser oder kleiner ...
4.) Stellst du eine feste Grösse ein (je nach Interessen wohl zwischen 256 bis 1 GB), hängt die Datei zusammen, sprich, beim reinschreiben braucht der Kopf nicht zwischen Anfang, Mitte und Ende hin und her springen, nur weil du einige andere Dateien dazwischen stehen hast (die HDD wird auch leiser dadurch, viele jumps der Köpfe kannst du am rattern der HDD erkennen, probier es doch aus, einmal die HDD auf eine Fragmentation von ca. 50 % zu bringen, aber noch gut ca. 1 GB an Platz und kopier dann mal eine grosse Datei (lass sie mal ca. 500 MB gross sein) darauf und guck zu wie die Lampe leuchtet, lösch die Datei, fragmentiere die HDD mit einem ordentlichen Programm (mit dem Standardteil kann man nicht soviel einstellen) und kopier danach nochmal die 500 MB grosse Datei rauf, deiner Meinung nach wird es keine Unterschiede bringen, ich sag dir, du wirst etwas merken (eventuell um einiges schneller, aber um einiges ruhiger auf jedenfall)) ...

Nachdem was du schreibst, macht Cache keinen Sinn, warum haben sie den trotzdem Cache drauf ? Laufruhe ? wie kannst du Laufruhe erzeugen ? Performencesteigerung ? erreichst du nur, indem der nächste Sektor schon gesucht wird, während der aktuelle Sektor gerade auf Reisen geht (bei Fat 32 kann ein Sektor 32 KB gross sein und diese werden schon zusammen gesucht, bis die 2 MB Cache voll sind, imho), genauso kannst du dadurch auch eine bessere Laufruhe erreichen, weil die HDD nicht "hetzen" muss, sondern so lange Zeit hat, wie die Daten über den PCI-Bus brauchen, um die nächste Paketsammlung zusammen zu stellen, ohne Cache rattern die HDD's wie sau, woran mag das nur liegen ? ;) ...

[..,-]

Original geschrieben von Lokadamus
1.) Ich meine, die beste Übertragungsrate hast du am Anfang einer HDD (der Kreis ist dort am kleinsten), darum an den Anfang ...
Falsch, der Anfang ist bei Festplatten außen, daher die höchste Transferrate bei sequentiellem (war das fett genug?) Zugriff (der für die Auslagerungsdatei nicht unbedint entscheidend ist). Außen liegen pro Umdrehung mehr Sktoren, klar?

2.) Genau in der Mitte wäre ein Fehler, woher willst du wissen, das genau davor die Sektoren von einer Datei beendet wird und diese nicht noch mehr Sektoren braucht ? ansonsten hast du wieder nen Jump vom Lesekopf, der nicht sein muss ...
Das gilt für jede Datei, nicht nur für die Auslagerungsdatei. Dass in der Mitte der Platte irgendeine große Datei zu liegen kommt, kann man ohnehin nicht verhindrn. Ihr scheint hier dem Irrtum zu unterliegen, die Auslagerungsdatei würde vor allem beim Transfer großer Dateien gebraucht. Das ist natürlich nicht der Fall.

Wenn die Auslagerungsdatei in der Mitte der Festplatte liegt, ist die durchschnittliche Zeit, um die Köpfe von irgendwoher auf der Platte zur Auslagerungsdatei zu bewegen, minimal.

3.) Am Ende kannst du sie auch packen, wenn du der Auslagerungsdatei eine feste Grösse gibt, schliesslich wird die Datei nicht weiter verschoben weil nicht grösser oder kleiner ...
Die Auslagerungsdaei muss eine feste Größe haben, weil man sie an das Ende der Platte (da, wo es besonders langsam ist) legen sollte. Man muss die Auslagerungsdatei an das Ende der Platte legen, weil sie eine feste Größe haben sollte. Das nennt man zirkuläre Logik.

4.) Stellst du eine feste Grösse ein (je nach Interessen wohl zwischen 256 bis 1 GB), hängt die Datei zusammen, sprich, beim reinschreiben braucht der Kopf nicht zwischen Anfang, Mitte und Ende hin und her springen, nur weil du einige andere Dateien dazwischen stehen hast
Wenn du keine fest Größe einstellst, ist die Auslagerungsdatei ebenfalls zusammenhängend. Warum auch nicht? Nur dann, wenn die Auslagerungsdatei ausnahmsweise mal zu klein sein solle, wird sie dynamisch erweitert. Dabei kann es dann zu einer Fragmentierung der Auslagerungsdatei kommen, was aber nicht besonders schlimm ist, weil das System dann sowieso schleicht.

Spätestens nach dem nächsten Neustart hat die Auslagerungsdatei wieder die vorherige Größe und ist genauso unfragmentiert wie vorher.

Wenn die Vergrößerung der Auslagerungsdatei nicht die Ausnahme, sondern die Regel ist, dann hast du einfach zu wenig RAM. Da hilft alles nichts, das System schneckt.

... probier es doch aus, einmal die HDD auf eine Fragmentation von ca. 50 % zu bringen, aber noch gut ca. 1 GB an Platz und kopier dann mal eine grosse Datei (lass sie mal ca. 500 MB gross sein) darauf und guck zu wie die Lampe leuchtet, lösch die Datei, ...Wenn auf einer 80 GB Festplatte nur noch 1 GB frei ist, wird alles und dauernd fragmentiert. Da hilft überhaupt gar nichts. Eine Platte, die zu mehr als 85% gefüllt ist, macht den Rechner schnarchlangsam, nicht eine dynamische Auslagerungsdatei.

Nachdem was du schreibst, macht Cache keinen Sinn, warum haben sie den trotzdem Cache drauf ? Laufruhe ? wie kannst du Laufruhe erzeugen ? Performencesteigerung ? erreichst du nur, indem der nächste Sektor schon gesucht wird, während der aktuelle Sektor gerade auf Reisen geht (bei Fat 32 kann ein Sektor 32 KB gross sein und diese werden schon zusammen gesucht, bis die 2 MB Cache voll sind, imho), Wovon redest du? Lesen oder Schreiben? Leg dich doch mal bitte fest und behandle beide Fälle unterschiedlich. Beim Schreiben hält Windows die Daten so lange im Cache (im RAM!), bis das System Zeit hat, die Daten zu schreiben. Das dauert relativ gesehen so lange, dass die Platte zwischendurch nichts anderes machen kann. Viele Dateien sind ohnehin viel größer, als der FP-Cache und geschrieben wird (wenn möglich) sequentiell, da genügt ein wenig Cache, damit der Bus zwischen den Blöcken wieder etwas früher freigegeben werden kann.

Beim sequentiellen Lesen spielt auch ein Read-Ahead-Cache keine Rolle und der Festplatten-Cache ist auch bei 8 MB meistens zu klein, um wirklich ganze Dateien vorzuladen.

Der Festplattencache ist nicht überflüssig (habe ich nie behauptet), aber das Caching durch das Betriebssystem ist viel effektiver und eine Vergrößerung von 2 auf 8MB bringt fast nichts.

über den PCI-Bus brauchen, um die nächste Paketsammlung zusammen zu stellen, ohne Cache rattern die HDD's wie sau, woran mag das nur liegen ? ;) ... Die Übertragung über den PCI-Bus (wenn der IDE-Controller bei einem alten Board überhaupt noch über PCI angebunden ist) geht um Größenordnungen schneller, als das Lesen von der Platte. Die hat niemals Zeit übrig.

[Leonidas]

Wenn jetzt noch die Mär kommt, das Min und Max gleich sein müssen, um die ständigen Größenveränderungen der Auslagerungsdatei zu verhindern, spring ich ausm Fenster ...

[Lokadamus]

mmm...

Zu deinem
1.) blablabla ... demnach scheint alles egal zu sein, Sektoren hier, Sektoren da ... jaja ... ja, ich weis, was sequentiel ist, ich hoffe, du auch (siehe Pic) ...

2.) Hast du dir überhaupt mit einem guten Programm mal angeguckt, wo welche Datei landet ? ... viel Spass ... (von wegen die Auslagerungsdatei würde zusammen hängend sein, die ist unter Fat 32 dermassen zerpflückt, da ist alles mögliche dazwischen, nur weil der Kram dynamisch ist und ich glaube kaum, das NTFS daran was ändert) ...

Dabei kann es dann zu einer Fragmentierung der Auslagerungsdatei kommen, was aber nicht besonders schlimm ist, weil das System dann sowieso schleicht.

Na spitze, wovon reden wir den die ganze Zeit ???

Spätestens nach dem nächsten Neustart hat die Auslagerungsdatei wieder die vorherige Größe und ist genauso unfragmentiert wie vorher.
??? bei dynamischen wechselt die Grösse permanent, bei einer festen aber NICHT (zumindest unter Fat nicht und bei NTFS wird man das wohl auch fest einstellen können) ...

Wenn die Vergrößerung der Auslagerungsdatei nicht die Ausnahme, sondern die Regel ist, dann hast du einfach zu wenig RAM. Da hilft alles nichts, das System schneckt.
Juten Morgen !!! ein echter Schlaubi Schlumpf ist unter uns ... ja, und je mehr die HDD framgmentiert ist, desto schlimmer wird es !
Wenn auf einer 80 GB Festplatte nur noch 1 GB frei ist, wird alles und dauernd fragmentiert. Da hilft überhaupt gar nichts. Eine Platte, die zu mehr als 85% gefüllt ist, macht den Rechner schnarchlangsam, nicht eine dynamische Auslagerungsdatei.
*schweigen und geniessen* ... siehe oben ...

Wovon redest du? Lesen oder Schreiben? Leg dich doch mal bitte fest und behandle beide Fälle unterschiedlich. Beim Schreiben hält Windows die Daten so lange im Cache (im RAM!), bis das System Zeit hat, die Daten zu schreiben. Das dauert relativ gesehen so lange, dass die Platte zwischendurch nichts anderes machen kann. Viele Dateien sind ohnehin viel größer, als der FP-Cache und geschrieben wird (wenn möglich) sequentiell, da genügt ein wenig Cache, damit der Bus zwischen den Blöcken wieder etwas früher freigegeben werden kann. Ich weiss nicht, was du dauernd mit dem Windows-Cache hast, ich rede von dem kleinen Cache, der bei der HDD integriert ist ...

Beim sequentiellen Lesen spielt auch ein Read-Ahead-Cache keine Rolle und der Festplatten-Cache ist auch bei 8 MB meistens zu klein, um wirklich ganze Dateien vorzuladen.
Aha, und du kannst alle Daten so schön sequentiell unter NTFS lesen ??? das will ich auch ... welches OS hast du ? Windows kann es nicht sein ...

[x-dragon]

Wie arbeitet Windows denn mit der Auslagerungsdatei, wird ein bestimmter Teil beim Start reserviert(und je nach Bedarf erweitert) und beim beenden wieder freigegeben oder wird diese komplett nach Bedarf reguliert, also von 0 bis Bedarf bzw Platz auf der Platte?

[..,-]

Mein lieber Lokadamus,

auch wenn du dich scheinbar berufen fühlst, persönlich werden zu müssen, werde ich versuchen, es dir letztmalig zu erklären. Deine Bereitschaft, dazuzulernen scheint zwar nicht sehr ausgeprägt zu sein, aber damit nicht noch andere von deinem unverstanden widergekäuten Unsinn verunsichert werden, mach ich mir nochmal die Mühe.

Original geschrieben von Lokadamus
(von wegen die Auslagerungsdatei würde zusammen hängend sein, die ist unter Fat 32 dermassen zerpflückt, da ist alles mögliche dazwischen, nur weil der Kram dynamisch ist und ich glaube kaum, das NTFS daran was ändert) ...
Falsch. Auch wenn der Scientology-Defragmentierer, den Microsoft mit Windows 2000/XP mitliefert, nicht in der Lage ist, die Auslagerungsdatei zu defragmentieren: Andere Programme können das. Wie z.B. das dir sicher bekannte, kostenlose PageDefrag.

Manu benutzt offensichtlich eine dieser beiden Windows-Versionen. Bei einer Einstellung

Anfangsgrösse (MB): 768
Maximale Grösse (MB): 1536

genügt ein einmaliger durchlauf von PageDefrag und eine 768 MB große, nicht fragmentierte Auslagerungsdatei steht zur Verfügung. Diese wird zu keinem Zeitpunkt kleiner als 768 MB, kann also folglich nicht fragmentieren, solange Windows nicht mehr als 768 MB + physischer Speicher benötigt.

Nur falls diese Seichermenge einmal nicht ausreichen sollte, wird die Auslagerungsdatei nachträglich auf maximal 1536 MB vergrößert. Sollte das auch nicht reichen, erscheint eben die obige Fehlermeldung (von der du sicher Kenntnis genommen hast). Bei dieser Vergrößerung kann der über 768 MB hinausgehende Teil der Auslagerungsdatei fragmentiert werden.

Und das ist völlig egal. Bei 1,5 GB ausgelagertem Speicher rödelt die Platte ohnehin wie blöd und von flüssigem Arbeiten kann keine Rede sein.

Sobald die Speichernutzung wieder zurückgeht, verkleinert Windows 2000/XP die Auslagerungsdatei wieder, aber auf nicht weniger als 768 MB (spätestens nach einem Neustart). Diese 768 MB Auslagerungsdatei ist danach genauso unfragmentiert oder fragmentiert, wie sie vorher war. Punkt und aus.

??? bei dynamischen wechselt die Grösse permanent, bei einer festen aber NICHT (zumindest unter Fat nicht und bei NTFS wird man das wohl auch fest einstellen können) ...Du hast vermutlich vor nichts Angst, außer, dass dir der Himmel auf den Kopf fallen könnte, was? Oben steht, wie es tatsächlich ist.

Ich weiss nicht, was du dauernd mit dem Windows-Cache hast, ich rede von dem kleinen Cache, der bei der HDD integriert ist ...Das du vom Windows-Cache nicht viel weißt, dürfte wohl jeder gemerkt haben. Mit Fragmentierung hat der Festplattencache nichts zu tun. Ein 2 MB Plattencache (Lese- und Schreibcache zusammen) ist völlig ausreichend, 8 MB machen keinen merklcihen Unterschied. Das alles hatte ich zwar oben schon genauso gesagt, aber du wolltest es ja scheinbar nochmal hören.

Aha, und du kannst alle Daten so schön sequentiell unter NTFS lesen ??? das will ich auch ... welches OS hast du ? Windows kann es nicht sein ... Ich weiß zwar nicht, an welcher Stelle du das jetzt wieder missverstanden hast, aber eine nicht fragmentierte Auslagerungsdatei könnte natürlich, wenn es nötig wäre, sequentiell gelesen werden.

Vielleicht leihst du dir von deinem Vater mal seine c't-Sammlung und suchst mal nach dem Artikel, in dem folgendes Experiment gemacht wurde:

Schneller Rechner, langsame Platte mit Betriebssystem, schnelle Platte nur für die Auslagerungsdatei oder alternativ mit auf der Systemplatte.

Wie groß war der Leistungsunterschied in allen Anwendungsbenchmarks: Weniger als 4%, wenn ich mich recht erinnere.

[Lokadamus]

mmm...

Falsch. Auch wenn der Scientology-Defragmentierer, den Microsoft mit Windows 2000/XP mitliefert, nicht in der Lage ist, die Auslagerungsdatei zu defragmentieren: Andere Programme können das. Wie z.B. das dir sicher bekannte, kostenlose PageDefrag. Sagst du damit nicht selber, das Windows von sich selber heraus NICHT in der Lage ist, die Datei zusammenhängend anzulegen ??? ... und das wohl auch unter NTFS ... das andere Programme das können habe ich oben schon geschrieben (Norton == Norton Utilities == Speedisk, ich dachte, das Programm wäre bekannt, gehört aber nicht zu den "stabilsten", weil einige killen damit ihre HDD ...

Du hast vermutlich vor nichts Angst, außer, dass dir der Himmel auf den Kopf fallen könnte, was? Oben steht, wie es tatsächlich ist.Äh, hallo ? Eine feste Datei hat eine feste Grösse, min == max == min, die defragmentierst du einmal und nie wieder ... wenn du nur eine min. nimmst, bekommst du wieder die Probs, wenn du konstant mehr brauchst ...

Das du vom Windows-Cache nicht viel weißt, dürfte wohl jeder gemerkt haben. Mit Fragmentierung hat der Festplattencache nichts zu tun.Darum wollte ich wissen, warum du das überhaupt mit reinbringst, davon war NIE die Rede. Du warst derjenige, der es reingebracht hat ...
Ein 2 MB Plattencache (Lese- und Schreibcache zusammen) ist völlig ausreichend, 8 MB machen keinen merklcihen Unterschied. Das alles hatte ich zwar oben schon genauso gesagt, aber du wolltest es ja scheinbar nochmal hören.Äh, hallo ? mofa hat geschrieben, das der Cache sich vervierfacht und der rest sich vermehrfacht, ich wollte nur sinngemäß rüberbringen, das die paar MB brauchbar sind, sprich, ohne dürfte die HDD ziemlich laut rattern, allerdings ist die Grösse in diesem Sinne irrelevant, weil für den alltäglchen Gebrauch gross genug (8 MB dürfte für Multiuser interessant sein oder kleine private Fileserver mit hohem Traffic) ...

Vielleicht leihst du dir von deinem Vater mal seine c't-Sammlung und suchst mal nach dem Artikel, in dem folgendes Experiment gemacht wurde:
Schneller Rechner, langsame Platte mit Betriebssystem, schnelle Platte nur für die Auslagerungsdatei oder alternativ mit auf der Systemplatte.
Wie groß war der Leistungsunterschied in allen Anwendungsbenchmarks: Weniger als 4%, wenn ich mich recht erinnere.Waren die HDD's voll oder leer (hohe Fragmentation oder keine ?) ???
Achja, nur nochmal nachgefragt, sequenziell war doch linear lesen oder ? das würde bedeuten, in einem Rutsch lesen, sprich, keine Jumps der Köpfe (bei Windows von sich heraus nicht möglich :P) ...

[..,-]

Original geschrieben von Lokadamus
Sagst du damit nicht selber, das Windows von sich selber heraus NICHT in der Lage ist, die Datei zusammenhängend anzulegen ??? ... und das wohl auch unter NTFS ...Ich würde ehrlich gesagt meinen Arsch nicht darauf verwetten, wie und wo die Auslagerungsdatei nach einer frischen Installatin liegt. Aber wenn ich den Eindruck erweckt habe, jegliche Defragmentierung der Auslagerungsdatei wäre von Haus aus nicht möglich, oder mit Windows-Boardmitteln zu beheben, dann habe ich mich wohl unklar ausgedrückt. Ganz klar: Eine einmal fragmentierte Auslagerungsdatei und Registry-Dateien fasst der mitgelieferte Defragmentierer nicht an.

Äh, hallo ? Eine feste Datei hat eine feste Grösse, min == max == min, die defragmentierst du einmal und nie wieder ... wenn du nur eine min. nimmst, bekommst du wieder die Probs, wenn du konstant mehr brauchst ...Völlig richtig, dem kann ich nur zustimmen. Aaaaaber ... es ist 1. entweder den Verlust an Festplattenkapazität einfach nicht wert (wenn man von Anfang an eine Mörderauslagerungsdatei von 2 oder 3 GB anlegt) oder du kannst 2. eben das Problem von Manu bekommen, dass eine Anwendung einfach abbricht (was doch wesentlich unerfreulicher ist, als wenn der Rechner verlangsamt weitermacht).

Windows 2000 stellt als Standard ungefähr 2/3 des physischen RAMs für die Mindestgröße ein. Das ist eigentlich eine sehr vernünftige Größe. Wenn man tatsächlich konstant mehr als das brauchst, dann hast du ohnehin ein Problem. Die paar Prozent Geschwindigkeitszuwachs, die man durch eine garantiert nie fragmentierte Auslagerungsdatei vielleicht raushohlen könnte, stehen in keinem Verhälstnis zu dem, den man mit mehr RAM erzielen würde. Und zusätzlich wird die Platte schneller voll, so dass für alle andern Dateien die Wahrscheinlichkeit steigt, dass sie nur noch fragmentiert abgelegt werden können. Bei einer einzelnen 80 GB Partition sicher kein echtes Problem, aber bei den Mini-Partitionen, die sich manche da draufknallen, schon.

Vom Datenträger-Cache des Betriebssystems hatte ich nur angefangen, weil dieser sehr viel mehr dazu beiträgt, dass die Platte weniger Kopfbewegungen durchführen muss, denn ...

...ich wollte nur sinngemäß rüberbringen, das die paar MB brauchbar sind, sprich, ohne dürfte die HDD ziemlich laut rattern, allerdings ist die Grösse in diesem Sinne irrelevant, weil für den alltäglchen Gebrauch gross genug ...Der Festplattencache entlastet die Platte beim Schreiben nur wenig. Die Platte schreibt sowieso viel langsamer, als Daten angeliefert werden können und selbst ein 8 MB Cache ist in nullkommanix voll. Ganz anders der Datenträger-Cache. Der kann viele MB groß sein und Windows versucht die Schreibvorgänge so zu verzögern, dass sie erst dann ausgeführt werden, wenn das System gerade durch nichts anders ausgelastet ist. Ein weiterer positiver Effekt ist, das manche Schreibvorgänge erst gar nicht physich durchgeführt werden müssen, weil die Daten in der Zwischenzeit schon wieder verändert oder sogar gelöscht worden sind (temporäre Dateien!), während sie sich noch im Software-Cache befinden. Das hilft anständig, Plattenzugriffe zu vermindern. Ich weiß nicht, ob es von MS dazu auch Zahlenangaben gibt, aber unter UNIXen werden Daten bis zu 30 Sekunden (!) verzögert geschrieben.

Waren die HDD's voll oder leer (hohe Fragmentation oder keine ?) ???Müsste ich nachschauen, wenn ich den Artikel noch finde. Da auf der schnellen Platte nichts außer der Auslagerungsdatei war, war zumindest die auf jeden fall völlig unfragmentiert. Und es ging ja in erster Linie um den Einfluss einer fragmentierten Auslagerungsdatei.

Achja, nur nochmal nachgefragt, sequenziell war doch linear lesen oder ? das würde bedeuten, in einem Rutsch lesen, sprich, keine Jumps der Köpfe (bei Windows von sich heraus nicht möglich :P) ... Ja, aber warum sollte das bei Windows grundsätzlich erstmal nicht möglich sein? Oder meinst du jetzt wieder nur die Auslagerungsdatei? Wie gesagt, dass die wirklich komplett in einem Rutsch gelesen werden müsste, dürfte sehr, sehr selten vorkommen.

[Lokadamus]

mmm...

@Leonidas
Schon gesprungen ? ... oder hast du eine neues Verfahren für NTFS entwickelt, um die Swapdatei und alle anderne Dateien trotz Grössenveränderung nicht fragmentieren zu lassen ??? ;)

Ich würde ehrlich gesagt meinen Arsch nicht darauf verwetten, wie und wo die Auslagerungsdatei nach einer frischen Installatin liegt. Aber wenn ich den Eindruck erweckt habe, jegliche Defragmentierung der Auslagerungsdatei wäre von Haus aus nicht möglich, oder mit Windows-Boardmitteln zu beheben, dann habe ich mich wohl unklar ausgedrückt. Ganz klar: Eine einmal fragmentierte Auslagerungsdatei und Registry-Dateien fasst der mitgelieferte Defragmentierer nicht an.Sie liegt knapp unter der Windowsinstallation, fängt aber dadurch, das sie nicht fest ist und bei Win 9x zu klein sehr schnell an zu fragmentieren, "stört" dadurch auch gleich die anderen Programme die mit drauf sollen und die HDD ist erstmal schön durcheinander, bei Win 2k "scheint" es wenigstens eine Mindesgrösse anzulegen, nur je nach eigenen Interessen wohl meistens zu klein (wo dort die Auslagerungsdatei liegt, weiss ich nicht, weil Defrag nicht anzeigt, wo welche Datei liegt :(, glaube aber kaum, das sie am Anfang oder am Ende liegt) ...

Ganz klar: Eine einmal fragmentierte Auslagerungsdatei und Registry-Dateien fasst der mitgelieferte Defragmentierer nicht an.Bei Win 98 macht er es aufjedenfall, weil das dumme Teil denkt, es wüsste besser, wie eine "optimierte" HDD auszusehen hat, bei Win 2k hab ich es bisher nicht getestet, denke aber, das es da zu den gleichen Probs kommen wird (jeder Defrager hat eine andere Grundlage, die Sachen anzuordnen).

Völlig richtig, dem kann ich nur zustimmen. Aaaaaber ... es ist 1. entweder den Verlust an Festplattenkapazität einfach nicht wert (wenn man von Anfang an eine Mörderauslagerungsdatei von 2 oder 3 GB anlegt) oder du kannst 2. eben das Problem von Manu bekommen, dass eine Anwendung einfach abbricht (was doch wesentlich unerfreulicher ist, als wenn der Rechner verlangsamt weitermacht).Wie schon vorher mal geschrieben, je nach eigenen Interessen, in den meisten Fällen reicht eine Grösse von dicke 256 MB aus, spielt man gerne gewissen Ego-Shooter oder andere 3D-Killeraplikations oder hantiert viel mit Grafik, kann man gerne auf 512 bzw. 1 GB hochgehen, erst recht, wenn man eine HDD von ca. 80 GB oder so hat (wieviel Platz nimmt nochmal die Sicherung von MS in Anspruch ? ;)) oder aber eben nicht fest setzen ... echter Ram ist sowieso besser, da stimme ich dir sofort zu.

Ganz anders der Datenträger-Cache. Der kann viele MB groß sein und Windows versucht die Schreibvorgänge so zu verzögern, dass sie erst dann ausgeführt werden, wenn das System gerade durch nichts anders ausgelastet ist. Ach, das dumme Teil ist also schuld daran, das auf meiner alten Gurke nix richtig klappt, wenn es um grosse Dateien geht (selbst ein Upload klappt grundsäztlich nicht richtig, bei ca. 100 MB bricht es just for fun immer ab, egal wie gross Swap ist, obwohl es damit nix zu tun haben sollte ???) ...

Müsste ich nachschauen, wenn ich den Artikel noch finde. Da auf der schnellen Platte nichts außer der Auslagerungsdatei war, war zumindest die auf jeden fall völlig unfragmentiert. Und es ging ja in erster Linie um den Einfluss einer fragmentierten Auslagerungsdatei.Brauchst nicht nachschauen, so wichtig ist es nicht, wobei da wieder die Frage ist, wie stark sie die Auslagerungsdatei ausgelastet haben ... hab damals mit MS-DOS schon meine Erfahrungen mit Fragmentationen (schreibt man das so?) gemacht, ging um ein altes PC-Spiel, was ca. 1200 Dateien hatte, alleine das Verzeichnis anzeigen zu lassen hat ca. 3-5 Sekunden gedauert, nachdem einmal Speeddisk rübergelaufen ist, war es nur noch 1 Sekunde. Bei Windows soll man sowas erst ab 5.000 oder 10.000 Dateien in einem Ordner merken (bei Speeddisk kann man schön angeben, ob die Dateien nach Ordner, Namen sortiert werden sollen, sehr gute Funktion) ... ich hoffe, du hast auch einen alten PC, dann kannst du selber sowas testen ...

Ja, aber warum sollte das bei Windows grundsätzlich erstmal nicht möglich sein? Oder meinst du jetzt wieder nur die Auslagerungsdatei? Wie gesagt, dass die wirklich komplett in einem Rutsch gelesen werden müsste, dürfte sehr, sehr selten vorkommen.
Alle Dateien meine ich.
MS schmeisst bisher alle Dateien gerade dorthin, wo Platz ist (sprich, wo ein Sektor frei ist, nicht wo Platz für die gesamte Datei ist, ansonsten bräuchte man kein Defrag). Wie willst du da die Dateien so in einem Rutsch lesen, wenn der eine Teil vorne ist und der andere hinten ?

[..,-]

Original geschrieben von Lokadamus
... bei Win 2k "scheint" es wenigstens eine Mindesgrösse anzulegen, nur je nach eigenen Interessen wohl meistens zu klein (wo dort die Auslagerungsdatei liegt, weiss ich nicht, weil Defrag nicht anzeigt, wo welche Datei liegt :(, glaube aber kaum, das sie am Anfang oder am Ende liegt) ...

... bei Win 2k hab ich es bisher nicht getestet, denke aber, das es da zu den gleichen Probs kommen wird (jeder Defrager hat eine andere Grundlage, die Sachen anzuordnen).
Windows 9x würde ich eigentlich gerne außen vor lassen. Zum einen verwendet es der Thread-Starter nicht, zum anderen ist 2000/XP in diesem Bereich nunmal deutlich besser.

Wo die Auslagerungsdatei unter W2K liegt, zeigt zumindest die freie Version von OO Defrag prima an. Bildchen siehe unten. Und da das eine von zwei Partitionen ist, liegt sie ziemlich genau da, wo ich sie haben will. :)

Wie schon vorher mal geschrieben, je nach eigenen Interessen, in den meisten Fällen reicht eine Grösse von dicke 256 MB aus,
...
oder aber eben nicht fest setzen ... echter Ram ist sowieso besser, da stimme ich dir sofort zu.
Wenn dir 256 MB sowieso (fast immer) reichen, dann gibt es doch erst recht keinen Grund, die Obergrenze nicht erheblich höher zu setzen. Wie gesagt, Fragmentierung tritt dann höchstens dann auf, wenn es mal doch nicht reicht und verschwindet von alleien wieder, sobald die Auslagerungsdatei wieder schrumpft.

MS schmeisst bisher alle Dateien gerade dorthin, wo Platz ist (sprich, wo ein Sektor frei ist, nicht wo Platz für die gesamte Datei ist, ansonsten bräuchte man kein Defrag). Oh nein, das ist so nicht richtig! Schon Windows 98 versucht zunächst mal ausreichend freien Platz auf der Platte zu finden. Fragmentierung von Dateien tritt eigentlich nur dann auf, wenn sie nach dem ersten Speichern mehr wachsen, als dahinter noch Platz zur Verfügung steht. Und um dem entgegenzuwirken verfolgt es noch eine weitere Strategie: Neue Dateien werden immer mit einem gewissen "Mindestabstand" zu vorhergehenden Dateien angelegt. Standardmäßig sind das bei W98 500 kiB. Das kann man aber z.B. per X-Setup (oder mit manuellem Registry-Gepopel) problemlos hochsetzen.

Man erreicht also weniger Dateifragmentierung, indem man eine höhere Fragmentierung des freien Speicherplatzes zulässt. Viele Defragmentierer unterscheiden in der Anzeige nur sehr unzureichend zwischen fragmentiertem freiem Speicherplatz (für sich genommen praktisch völlig harmlos) und fragmentierten Datein.

[Lokadamus]

mmm...

??? aha, also das Rote da unten, das ist eine grosse Datei, die ich von einem anderen Rechner rübergezogen habe, sprich sie wird definitiv nicht wachsen, weil ich sie nicht brauche, sondern nur gesichert habe ... die weissen Felder dazwischen sind also Beschleuningungsfelder oder hab ich dich da falsch verstanden. Das ist übrigens die HDD von gestern, ich hab das normale Defrag schon drüberlaufen lassen ... über den Rest der HDD will ich lieber nicht reden, weil wenn das deine Vorstellung von einer "optimierten" HDD ist, dann kann dir niemand mehr helfen ... und JA, es interessiert mich gerade NICHT, wie oo_Defrag, Speedisk und all die anderen es machen würden ...

[..,-]

Wahrscheinlich weißt du es ja schon, aber der Vollständigkeit doch nochmal:

Wenn man in OO Defrag eines dieser Block-Kästchen mit der linken Maustaste anklickt, kommt ein Fenster hoch, in dem man genau sehen kann, welche Dateien oder Dateiteile sich in diesem Block befinden und in welchem Status. Und in den Laufwerksinformationen gibt es ja nochmal die komplette Liste der fragmentierten Dateien mit der Angabe, in wie viele Fragmente die Datei aufgeteilt ist.

Ob Windows 2000 immer noch die gleiche Taktik beim Anlegen neuer Datein verfolgt, weiß ich nicht. Darüber habe ich noch nichts Aussagekräftiges gefunden (allerdings auch nicht zu intensiv nach gesucht). Aber man muss sich schon klarmachen, dass eine normale SPACE-Defragmentierung eventuelle Lücken zwischen den Dateien natürlich wieder schließt. Ansonsen habe ich deinen letzen Satz nicht verstanden. Wieso sollte es möglich sein, genau eine "richtige" Defragmentierungsstrategie zu entwickeln? Kann gar nicht sein.

[Lokadamus]

mmm...

Wenn man in OO Defrag eines dieser Block-Kästchen mit der linken Maustaste anklickt, kommt ein Fenster hoch, in dem man genau sehen kann, welche Dateien oder Dateiteile sich in diesem Block befinden und in welchem Status. Und in den Laufwerksinformationen gibt es ja nochmal die komplette Liste der fragmentierten Dateien mit der Angabe, in wie viele Fragmente die Datei aufgeteilt ist.Daher weiss ich doch erst, das die grossen roten Dinger am Ende zusammen gehören und ein gutes Defragprogramm packt diese meines Wissen nach zusammen ... und so, wie jeder von NTFS redet, müsste es von sich heraus sowas schon machen, was aber nicht zu sein scheint (vielleicht bin ich auch die Ausnahme, scheint ja so zu sein, ansonsten wäre das ganze Gespräch unnötig gewesen) ...

Ob Windows 2000 immer noch die gleiche Taktik beim Anlegen neuer Datein verfolgt, weiß ich nicht. Darüber habe ich noch nichts Aussagekräftiges gefunden (allerdings auch nicht zu intensiv nach gesucht). Aber man muss sich schon klarmachen, dass eine normale SPACE-Defragmentierung eventuelle Lücken zwischen den Dateien natürlich wieder schließt. Ansonsen habe ich deinen letzen Satz nicht verstanden. Wieso sollte es möglich sein, genau eine "richtige" Defragmentierungsstrategie zu entwickeln? Kann gar nicht sein.Naja, spiel mal mit einer HDD einen Monat lang rum, ohne ein Defragprogramm zu nehmen und guck dir dann mal an, wo welche Dateien gelandet sind, sieht alles ein bischen komisch aus, ihmo alles planlos ... und jedes Programm ausser Defrag von MS bietet eine ordentliche Sammlung von Funtkionen an, wie die Dateien angelegt werden sollen ... können leider nicht parallel zu Windows laufen, weil das doch zu sehr auf die Resourcen geht ...

[..,-]

Original geschrieben von Lokadamus
Daher weiss ich doch erst, das die grossen roten Dinger am Ende zusammen gehören und ein gutes Defragprogramm packt diese meines Wissen nach zusammen ...Die ganzen roten Dinger am Ende liegen bereits zusammen, ist doch sehr gut zu sehen, oder? Das ist nicht das Problem, die Frage ist nur, wo außerdem noch Teile liegen. Selbst wenn so eine Riesendatei nur in zwei Fragmente aufgeteilt ist (was absolut piepegal ist), wird sie trotzdem vollständig rot dargestellt. Das impliziert bei vielen Benutzern dann erfolgreich, dass da "alles durcheinander" wäre. Psychologisch sehr wirksam.

... und so, wie jeder von NTFS redet, müsste es von sich heraus sowas schon machen, was aber nicht zu sein scheint ...Jeder? Nöö, ich habe an keiner Stelle etwas derartiges behauptet.

Naja, spiel mal mit einer HDD einen Monat lang rum, ohne ein Defragprogramm zu nehmen und guck dir dann mal an, wo welche Dateien gelandet sind, sieht alles ein bischen komisch aus, ihmo alles planlos ... Genau, beim Angucken kriegt man den Rot-Schock, siehe oben. Wie groß der Einfluss auf die Leistung ist, darüber sagt die Orgie in Rot nichts aus.

...und jedes Programm ausser Defrag von MS bietet eine ordentliche Sammlung von Funtkionen an, wie die Dateien angelegt werden sollen ...Was einem die Möglichkeit bietet, monatelang auszutesten, welche Option denn wohl für Doom3 die beste sein könnte :lol: .

Im Ernst: Habe ich irgendwo gesagt, man bräuchte oder solle seine Festplatte nicht zu defragmentieren? Nein, habe ich nicht. Aber was ich sage ist, dass 1. der Einfluss der Fragmentierung total überschätzt wird und dass 2. die mögliche Fragmentierung der Auslagerungsdatei überhaupt kein Grund ist, die maximale Größe auf den selben Wert zu stellen, wie die minimale Größe.

Und Manu scheint ja auch ganz begeistert von meinen Ausführungen zu sein, so intensiv, wie er sich an der Diskussion beteiligt ... ;)

[Lokadamus]

mmm...

1.) Du meinstest irgendwo, NTFS sei besser in der Verwaltung als Fat 32, ich seh da keinen Unterschied ...

2.) Text nicht richtig gelesen ? die roten Dinger unten gehören zusammen, sind gesplittet, weil Defrag am Ende von dem einen Ding eine Datei mit dem Namen C:\. liegt (was immer das ist), genauso hab ich zwischen drinne des öfteren noch solche Sachen wie 10x eine Datei, 1x Fragment einer anderen Datei 10x wieder die Datei davor ... und nein, beides sind normale Dateien. Soll das die tolle Anordnung sein ? Sehe ich keinen Nutzen drinne, würde es durchwegs abwechselnd sein, würde es Sinn machen, aber so ...

3.) Oja, Defrag alleine hat ja auch so viele Optionen :schlag: ... wenn, dann überlegt man vorher, wie man es anordnen lässt und das macht man schön brav am Anfang beim 1. Starten eines brauchbaren Defragproggies ...

Zu deinem 1.würde ich eher sagen, es kommt darauf an, WANN man es macht und dann frag mal die Nachbarschaft, ob sie sowas überhaupt kennen ? wahrscheinlich nicht und dann haben sie eine Fragmentation von 70 % und dort kann man was merken (ausser du hast SCSI oder nen High-End-PC, dort siehst du nur die HDD immer rödeln, aber es läuft alles trotzdem flüssig (woran das nur wieder liegt ??? )) ... und wehe du sagst, gleich, das DU regelmässig defrag machst (dann ist es kein Wunder, das du keinen Unterschied merkst) ...

Zu deinem 2. Ok, da hat MS wohl gelernt, das Teil ab Win 2k zusammenhängend anzulegen ... achja, wenn du sagst, das es bei Fat32 auch egal ist, dann kannst du gerne mal vorbeikommen und mir zeigen, wie du Video's flüssig abspielen lassen willst auf meiner Gurke, wenn die HDD schön durcheinander ist (komischerweise läuft es dann nicht mehr flüssig, Geister, böse Dämonen oder woran liegt das ? nach nem Defrag geht es ohne Probs) ...

[x-dragon]

Original geschrieben von Lokadamus
mmm...

1.) Du meinstest irgendwo, NTFS sei besser in der Verwaltung als Fat 32, ich seh da keinen Unterschied ...
... Grundsätzlich stimmt das wohl auch, wobei ich aber noch nix konkreteres darüber gelesen habe, das NTFS Daten möglichst "Intelligent" speichert, wobei FAT grundsätzlich alle Daten nur stumpf hintereinander schreibt.

[Lokadamus]

mmm...

Weder der eine noch der andere machen das wirklich intelligent, von NTFS hab ich auch gehört, es sei intelligent und würde automatisch die Dateien so anlegen, das man Defrag nicht mehr brauchen würde ... so ist es aber leider nicht (kannst mit dem oo_defrag nachgucken, der zeigt die einzelnen Sektoren an und was wo abgelegt wurde) ... und wenn den erstmal die Daten kreuz und quer liegen, was bei den meisten (=normalen) Usern wohl der Fall ist, hängt der IE auch gerne mal dabei, wenn er einige Verzeichnisse anzeigen soll, da er erstmal fröhlich die Dateiliste zum Anzeigen sortiert, willst du kopieren, springt der Kopf auch gerne durch die Gegend usw. usf. (da alles innerhalb des "normalen-gewohnten" Rahmen bleibt, merkt man erst etwas, wenn die HDD schön durcheinander war und an es danach defragmentiert (50% Fragmentation oder noch schlechter machen da richtig Laune, nur wer von uns lässt seine HDD freiwillig soweit runterkommen ???), genauso ist es prima, wenn Leute ihre Temporäry Internet Files nicht löschen und dort 200 MB drinne haben ...

[x-dragon]

Hier auf Seite 16, ist eine interessante Beschreibung wie NTFS Daten speichert:
http://home.fhtw-berlin.de/~s0503881/NTFS_1_2.pdf

[Lokadamus]

mmm...

??? ist es nicht das, was ich die ganze Zeit sage ??? Die Dateien werden leider nicht schön zusammenhängend geschrieben, dadurch Fragmentation, der Lesekopf muss mehr rödeln usw. usf.; mehr Jumps der Köpfe = der Lesezyklus dauert länger ... viele User nutzen Programme wie Defrag nicht, dann merkt man es relativ gut (abhängig von der restlichen Hardware), nimmt man ein gutes Programm, kann man sogar anordnen, ob die Dateien nach Ordner und alphabetisch angelegt werden sollen (zumindest bei Fat 32, danach gehts schön schnell, weil alles eingelesen werden kann, wie ein stinknormales Inhaltsverzeichnis) ...

[..,-]

Original geschrieben von Lokadamus
1.) Du meinstest irgendwo, NTFS sei besser in der Verwaltung als Fat 32, ich seh da keinen Unterschied ...Kann mich nicht daran erinnern. Wo bitte?

2.) Text nicht richtig gelesen ? die roten Dinger unten gehören zusammen, sind gesplittet, weil Defrag am Ende von dem einen Ding eine Datei mit dem Namen C:\. liegt Diesen Satz muss man nicht verstehen können, oder?

3.) Oja, Defrag alleine hat ja auch so viele Optionen :schlag: Wer hat das wo behauptet?

... wenn, dann überlegt man vorher, wie man es anordnen lässt und das macht man schön brav am Anfang beim 1. Starten eines brauchbaren Defragproggies ...Ähh, ja und? Where's the beef? Es gibt nicht eine ideale Datei-Anordnung für alle Fälle. Ist das so schwer zu begreifen?

Zu deinem 1.würde ich eher sagen, es kommt darauf an, WANN man es macht und dann frag mal die Nachbarschaft, ob sie sowas überhaupt kennen ? wahrscheinlich nicht und dann haben sie eine Fragmentation von 70 % und dort kann man was merken Nachbarschaft? Welche Nachbarschaft. Was meinst du bitte und was soll mich kümmern, ob igednwer eine zu 70% fragementierte Platte hat? Und was heißt das übrigens, 70% Fra

(ausser du hast SCSI oder nen High-End-PC, dort siehst du nur die HDD immer rödeln, aber es läuft alles trotzdem flüssig (woran das nur wieder liegt ??? )) ... Du würfelst hier so viel Zeug durcheinander, dass ich langsam am Sinn unserer Konversation zweifle. SCSI- oder High-End? Der Einfluss oder Nicht-Einfluss von Fragmentierung ist bei SCSI genauso groß oder klein, wie bei IDE. Wenn ein SCSI-System "flüssiger" läuft, als ein IDE-System, dann sind die Gründe dafür andere (effektives Teilen der Bandbreite zwischen vielen Geräten, schnellere Platten).

und wehe du sagst, gleich, das DU regelmässig defrag machst (dann ist es kein Wunder, das du keinen Unterschied merkst) ...Wo habe ich behauptet, dass ich nicht regelmäßig defragmentieren würde oder dass du das nicht machen solltest? Bleib doch mal bitte bei den Fakten. Übrigens: Eimal im Monat ist auch regelmäßig ... und völlig ausreichend.


Wenn du mich schon zitieren möchtest, dann tu das bitte auch (es gibt das diesen Knopf "zitat") anstatt mir wirr Sachen in den Mund zulegen. Außerdem ging es in dieser Diskussion ausschließlich darum, ob man die obere Grenze für die Auslagerungsdatei genauso einstellen sollte wie die untere (Hinweis für neue Leser: Nein.). Auch wenn du dabei von Hölzken über Stöcksken immer wieder auf die scheinbar dauerfragmentierte Festplatte deiner "Gurke" zurückkommst: Das war nicht das Thema. Und einen vernünftiges Gegenargument habe ich leider immer noch nicht gehört. Vermutlich, weil es keins gibt.

[Lokadamus]

mmm...

Also, wenn ich mir den Text von oben nochmal durchlesen, bist du es, der sagt , Fragmentationen würden heute nicht mehr auftreten (heute = NTFS oder wie hast du es gemeint ???)...

Diesen Satz muss man nicht verstehen können, oder? Welchen Teil hast du davon nicht verstanden ? im Bild von mir sind in der unteren Hälfte 2 rote grosse Dinger, die zusammen gehören, welche aber durch eine Datei mit dem Namen C:\. getrennt werden ...

Ähh, ja und? Where's the beef? Es gibt nicht eine ideale Datei-Anordnung für alle Fälle. Ist das so schwer zu begreifen?Tschuldige, ich vergaß, du bist nicht in der Lage, andere Einstellungen zu nehmen, als die Standardeinstellungen ... die restlichen Kommentare dazu spar ich mir ...

Nachbarschaft? Welche Nachbarschaft. Was meinst du bitte und was soll mich kümmern, ob igednwer eine zu 70% fragementierte Platte hat? Und was heißt das übrigens, 70% FraIch vergaß, du und nur du, es gibt keine andere Menschen, wo kämen wir den dahin, wenn jemand anders geben würde ... vielleicht wüsste er dann, das er hin und wieder mal die Temporary Internet Files löschen sollte, Temp ebenefalls usw. usf. ... aber gut das es nur dich alleine gibt oder du der Standard der Menschheit bist zum Glück bin ich unnormal ...

Du würfelst hier so viel Zeug durcheinander, dass ich langsam am Sinn unserer Konversation zweifle. SCSI- oder High-End? Der Einfluss oder Nicht-Einfluss von Fragmentierung ist bei SCSI genauso groß oder klein, wie bei IDE. Wenn ein SCSI-System "flüssiger" läuft, als ein IDE-System, dann sind die Gründe dafür andere (effektives Teilen der Bandbreite zwischen vielen Geräten, schnellere Platten).
Du sagst doch selber, man merkt keinen Unterschied ... mag es vielleicht daran liegen, das du ein System mit schnellen HDD's hast und einer schnelle CPU ? vielleicht SCSI oder IDE mit 7200 rpm ? dort merkt man nicht so schnell nen Unterschied (bzw. erst, wenn man wirklich Datentraffic braucht, aber ob zwischendurch da nun 1 MB mehr pro Sekunde durch die Gegend geschaufelt wird oder nicht, fällt wirklich nicht mehr auf bei schnellen Platten) ...

Du würfelst hier so viel Zeug durcheinander, dass ich langsam am Sinn unserer Konversation zweifle. Ach, erst jetzt ? ich zweifle schon seit Ende Seite 1 daran ...

Wo habe ich behauptet, dass ich nicht regelmäßig defragmentieren würde oder dass du das nicht machen solltest? Bleib doch mal bitte bei den Fakten. Übrigens: Eimal im Monat ist auch regelmäßig ... und völlig ausreichend.Das war eine Unterstellung, kein Zitat ... und bist du dir sicher, das alle einmal pro Monat defrag (naja, Strafe muss sein, ansonsten würden die auch ein besseres Tool benutzen) laufen lassen ...

Außerdem ging es in dieser Diskussion ausschließlich darum, ob man die obere Grenze für die Auslagerungsdatei genauso einstellen sollte wie die untere (Hinweis für neue Leser: Nein.).Darum ging es auch, es ging eigentlich um das Prinzip, wie die Dateien angeordnet werden und das Swapfile ... gehört meiner Meinung nach beides zusammen, aber egal ...

Und einen vernünftiges Gegenargument habe ich leider immer noch nicht gehört. Vielleicht, weil du irgendwo vom Thema abgewichen bist ? mofa hat 2 GB als Swap empfohlen, ich hab weniger empfohlen, von dir kam irgendwie nix wirklich brauchbares, am besten wohl swap als 2 MB als Startwert und unendlich als Ende angeben, zumindest scheint das deine Argumentation zu werden ...

[..,-]

Einmal sag ich noch was dazu, danach darfst du diese Diskussion für dich haben.
Original geschrieben von Lokadamus
Also, wenn ich mir den Text von oben nochmal durchlesen, bist du es, der sagt , Fragmentationen würden heute nicht mehr auftreten (heute = NTFS oder wie hast du es gemeint ???)...Jedes Posting in diesem Forum hat eine eindeutige ID. Du findest die ID eines Beitrags recht einfach, wenn du z.B entweder Mozilla benutzt, oder für den Internet Explorer die "Microsoft Web Developer Accessories" installiert hast (Suche einfach bei Google danach, falls du nicht weißt, was das ist.) Dann setzt du den Mauszeiger umittelbar hinter den Namen desjenigen, der den Beitrag geschreiben hat, markierst den Namen von hinten nach vorne und bewegst den Mauszeiger noch ein bisschen weiter nach oben, bevor du die Maustaste wieder losläst. Dann klickst du mit der rechten Maustaste auf den markierten Text und wählst aus dem Kontextmenü "Auswahl-Quelltext ansehen" (Mozilla deutsch) oder "View partial source". In beiden Fällen öffnet sich ein neues Fenster, in dem du den HTML-Quelltext des gerade markierten Textes findest. Darin steht irgendwo etwas ähnliches wie:

<A name="post1086397"></A>

Das war jetzt zum Beispiel die ID deines letzten Postings.

Wenn du mir die ID eines von mir verfassten Postings nennen kannst (der direkte Link auf das Posting geht auch), in dem ich geschreiben habe, dass Fragmentierung heute nicht mehr auftritt, dann unterhalte ich mich gerne mit dir darüber und nehme diese Aussage zurück. Wenn du mir diese ID nicht nennen kannst, dann hör bitte endlich auf, mir irgendwelchen Scheiß in den Mund legen zu wollen, ja?

Welchen Teil hast du davon nicht verstanden ? im Bild von mir sind in der unteren Hälfte 2 rote grosse Dinger, die zusammen gehören, welche aber durch eine Datei mit dem Namen C:\. getrennt werden ...So verstehe ich den Satz sofort. In der alten Version fehlte, wohlwollend betrachtet, mindestens ein Wort, um Verständlichkeit herzustellen.

Und was ich dazu gesagt habe ist nicht, dass die Datei nicht fragmentiert wäre, sondern lediglich, dass auch die bereits unmittlelbar hintereinander liegenden Teile der Datei komplett rot angezeigt werden, selbst wenn sie nur in 2 Fragmente aufgeteilt ist. Das meiste, was rot angezeigt wird, ist also oft nur in wenige Fragmente unterteilt, insbesondere, wenn es sich um große Dateien handelt. Und wenn dein Rechner ein Video nicht mehr ruckelfrei abspielen kann, nur weil es in zwei oder 3 Fragmente aufgeteilt ist, dann stimmt da noch etwas ganz anderes nicht.

Ich vergaß, du und nur du, es gibt keine andere Menschen, wo kämen wir den dahin, wenn jemand anders geben würde ... vielleicht wüsste er dann, das er hin und wieder mal die Temporary Internet Files löschen sollte, Temp ebenefalls usw. usf. ... aber gut das es nur dich alleine gibt oder du der Standard der Menschheit bist zum Glück bin ich unnormal ...Aha, mit Nachbarschaft wolltest du mir also scheinbar sagen, dass viele Windows-Benutzer gar nicht wissen, dass es Fragmentierung gibt. Ja klar, na und? Was hat das mit dem Problem von Manu zu tun oder damit, wie groß der Performance-Einbruch ist? Wolltest du sagen: Viele Benutzer holen aus ihrem Rechner nicht die maximale Geschwindigkeit raus, weil sie nie defragmentieren und nie temporäre Dateien löschen? Sicher. Und trotzdem funktioniert es im Großen und ganzen...

Du sagst doch selber, man merkt keinen Unterschied ... mag es vielleicht daran liegen, das du ein System mit schnellen HDD's hast und einer schnelle CPU ? vielleicht SCSI oder IDE mit 7200 rpm ? dort merkt man nicht so schnell nen Unterschied (bzw. erst, wenn man wirklich Datentraffic braucht, aber ob zwischendurch da nun 1 MB mehr pro Sekunde durch die Gegend geschaufelt wird oder nicht, fällt wirklich nicht mehr auf bei schnellen Platten) ...Ein Athlon 2400+ gilt heute sicher als Einstiegsprozessor und ob eine (ich rede ausdrücklich von einer!) nur halbwegs aktuelle Festplatte nun per SCSI oder IDE angeschlossen ist oder mit 7200 oder 5400 Umdrehungen läuft, macht in Bezug auf die Auswirkungen von Dateifragmentierung überhaupt keinen Unterschied. Und daran ist nicht zuletzt der Festplattencache von Windows "schuld". So, da ist er wieder und er muss hier schon wieder erwähnt werde, weil das nunmal die Tasachen sind.

Das war eine Unterstellung, kein Zitat ... Mal wieder.

...und bist du dir sicher, das alle einmal pro Monat defrag (naja, Strafe muss sein, ansonsten würden die auch ein besseres Tool benutzen) laufen lassen ...Und da ist die nächste Unterstellung. Habe ich gesagt, alle würden das machen? Nein, ich habe gesagt, dass es genügt. Alle zwei Monate reicht übrigens auch. Wenn man seine Platten nicht zu mehr als 85% vollschaufelt, aber dann kann man de facto ja auch nicht mehr vernünftig defragmentieren.

Und nochwas, was dir gefallen wird: Mehr als OO Defrag Free und Page Defrag braucht kein Privatanwender. Alles andere bringt keinen auch nur im gerigsten im Vergleich zum Aufpreis zu rechtfertigenden Nutzen.

Darum ging es auch, es ging eigentlich um das Prinzip, wie die Dateien angeordnet werden und das Swapfile ... gehört meiner Meinung nach beides zusammen, aber egal ...Das Problem steht genau hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=83429#post1064538). Für jeden nachzulesen.

von dir kam irgendwie nix wirklich brauchbares, am besten wohl swap als 2 MB als Startwert und unendlich als Ende angeben, zumindest scheint das deine Argumentation zu werden ... Die günstigste minimale Größe der Auslagerungsdatei kann man nicht pauschal empfehlen. Wer so etwas sagt, redet Stuss. Aber man kann sie mit Windows-Boardmitteln selbst bestimmen. Das dazu erforderliche Werkzeug heißt Systemmonitor und ist z.B. unter Windows 2000 unter Start -> Einstellungen -> Systemsteuerung -> Verwaltung zu finden.

Zunächst stellt man für die Auslagerungsdatei einen zum Testen sinnvollen Grundwert ein, z.B. das Doppelte des physikalischen RAMs. Dann ruft man den Systemmonitor auf, klickt auf die Schaltfläche mit dem Plus-Zeichen, wählt als Datenobjekt die Auslagerungsdatei und fügt den Leistungsindikator "Belegung (%)" hinzu. Nun bekommt man eine schönen Graphen über die Belegung der Auslagerungsdatei angezeigt, einschließlich Minimum, Maximum und Durschnitt. Nun arbeitet (oder spielt) man einfach ein Weile das, was man auch sonst so macht. Hinterher kann man im Diagramm des Systemmonitors sehen, zu wieviel Prozent die Auslagerungsdatei im Schnitt und maximal ausgelastet war.

Entsprechend kann man die Minimalgröße danach verkleinern oder eben auch vergrößern.

Damit ist sichergestellt, dass die Auslagerungsdatei fast nie vergrößert werden muss, und das reicht. Die maximale Größe stellt man dann sinnvollerweise mindestens doppelt so groß ein, damit einem nicht das passiert, was das Problem von Manu war: Nämlich das ein Programm nicht mehr weiterarbeiten kann, weil Windows der virtuelle Speicher ausgeht.


So, von mir aus kannst du jetzt weiter Voodoo-Tuning-Tipps verbreiten oder es sein lassen, ich habe zu diesem Thema genug gesagt.

[PatTheMav]

Meine persönliche Erfahrung ist bisher, dass ich ab 256 MB unter Windows 98 immer mit 300-500 MB grossen Swapfiles problemlos klargekommen bin. Als ich 256 und 384 MB Ram hatte, war die Swapfile 300 MB gross, nun hab ich 512 MB Ram und ne ebenso grosse Swapfile. Allerdings habe ich über Stunden hinweg eine Swapfile-Nutzung von 10% - Conservative Swapfile-Usage machts möglich. Und trotz intensiver Programmier und Grafik-Arbeit bin ich noch nie in die Situation geraten, dass mein Ram aufgebraucht worden wäre. Bei einem OS, dass nur 60 MB schluckt net verwunderlich. Allerdings kann ich mir gut vorstellen, dass es mit Speicherverschwendern wie Windows XP etwas anders aussieht und der physisch verfügbare Ram vorher aufgebraucht ist und dort entsprechend grössere Swapfiles nötig werden.

Was Lokadamus als Fragmentierung der Swapfile anspricht ist wohl eine Tatsache, die mir auch aufgefallen ist : Aktiviert man in Windows eine "dynamische" Swapfile, d.h. weder Minimal noch Maximalgrösse angegeben, verteilen sich die Blöcke, die der Swapfile zugeordnet sind, auf der Platte wie sie Lust haben, mal hier ein 70-MB-Block, dahinter dann meinetwegen frisch installierte 60 MB eines Programms, dahinter wieder 40 MB Swapfile (die Zahlen sind jetzt reine Phantasiewerte) und nach dem neustart hast in der 70-MB Lücke nach paar Stunden ne 30 MB-Swapfile und immer wieder zwischendurch sind die restlichen 40 MB durch andere Daten aufgefüllt - Fragmentierung bei Fat32 par Excellence.

Bei 9x-Systemem bin ich bisher immer gut damit gefahren, nach der Windows Installation mitsamt Treibern den virtuellen Speicher zu deaktivieren, komplett zu defragmentieren und hinter diesem "ordentlichen" Block meine 500-MB Swapfile zu erstellen. Alles was danach an "Nutzdaten" kommt liegt hinter der Swapfile. Zwar hab ich exakt dieselben Werte für Minimum und Maximum, da aber meine Swap eigentlich nie sichtbar genutzt wurde, bin ich auf ner 10 GB-Partition zufrieden damit. 2 oder 3 GB grosse feste Swapfiles halte ich für Schwachsinn, da die nur unnötig Platz verbrauchen, wenn sollte man einen vernünftigen Minimalwert nutzen, der immer fest unverteilt (auch unfragmentiert genannt) auf der Platte sitzt und nur bei Bedarf vergrössert wird. Ob dann diese hundert MB, die für den aktuellen Betrieb gebraucht werden, verteilt gespeichert werden, ist nicht schlimm, da sie nach nem Reboot eh weg sind.

Einzig problematisch wird dies, wenn eh nicht viel Platz auf der Platte frei ist, und durch die Verteilung der anderen Abschnitte der vergrösserten Swapfile grössere Dateiblöcke ebenfalls fragmentiert abgelegt werden, was m.E. aber nur bei knappen freien Speicher passieren sollte.

Mich würd aber interessieren, wie man eine zu 70% fragmentierte Platte hinbekommt ?

Meine ist selbst nach Monaten nur 2-3% fragmentiert und wenn ich mal defragmentiere, sieht es so aus, als ob ein und dieselben Elemente gelesen und wieder geschrieben werden, aber in der Übersicht stellt sich jede meiner Partitionen als ein grosser Block dar. Keine Ahnung was ich richtig oder anders mache, aber ich bekomm sie einfach nicht fragmentiert, was aber auch daran liegen mag, wenn ich ..,- richtig verstanden hab, dass ich doch noch relativ viel freien Speicher habe. Als Nicht-Leecher bekommt man 100 GB Gesamtkapazität halt schwer voll.

[Lokadamus]

mmm...

Pat
70 % bekommst du relativ gut dadurch zusammen, wenn beim IE (oder anderen Browsern) die gecachten Daten nicht gelöscht werden oder die Daten keine Beschränkung haben (IE hat nix dagegen, wenn die temporary Internet Files auf 200 MB oder noch mehr anwachsen ;)) oder du Programme benutzt, die selber gerne noch cachen (Baldurs Gate benötigt selber noch extra dafür Platz (ab ca. 300 MB)), defragmentiert man selbst nach der Installation von Windows nicht und lässt dem freien Lauf, kommt doch sehr schnell runter auf 80 % und dann ist der Weg auch nicht mehr weit nach unten ;) ...

..,-
Mir ging es beim Video um allgemein die Defragmentation (ohne und mit = stottern und flüssig), bei den roten Dingern handelt es sich um kein Movie, aber ich kenne kein "echtes" Defragprogramm, was eine Datei so weit auseinander legt und wenn das die normale Arbeitsweise von MS Defrag ist...

Aha, mit Nachbarschaft wolltest du mir also scheinbar sagen, dass viele Windows-Benutzer gar nicht wissen, dass es Fragmentierung gibt. Ja klar, na und? Was hat das mit dem Problem von Manu zu tun oder damit, wie groß der Performance-Einbruch ist? Wolltest du sagen: Viele Benutzer holen aus ihrem Rechner nicht die maximale Geschwindigkeit raus, weil sie nie defragmentieren und nie temporäre Dateien löschen? Sicher. Und trotzdem funktioniert es im Großen und ganzen...Jep, das wollte ich damit sagen ... hätte er sie vorher schon defragmentiert, hätte er nicht so einen Performenceeinbruch, nur wie du schon sagst, es funktioniert doch noch alles im grossen und ganzen (und schön langsam) ...
und hatte ich nicht irgendwo geschrieben, das es auch die Performence erhöht ? da ich die ganze Zeit von einem "normalen" User ausgehe, wundert es mich, das du mir auf einmal zustimmst oder wie darf ich dein "Sicher" deuten ??? ...

Und da ist die nächste Unterstellung. Habe ich gesagt, alle würden das machen? Nein, ich habe gesagt, dass es genügt. Alle zwei Monate reicht übrigens auch. Wenn man seine Platten nicht zu mehr als 85% vollschaufelt, aber dann kann man de facto ja auch nicht mehr vernünftig defragmentieren.

Und nochwas, was dir gefallen wird: Mehr als OO Defrag Free und Page Defrag braucht kein Privatanwender. Alles andere bringt keinen auch nur im gerigsten im Vergleich zum Aufpreis zu rechtfertigenden Nutzen.Wie voll man seine HDD schaufelt, ist wumpe, interessant sind daran nur die Bewegungen der Dateien selbst, wenn man regelmässig defrag macht, fällt es auch nicht auf und Word schiebt danach nur noch wenig von sich durch die Gegend, so wie die meistens anderen Proggies ebenfalls ...

Hab ich auch nix gegen, das man nur OO Defrag Free und Page Defrag (kenne ich nicht) braucht, aber es ist meines Wissens nach KEIN Standardprogramm von MS, woher soll Manu oder jemand anderes so etwas wissen ? und ich gehe jede Wette mit dir ein, das man bei ihm auch was davon merkt, egal, was für eine CPU, HDD oder wieviel Ram er hat ...

Das Problem steht genau hier. Für jeden nachzulesen. Aha, was willst du mir damit sagen ? Das mofa84 die Frage schon lange beantwortet hatte und du ... äähh ... naja ...

Zunächst stellt man für die Auslagerungsdatei einen zum Testen sinnvollen Grundwert ein, z.B. das Doppelte des physikalischen RAMs. Dann ruft man den Systemmonitor auf, klickt auf die Schaltfläche mit dem Plus-Zeichen, wählt als Datenobjekt die Auslagerungsdatei und fügt den Leistungsindikator "Belegung (%)" hinzu. Nun bekommt man eine schönen Graphen über die Belegung der Auslagerungsdatei angezeigt, einschließlich Minimum, Maximum und Durschnitt. Nun arbeitet (oder spielt) man einfach ein Weile das, was man auch sonst so macht. Hinterher kann man im Diagramm des Systemmonitors sehen, zu wieviel Prozent die Auslagerungsdatei im Schnitt und maximal ausgelastet war. ... was soll ich dazu nur sagen, wäre prima wenn das auch in der Computer Blöd drinne stehen würde oder MS sowas selber hinbekommen würde ...

Achja, bin zu faul, die ID rauszusuchen, hab dann einfachmal ein Bild gemacht, wo ich mich doch frage, wie ich deine Kommentare deuten darf ... wäre es nur ein Märchen, müsstes es doch überflüssig sein, oder ???