Warum kommt der RAM-"blubb" schon bei 3.3 GB Ram-Nutzung und nicht erst bei 4GB-Nutzung?

Wichtig ist das, was an Ram frei ist.
Die ganzen Angaben mit 8 GB, 16 GB oder gar 32 GB haben überhaupt keine Aussagekraft.

Der TS mag es sehr gerne, wenn ~5,5 GB für ihn frei verfügbar sind. Ja, richtig gelesen, nicht 3,2 GB, nicht 3,5 GB, nicht 4 GB, sondern ~5,5 GB.

Denn wie ich bereits mehrfach darlegte und auch beweisen konnte, gibt es außer dem TS noch andere Sachen, die ihrerseits Ram benötigen, wenn der TS laufen soll: DirectX, OpenAL, PhysX, etc etc...
(Irgendwo hatte ich dazu mal ein Bild gemacht...)
Edit: Gefunden: Train Simulator 2015 ist extrem langsam

Zitat von Prelli

Der TS mag es sehr gerne, wenn ~5,5 GB für ihn frei verfügbar sind. Ja, richtig gelesen, nicht 3,2 GB, nicht 3,5 GB, nicht 4 GB, sondern ~5,5 GB.

Also reichen jetzt die 8 GB aus für den TS mit seinem Anhang also ohne andere zusätzliche Programme.
Oder wären 16 GB besser.

Hallo Prelli,
ok, dann werde ich mir wohl mal 2 Ram-Riegel mit 2 x 8gb bestellen müssen, obwohl alle anderen Strecken im TS mit mein 8Gb RAM gut laufen.

Trainrunner

@Prelli: Das kann ich nicht bestätigen. Du spielst auf diesen Beitrag an, nicht wahr? Train Simulator 2015 ist extrem langsam

Da steht "Commit", nicht "Physical Memory". Das ist nicht der RAM-Speicher, sondern der Commit Charge, quasi der "angemeldete" RAM-Speicher im Konvolut aus Auslagerungsdatei und RAM. Wieviel RAM wirklich benötigt und belegt werden hängt damit nicht zusammen. Ich habe die Situation mal nachgestellt, Knotenpunkt Hamburg mit Rollmaterial bis zum Dump:

Das ist der Commit Charge, wie man erkennen kann hat der TS sich selbst und Windows für den TS wie bei dir 4,6GB "reserviert". Diese "Reservierung" kann er aber nie verwenden, er wird schon weit, weit vorher abstürzen.

Das ist der physikalische, echte Speicher. 3,6GB, dann folgt der Dump. Und da ist auch die magische Grenze, irgendwo bei 3,XGB, beim physischen Speicher. Ob nun Windows für die Anwendung weiteren Speicher "reserviert" ist völlig irrelevant, den TS haut es bei 3,XGB auf die Schnauze. Den im System Commit "verfügbaren" Speicher kann man übrigens auch mit der Auslagerungsdatei erweitern - solange auch nur ein wenig echter RAM frei ist, wird diese nicht verwendet.

Und ja, hier sind bereits alle DLLs und Laufzeiten eingerechnet, u.A. auch DirectX. Diese können keinen "neuen" Speicher allokieren, zumindest nicht ohne Tricks.

8GB RAM mit eingeschalteter Auslagerungsdatei (=> Standardeinstellung) für den System Commit (die Auslagerungsdatei wird dabei normalerweise nicht verwendet, nur für den Fall der Fälle "reserviert") reichen selbst mit offenem Firefox und Mailprogramm und 4GB "Grundbelastung" locker aus.

Grüße

Wollte damit das ansprechen was @Prelli verdeutlicht hat. Dass man natürlich noch neben her was laufen hat und das auch RAM nimmt, und daher lieber mehr als zu wenig hat.

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. Ob das nun durch OpenAL, DirectX, PhysX oder sonstwas beansprucht wird, kann ich ad hoc nicht sagen.

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.

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.
Auch hier gilt der uralte EisenbahnerComputerspruch: "Es gibt keinen Ersatz für Ram, außer noch mehr Ram".

Kurz: Man sollte 5 GB an freiem Ram bereitstellen.
Wer nebenher die Kochrezeptedatenbank, Blender, MSOffice, Browser und Tetris laufen lassen will, der kann das natürlich tun, sollte aber gegebenenfalls von 8 auf 16 GB Ram aufrüsten.

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

Wieder was gelernt. Vielen Dank für die sehr gute Erklärung.

Zitat von Scarlet

dem Train Simulator auf 16GB oder sogar 32GB aufzurüsten, weil dann evtl. die Moselstrecke doch läuft, ist schlicht sinnfrei.

Bringt anscheinend auch nichts. Ich kann seit dem TS2016 Update auf kaum einer Strecke mehr sinnvoll fahren.
Ich hab 16GB Arbeitsspeicher und trotzdem stürzt mein TS schon bei c.a. 3,2 GB ab. Obwohl mein OS meist nicht mehr als 4 GB belegt. Dem TS bleiben daher immer, im schlimmsten Fall, mindestens 10 GB. Trotzdem kann ich nicht mit hoher Szeneriequalität fahren. Stufe 1 muss reichen sonst kriege ich auf den meisten Strecken einen Dump. Besonders "schlimm" ist es auf:
-Moselstrecke
-HaSi V3
-München-Garmisch mit TW Update

Wobei ich sagen muss das ich es nicht einmal mehr ohne KI-Verkehr schaffe. Mit sowieso nicht.

Das nutzt dem TS aber noch immer nix.

Zitat von dazzle2

Hallo,

es gibt doch ein kleines Tool, welches die 4GB Ram Sperre bei 32Bit Systemen umgeht. Ich kann mit meinem 32Bit Sytstem so die vollen 6gB Ram nutzen die ich installiert habe.

Mahlzeit, du sprichst vermutlich das LAA der PAE an (Large Adress Aware, Physical Adress Extension)
Wenn das nur an der exe was machst, täuscht du dich da. Das Betriebssystem wird dann weiterhin nur maximal 4 GB Speicher Adressieren können.

Eine Möglichkeit ist es, PAE auch im Betriebssystem zu Aktivieren, dann könnte das System die vollen 6 GB nutzen, aber Programme sind dann dennoch auf maximal 4 GB Begrenzt.

Das ganze zu Aktivieren, ist bei Windows aber recht schwierig, hat aber auch seine Gründe:

Es gibt etliche Treiber und auch Programme, die mit PAE unter 32 Bit nicht zurecht kommen, was das ganze System extrem instabil macht. Weshalb das bei Windows generell aus geschaltet ist, und auch nur schwer zu Aktivieren ist.

@lol515

Scarlets Beitrag richtig lesen, Hirn einschalten, und nachdenken.

Der Nachteil ist, dass das wesentlich ineffizienter ist da die GPU die Berechnungen wesentlich schneller durchführen kann als die CPU.

*gelöscht*

Hat sich da bei PhysX was geändert?
Früher musste ein Spiel - soweit ich mich erinnere - GPU-PhysX explizit unterstützen, ansonsten wurde es immer über die CPU berechnet. Unabhängig von der verbauten Grafikkarte.

Sorry für die Nachfrage, bin schon seit über fünf Jahren AMD-Nutzer.

Also, da hat sich eigentlich nichts geändert.

Sobald die GPU Physx Unterstützt, wird die GPU dafür verwendet.

D.h. Nvidia seit, uff schlag mich tot. Und AMD Radeon Grafikkarten vielleicht in 100 Jahren mal... AMD lehnte ja Nvidias Angebot, eine Komplett Kostenloser Nutzung und vollen zugriff auf PhysX ab, da man da lieber was eigenes machen will. (Ne, da wird nix eigenes kommen, das ist schon ewig her, und gekommen ist nie etwas in die Richtung von AMD)

Und der Nachteil der CPU Berechnung ist auch, das es viele PhysX Effekte gibt, die dann gar nicht erst Berechnen werden. Und viele PhysX Effekte werden vereinfacht, da die CPU einfach nicht genug Rechenleistung für so was hat. (Hört sich komisch an, is aber so. Eine CPU ist gar nicht für solche Rechenaufgaben ausgelegt, eine GPU hingegen schon.)