Hallo zusammen Ich weis, komischer Titel^^ also, ich hab z.Zt. 6GB RAM in meinem System (Core i7 920), das OS ist WIN7 64bit. Vom Windows 7 hab ich in der Sidebar ein Gadget, dass mir die momentane RAM-Auslastung anzeigt, die steht so bei etwa 1.5GB von den 6 die zur Verfügung stehen und wenn ich mehr anfange zu arbeiten oder zu gamen steigt die Auslastung allerhöchstens mal auf vielleicht 3GB an. Wieso nimmt sich das System nicht mehr? Denn da wird doch garantiert, obwolh mehr RAM zu Verfügung steht noch in die Auslagerungsdatei geschrieben? Macht das OS abhängig vom total zur Verfügung stehenden RAM wieviel davon es für sich selbst belegt oder wie läuft das? Lg
kannst ja mal testen, ob das system probleme damit hat, den restlichen speicher zu benutzen und herausfinden, warum es so früh auslagert. macht ja die sache nicht gerade leistungsfähiger.
Wiewohl dein Namensgeber massgeblich die deutsche Sprache geprägt hat steige ich bei deinen Sätzen nicht ganz durch. Jedenfalls wird nur soviel RAM verwendet wie benötigt wird. Vom Rest nutzt Windows einen Teil als Disk-Cache. Windows neigt dazu, mit der Zeit auch dann lange nicht mehr genutzte RAM-Inhalte ins Pagingfile auszulagern, wenn es dafür keinen ersichtlichen Grund gibt.
was soll der denn in den ram laden? Klar kann Windows7 64bit den kompletten speicher nutzen. Was zeigt denn der Taskmangager an? Nimm doch mal ein programm was richtig speicher braucht. Wieso kauft man sich 6GB RAM, wenn man nicht weis was man damit tun kan.
Lass ein paar virtuelle Maschinen laufen, dann wird das schon ;) Habe hier im Notebook 8 und im Desktop 12 GB und Auslastung ist im Normalfall 60%
Ja natürlich kann ich den RAM manuell füllen (ich habe zurzeit auch ne virtuelle maschine am laufen (und die braucht 4GB sonst geht nix;))) nein, die frage war mehr wenns ums nackte Betriebssystem geht, warum das dann nicht mehr reinschreibt (weils nicht mehr platz braucht oder weils nicht will?;)) Und doch, natürlich weis ich was ich mit 6GB RAM anstellen kann;)
Ich verstehe zwar immer noch nicht wo dein Problem liegt, aber du kratzt hier wohl an einem fundamentalen Unterschied zwischen Mensch und Maschine. Eine Maschine verwendet stets nur grad so viel Resourcen wie sie braucht. Wenn was übrig bleibt ist ihr dies egal. Der Mensch jedoch pflegt die zur Verfügung stehenden Resourcen stets in überschaubarer Zeit voll auszureizen. Ganz gleich ob das nun Plattenplatz ist oder Erdöl. Andersrum gegengefragt: Wieso erwartest du von einem Betriebssystem, dass es den Speicher deines Rechners vollständig füllt, wenn es nichts gibt, womit man diesen sinnvoll füllen könnte?
Martin Luther schrieb: > Denn da wird doch garantiert, > obwolh mehr RAM zu Verfügung steht noch in die Auslagerungsdatei > geschrieben? Wenn noch RAM zur Verfügung steht, aber trotzdem die Auslagerungsdatei beschrieben wird, stimmt etwas mit der Speicherverwaltung des Betriebssystems nicht. Woher weisst Du, dass in die Auslagerungsdatei geschrieben wird?
J.-u. G. schrieb: > Wenn noch RAM zur Verfügung steht, aber trotzdem die Auslagerungsdatei > beschrieben wird, stimmt etwas mit der Speicherverwaltung des > Betriebssystems nicht. Wobei man dabei unterscheiden muss, ob grad jetzt was reingeschrieben wird, obwohl bannig Platz ist, oder ob das irgendwann früher passierte, als es enger zuging. Zumal Windows auch mal Code/Daten zugunsten von Disk-Cache auszulagern bereit ist, wenn ihm das sinnvoll erscheint. > Woher weisst Du, dass in die Auslagerungsdatei > geschrieben wird? Vermutlich weil was drin ist. Zeigt Windows an.
Windows Taskmanager (z.B. über Str+Alt+Entf) -> Leistung (man sieht: ordentlich was frei) -> Resourcenmonitor -> Arbeitsspeicher -> Unten der Balken: Das dunkelerer (sry) Blau: "Standby" ist ebenfalls belegter Speicher, welcher bereitsvorgecachte Daten beinhaltet. Dies sind meist Daten, wo Windows versucht in die Glaskugel zu schauen um ggf. schneller dranzukommen. Wird mehr Speicher benötigt wird es einfach überschrieben, da die Daten dort redundant liegen. Verdrängen ist hier nicht nötig - daher kann man diesen Bereich auch ruhig als freien Speicher ansehen - er bringt trotzdem einen gewissen Speedup. Mehr Ram macht also auch sinn, wenn man ihn nicht "direkt" benötigt. In einem Jahr sieht es eh wieder aders aus: dann ist er schon wieder zu knapp ;-)
Wenn man sowas live in Tools wie Perfmon bewundert, dann könnten auch statistische Schmutzeffekte dazu kommen. Wie sich das bei Windows verhält weiss ich grad nicht, aber manche Betriebssysteme neigen dazu, zwischen Paging und File-I/O keinen fundamentalen Unterschied zu machen (nachvollziehbar wenn man sich Files als memory mapped denkt). Das kann in entsprechenden Laststatistiken dazu führen, dass File-I/O als Paging-Aktivität erscheint.
A. K. schrieb: > Vermutlich weil was drin ist. Zeigt Windows an. Ich kenne mich mit Windows 7 überhaupt nicht aus, aber wenn ausgelagerte Inhalte wieder zurück in den RAM wandern, sollte doch die Auslastungsanzeige der Auslagerungsdatei zurückgehen, unabghängig davon, ob in der Auslagerungsdatei tatsächlich etwas gelöscht wird.
Ich muss nochmal was nachschieben: So falsch läuft es da bei Windows garnicht - die frage ist wie man die Qualität einer Speicherverwaltung messen möchte. Unixoide Benutzer werfen Windows gerne vor Speicher zu verschwenden, Windows Benutzer werfen Unixoiden vor sie würden auch Speicher verschwenden in dem sie ihn nicht benutzen. Wenn man nun sich über die Tatsache bewusst ist, das die CPU im Schnitt gerade mal bei 2% aller Befehle nicht auf einen lahmen Bus (z.B. Platte) warten muss, so ist der Windowsansatz nicht umbedingt falsch. Das ganze läuft bei knappem Speicher aber schon wieder in den Sand ;-)
J.-u. G. schrieb: > Ich kenne mich mit Windows 7 überhaupt nicht aus, Ich auch nicht. > aber wenn ausgelagerte Inhalte wieder zurück in den RAM wandern, > sollte doch die Auslastungsanzeige der Auslagerungsdatei zurückgehen, Das schon. Andererseits geschieht das erst, wenn das Zeug auch benötigt wird, nicht bereits auf Verdacht weil was frei ist. Es gibt beispielsweise in allerlei Programmen wie auch im Betriebssystem diverse Ecken, die nur bei System/Programmstart und -Ende benötigt werden und nie zwischendrin. Sowas wandert u.U. irgendwann ins Pagingfile und bleibt da vergraben bis zum Shutdown, auch wenn noch so viel RAM frei ist.
Stryker schrieb: > Wenn man nun sich über die Tatsache bewusst ist, das die CPU im Schnitt > gerade mal bei 2% aller Befehle nicht auf einen lahmen Bus (z.B. Platte) > warten muss ??? Was für Befehle meinst du hier? Prozessorbefehle oder sowas wie "DIR" in der Commandline?
Stryker schrieb: > Wenn man nun sich über die Tatsache bewusst ist, das die CPU im Schnitt > gerade mal bei 2% aller Befehle nicht auf einen lahmen Bus (z.B. Platte) > warten muss, Also das kann ich mir bei bestem Willen nicht vorstellen, dass 98% der CPU-Befehle auf die Peripherie zugreifen.
A. K. schrieb: > Es gibt beispielsweise in allerlei Programmen wie auch im Betriebssystem > diverse Ecken, die nur bei System/Programmstart und -Ende benötigt > werden und nie zwischendrin. Sowas wandert u.U. irgendwann ins > Pagingfile und bleibt da vergraben bis zum Shutdown, auch wenn noch so > viel RAM frei ist. was auch sinnvoll ist, denn man wirklich mal ram gebraucht wird, dann muss nicht erst etwas weggeschrieben werden. Ich würde sogar vermuten das es im Pagefile und im RAM ist. Wenn der Ram gebraucht wird, wird er einfach freigeben, wenn die Daten doch mal gebraucht werden stehen sie zur Verfügung.
J.-u. G. schrieb: > Also das kann ich mir bei bestem Willen nicht vorstellen, dass 98% der > CPU-Befehle auf die Peripherie zugreifen. Man könnte diese Aussage auch auf die Cache-Levels abbilden. Aber auch dann sollten es i.d.R. >>90% Hitrate auf dem L1 sein, sonst hat jemand was ganz ganz falsch gemacht.
A. K. schrieb: > J.-u. G. schrieb: > >> aber wenn ausgelagerte Inhalte wieder zurück in den RAM wandern, >> sollte doch die Auslastungsanzeige der Auslagerungsdatei zurückgehen, > > Das schon. Andererseits geschieht das erst, wenn das Zeug auch benötigt > wird, nicht bereits auf Verdacht weil was frei ist. Wäre es nicht cleverer, bei ausreichend Platz im RAM ausgelagerte Pages in den RAM zurückzulesen, bevor deren Inhalte benötigt werden?
A. K. schrieb: > ??? Was für Befehle meinst du hier? Prozessorbefehle oder sowas wie > "DIR" in der Commandline? Prozessorbefehle ;-) Klar sollte im L1 der Hit >> 90 sein, sonst gehts ja wieder los mit dem lahmen Anhängseln... Aber es gibt ja dummerweise noch Kontextwechsel - da kommt man dann einfach nicht drumherum wieder alles wegzuschreiben und neu einzulesen. Hier entstehen auch das "große Ideln", dicht gefolgt vom Warten auf Semaphoren aber das ist ja schonwieder ein Scheduler Thema. BTW: Dort machen's die Unixoiden in der Tat besser ;-)
J.-u. G. schrieb: > Also das kann ich mir bei bestem Willen nicht vorstellen, dass 98% der > CPU-Befehle auf die Peripherie zugreifen. Sorry, habe es vermutlich zu undeutlich geschrieben: bei mir ist alles nach dem L1 Peripherie. Wenn man natürlich Nc betreibt, dann stimmt meine Aussage allerdings nicht - warum sollte klar sein, sonst gerne fragen ;-)
J.-u. G. schrieb: > Wäre es nicht cleverer, bei ausreichend Platz im RAM ausgelagerte Pages > in den RAM zurückzulesen, bevor es benötigt wird? Klar. Noch cleverer wäre es jedoch, die Lottozahlen von nächster Woche zu kennen. ;-) Auf Cache-Ebene gibts das, in Form von automatischem prefetching. Bei Paging habe ich davon noch nichts gehört. Wobei bei Paging heute eigentlich die Regel gilt, dass man bei spürbarem Umfang an Paging nicht so sehr am Algorithmus des Betriebssystems sondern an der Speicherausstattung schrauben sollte. Wenn man spürbar Paging kriegt, dann weil man zu wenig RAM frei hat. Dann ergibt das keinen Sinn. Hat man aber genug RAM frei, dann ist es ziemlich wahrscheinlich, dass das ausgelagerte Zeug dort gut untergebracht ist, weils auf absehbare Zeit kein Aas braucht.
Man sollte auch beachten, dass solche Algorithmen immer wieder mal daneben hauen und gewisse Traditionen ungern gebrochen werden. Seit Microsoft die Bits jenseits der 16 entdeckt hat, ist Windows in einem Aspekt bemerkenswert konsistent geblieben: Schreibt man auf normalem Weg (d.h. ohne caching hints) ein File, das grösser als der Speicher ist, dann fegt Windows gnadenlos alles aus raus, was nicht niet- und nagelfest ist, um Platz für den in diesem Fall völlig sinnlosen Disk-Cache zu kriegen. Das führt dazu, dass man während solcher Aktionen je nach persönlichem Geschmack besser eine Tasse Kaffee oder Tee zu sich nehmen sollte, aber nicht versuchen sollte, parallel dazu irgendwas Sinnvolles am Rechner zu tun. Old habits die hard, leider.
A. K. schrieb: > Klar. Noch cleverer wäre es jedoch, die Lottozahlen von nächster Woche > zu kennen. ;-) A. K. schrieb: > Hat man aber genug RAM frei, dann ist es > ziemlich wahrscheinlich, dass das ausgelagerte Zeug dort gut > untergebracht ist, weils auf absehbare Zeit kein Aas braucht. Wie jetzt? Weis dass BS nun, ob es die Daten kurzfristig braucht oder nicht? Wenn 4.5GB RAM frei sind (Angabe OP) könne doch die paar MB, die beim Herunterfahren nötig sind jederzeit wieder zurück ins RAM geschrieben werden.
Stryker schrieb: > Sorry, habe es vermutlich zu undeutlich geschrieben: bei mir ist alles > nach dem L1 Peripherie. Und du willst also allen Ernstes behaupten, dass 98% aller Befehle cache misses sind? Wäre dem so, dann hätten die CPU Designer der letzten Jahrzehnte durchweg Bockmist gebaut und sie hätten sich den teuren schnellen L1 Cache auch genausogut sparen können. Woher hast du diese groteske Zahl?
Bei mir (Linux 2.6.37) ist momentan der Gesamte nicht genutzte ram, ca. 1,6GB vollständig mit dem Cache gefüllt, leerer RAM wird also nicht verschwendet. Der Swap ist praktisch leer, geht doch; auch nach 7 Tagen uptime.
J.-u. G. schrieb: > Wie jetzt? Weis dass BS nun, ob es die Daten kurzfristig braucht oder > nicht? Wissen tut es garnichts, es vermutet. Und zwar vermutet es, dass jenes Zeugs, was schon sein 3 Stunden unverrückt im Pagingfile sitzt, aller Voraussicht nach auch nicht in Kürze irgendjemand interessieren könnte. Anders würde es sich zwar bei Zeugs verhalten, das erst seit kurzer Zeit drin liegt und wenn grad viel Paging-Traffic ist. Dummerweise ist das genau der Zeitpunkt, wo sich mangels genug freiem RAM solche Gedanken verbieten. > Wenn 4.5GB RAM frei sind (Angabe OP) könne doch die paar MB, die beim > Herunterfahren nötig sind jederzeit wieder zurück ins RAM geschrieben > werden. Klar. Aber warum? Hast du auch nur ein einziges Mal einen Programmtest gesehen, der nachmisst, wie lange es dauert, ein Programm oder Betriebssystem runterzufahren?
Luk4s K. schrieb: > Bei mir (Linux 2.6.37) ist momentan der Gesamte nicht genutzte ram, ca. > 1,6GB vollständig mit dem Cache gefüllt, leerer RAM wird also nicht > verschwendet. Der Swap ist praktisch leer, geht doch; auch nach 7 Tagen > uptime. Linux != Windows. Linux verhält sich in dieser Frage anders. Das muss nicht zwangsläufig besser sein, denn so belegt auch Kram RAM, das, weil ewig nicht gebraucht, als Disk-Cache vielleicht besser genutzt wäre. Der offensichtliche Effekt: Linux fährt nach längerer Nutzung i.d.R. deutlich schneller runter als Windows.
A. K. schrieb: > Klar. Aber warum? Hast du auch nur ein einziges Mal einen Programmtest > gesehen, der nachmisst, wie lange es dauert, ein Programm oder > Betriebssystem runterzufahren? Nein. Aber der Einwand, dass Daten im Pagefile für den Programm/System-Shutdown vorgehalten werden kam ja auch nicht von mir. Wenn das BS, so wie Du sagst, keine Ahnung von der Nützichkeit der Daten im swap hat, so spricht doch nichts dagegen, diese Daten auf Verdacht wieder einzulesen, wenn freier RAM im Überfluß vorhanden ist und sonst nichts zu tun ist.
Die Speicherverwaltung von Windows war schon immer sehr schlecht. Nimm lieber Linux.
gunnar schrieb: > Die Speicherverwaltung von Windows war schon immer sehr schlecht. Nimm > lieber Linux. Sehr interessant! Bitte genauere Infos (Insbesondere hinsichtlich pagefile/swap-Management).
Stryker schrieb: > Aber es gibt ja dummerweise noch Kontextwechsel - da kommt man dann > einfach nicht drumherum wieder alles wegzuschreiben und neu einzulesen. Der letzte x86 Prozessor mit durchweg virtuell getaggtem L1 war der K5, und selbst der tat das nicht wirklich. Nope, ein Kontextwechsel hat nur über die Grösse des Working Set Einfluss auf Cache-Traffic, nicht aus Prinzip. Und damit auf 2% zu kommen ist nur speziellen darauf "optimierten" Testprogrammen möglich.
gunnar schrieb: > Die Speicherverwaltung von Windows war schon immer sehr schlecht. Nimm > lieber Linux. immer solche pauschalen sinnlosen aussagen.
http://blogs.msdn.com/b/tims/archive/2010/10.aspx http://technet.microsoft.com/en-us/magazine/2007.03.vistakernel.aspx (kleiner Test auf einem Notebook mit Win7 x64 4 GB RAM: Neustart fast alles frei ca. 140 MB im Standby/Cache, VS2010 und Browser gestartet und ein paar Minuten gewartet -> Standby/Cache 1350 MB)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.