8GB sind aber eben völlig ausreichend und kein Flaschenhals. Ein normales Windows 7/8/10 64bit Betriebsystem hat eine Grundlast von ~3GB auf dem RAM, mit einem Browser gerne auch 4GB. Einem Nutzer daher zu empfehlen, wegen dem Train Simulator auf 16GB oder sogar 32GB aufzurüsten, weil dann evtl. die Moselstrecke doch läuft, ist schlicht sinnfrei.
Zitat von Prelli
Aus meiner Grafik, die ich im besagten Beitrag angehangen habe, geht klar draus hervor, dass zum Betrieb des TS etwas mehr als 5 GB an Ram benötigt und auch wieder freigegeben wird.
Nein, das geht nicht hervor. Da steht Commit. Nicht Physical Memory, nicht Virtual Memory, nicht Memory. Das ist der Commit Charge, Commit, System Commit. Das ist nicht die RAM-Belastung. Das ist die Gesamtmenge der für Anwendungen vorsichtshalber reservierten Pages (Speicherblöcke) im virtuellen Speicher. Dieser ist bei mir z.B. 25GB groß und ist die Gesamtmenge von Auslagerungsdatei und echtem RAM zusammen. Dieser Speicher ist nicht belegt. Er ist sicherheitshalber vorgemerkt und nicht belegt, damit die Anwendung bei weiterem Speicherhunger auch sicher noch Reserven hat. Das ist ein großer Unterschied. Mein aktuell belegter Commit beträgt z.B. 6,1GB. Mein Hauptspeicher ist aber nur mit 3,2GB belegt.
Commitbelastung - Arbeitsspeicherbelastung = Nicht verwendeter Speicher, der nur und ausschließlich als "verfügbar" zugesichert wurde aber nicht verwendet wird.
Ich habe den TS jetzt fast ein Dutzend Mal abstürzen lassen, mit verschiedenen Loks und Strecken. Jedes Mal sind 4GB bis 5,6GB im Commit reserviert (Nicht belegt!) und 3,6GB im Arbeitsspeicher allokiert und belegt. Beispiel:
Hier habe ich eine sehr große Grundbelastung generiert, in dem ich mehrere Gigabyte echten Speicher (=> RAM) vorher allokiert habe. Damit sinkt der noch vorhandene, freie echte Speicher auf ungefähr 4GB. Nach dem Absturz des TS werden, wie gehabt, 3,6GB Speicher freigegeben. Im Commit werden allerdings über 4,5GB freigegeben, da die Anwendung nun nicht mehr existiert und keinen zusätzlichen Speicher mehr allokieren kann. Deshalb kann auch der von der Anwendung gewünschte "Sicherheitsvorrat" (den sie als 32bit Anwendung nie nutzen kann!) "freigegeben" werden.
Man beachte auch die Tatsache, dass mein Arbeitsspeicher (12GB) nach dem Absturz laut Commit bereits fast voll wäre und vor dem Absturz um 4GB überschritten gewesen wäre. Das ist aber nicht der Fall, die Auslagerungsdatei (pagefile.sys) wurde ebenfalls nicht verwendet. Es ist einfach nur "reservierter", vorgemerkter Speicher, der nicht belegt ist und, im Fall des TS, auch nie belegt werden kann.
Der Train Simulator versucht (durch DirectX) direkt vor dem Absturz etwas "reservierten" Speicher zu allokieren, rennt aus dem signed Integer (2^32) und sucht sofort als nächstes den Ordner um den Dump zu plazieren. Es kann diesen Bereich einfach nicht ansprechen.
Zitat von Prelli
ich will damit nur verdeutlichen, dass zum betrieb des TS 3,5 GB freies Ram oftmals nicht ausreichen, wenn er davon nur 2,5 bekommen kann, während 1,0 GB davon von anderen Sachen benötigt werden, die aber zum betrieb des TS unabdingbar sind.
Mehr kann er so aber auch nicht bekommen, selbst bei 16GB freiem Speicher. Der Train Simulator mit allen Bibliotheken, PhysX und DirectX bildet als Prozess eine Einheit. Der Speicherbedarf (im RAM!) dieses Prozesses ist die Summe des Speicherbedarfs aller Threads und Module. Der Train Simulator startet nicht DirectX, PhysX, OpenGL usw. quasi als unabhängige Kindprozesse, sie befinden sich im Train Simulator und werden ein Teil von diesem.
Zitat von Prelli
Es mag sein, dass Einiges davon ins virtuelle Ram umgeschaufelt werden kann, sollte kein echtes Ram frei sein, doch geht das auf jeden Fall auf die Performance.
Wird es nicht. Möglicherweise habe ich mich missverständlich ausgedrückt: Es wird nichts ins "virtuelle Ram" ausgelagert, es wird nur vorgemerkt. Solange die Anwendung den Speicher nicht wirklich allokiert und benutzt verändert sich nichts, nur im Commit steigt der Wert - weder der Arbeitsspeicher noch die Auslagerungsdatei werden angefasst.
Praxisbeispiel: Ein Nutzer hat 8GB Arbeitsspeicher und 4GB Auslagerungsdatei, also 12GB virtuellen Speicher (=> Commit). Davon sind grundsätzlich, durch Betriebsystem und den beliebten Katzenbildern 4,2GB sowohl im Arbeitsspeicher als auch im Commit belegt. Nun startet er den TS, dieser reserviert im Laufe der Zeit 5GB im Commit. Damit liegt der Commit bei 9,2GB und theoretisch über dem vorhanden Arbeitsspeicher. Noch passiert aber garnichts, da der TS bisher nur 3,5GB im Arbeitsspeicher belegt, dieser ist also zu 7,7GB voll. Der TS läuft, ohne etwas in die Auslagerungsdatei zu schreiben. Nun stürtzt der TS ab, da er die 3,6GB-Marke überschreitet. Der Computer gibt nun sowohl die 3,6GB im Arbeitsspeicher frei als auch die "reservierten" 5GB im Commit.
Solange noch Arbeitsspeicher vorhanden ist wird die Auslagerungsdatei nicht angefasst, auch wenn der Commit die Größe des Arbeitsspeichers überschreitet. Denn der Commit ist nicht der beschriebene oder genutzte RAM, sondern nur der für spätere Verwendung vorgemerkte und für die Anwendung zugesicherte Speicher. Der Train Simulator inkl. DirectX, PhysX, OpenAL, OpenGL o.Ä. kann diesen aber nicht über 3,XGB nutzen. Es ist technisch einfach nicht (ohne Tricks) möglich.
Verstehst du den Unterschied zwischen dem Commit (von Windows als "Verfügbar" zugesicherter Speicher, der nicht komplett verwendet werden muss oder, im Falle des TS, kann) und dem Arbeitsspeicher oder der Auslagerungsdatei (von Anwendungen genutzter Speicher)? 
Der Train Simulator nutzt auch mit allen Modulen (leider!) nur 3,XGB.
Grüße
Manfred
