Arbeitsspeicher "geändert" läuft voll

Schinzie

Rear Admiral
Registriert
Feb. 2008
Beiträge
5.955
Hallo CB,

ich habe folgendes Problem und versuche es schon seit einiger Zeit zu lösen.
Ich rechne in der Arbeit große FEM-Modelle mithilfe von MSC. Nastran auf meinem Notebook.
Das Programm arbeitet primär mit der Festplatte (deshalb auch 2 SSD´s), für eine große Rechnung schreibt es mehrere dutzend GB als temporäre Datei auf die Datenträger (angegebendes SCRATCH verzeichnis)
Den Arbeitsspeicherverbrauch kann i ganz genau einstellen, und der Proezess verwendet dann auch nicht mehr (Im Tastmanager nachprüfbar)
Nun ist es so, dass mir der Arbeitsspeicher trotzdem voll läuft. Wenn ich mir im Resourcemonitor von Windows7 Professional 64bit angucke, was da los ist, sehe ich, dass der Teil "geändert" massiv ansteigt und den ganzen physikalischen Arbeitsspeicher füllt.

Ich habe zu Testzwecken die Auslagerungsdatei auf 16GB gestellt, ohne Erfolg. Dieses "geändert" wird nur auf dem physikalischen Arbeitsspeicher geschrieben.

Die Definiton für dieses "geändert" ist laut Windows: Arbeitsspeicher, dessen Inhalt auf einen DAtenträger geschrieben werden muss, bevor er zu einem anderem Zweck verwendet werden kann.

Was genau ist das, und kann man das irgendwo beeinflussen?

Hat es was mit den riesigen Datenmengen zu tun, oder womit? Wie gesagt, die Anwendung selber ist es nicht.

Die Datenträger laufen auch nicht voll, das war nämlich meine erste Vermutung, deshalb eine größere SSD.

Wäre sehr dankbar, wenn mir jemand weiterhelfen könnte.

gruß
 
Zuletzt bearbeitet:
Moin, verstehe das Problem nicht so ganz. Prinzipiell ist eine Berechnung von Daten im RAM der Berechnung von Daten von der HDD immer vorzuziehen. Der RAM ist einfach viel schneller. Wobei in deinem Fall wohl eh ein ständiger Austausch von Daten HDD<--> Ram vonstatten geht.
Geht es darum das der Rechner während dieser Berechnungen kein ordentliches Multitaskting mehr leistet ?
 
Es geht darum, dass der Rechner große Rechnungen mit paar Millionen Freiheitsgraden nicht mehr schafft. Es stürzt irgendwann mit einem Bluescreen ab (Physical memory dumping...). Davor hängt er.

Das tritt aber nicht während der eigentlihcen Rechnung auf, sondern während er auf den Datenträger schreibt.

Diese großen numerischen Rechnungen verwenden deshalb die Festplatten, da hier mit 40-60GB an Tempdatein hantiert wird, so viel Arbeitsspeicher hat kein Rechner.

Bei Rechnungen mit weniger Freiheitsgraden und weniger temporären DAtein funktioniert das wunderbar, und dank SSD´s bin ich wesentlich schneller als jeder HDD-Rechner.

das komische ist, dass unter Windows XP dieses Problem auf normalen HDD´s nicht auftritt. dort braucht es dann zwar einen halben Tag bis die Rechnung fertig ist, aber es läuft durch. Ich vermute dass es an Win7 und diesem "geändert" liegt.

Was genau soll das überhaupt sein?
 
Das sind nur gepufferte Daten, die das Betriebssystem noch nicht auf den Datenträger geschrieben hat. So wird der schnelle RAM ausgenutzt, anstelle auf die relativ langsame SSD zu warten. Merke: Ungenutzter RAM ist verschwendeter RAM.
Deshalb soll man ein Betriebssystem ja auch immer sauber runterfahren, anstelle einfach den Netzstecker zu ziehen. Nur so kann das System die Daten im RAM noch auf die Platte schreiben vor dem Ausschalten.

Dieses Verhalten ist eigentlich ein gutes Zeichen, es zeigt nämlich, dass Deine FEM-Software und das OS gut "zusammenarbeiten".

EDIT: Das System sollte dabei natürlich nicht abstürzen. Da liege ich dann wohl falsch mit meiner Vermutung.
Ergänzung ()

Welche Version (NX) setzt Du denn ein?
 
Das problem tritt sowohl bei MSC. Nastran 2008 R1 als auch bei MD Nastran 2010.1 auf.


gruß
 
Ich verwende ja kein NX, sondern MSC Nastran.

Wie gesagt, bei Windows XP scheint das Problem nicht aufzutreten. Ich weiß nicht, obs an den SSD´s liegen könnte. Bei Gelegenheit rechne ich es mal auf einer normalen HDD.

gruß
 
Schon mal versucht das Ganze im Kompatibilitätsmodus laufen zu lassen z.B. Windows XP.

Musst evtl. darauf achten, dass für die Berechnung eine andere exe ausgeführt wird und da ich nicht weiß, ob Kompatiblitätseinstellungen vererbt werden, würde ich diese direkt manipulieren.

Bye
 
Interessanter Gedanke, werd ich gleich mal ausprobieren, danke.


gruß
 
Ist die XP Installation auch eine 64bit Version ?
Wenn nicht mag es sein das der RAM einen Fehler aufweisst und das evtl. in einem Bereich der unter XP garnicht erst adressiert werden kann.
Hast mal memtest laufen lassen ?
 
Es sind alles 64bit Systeme. Die XP systeme sind auch nicht die von meinem Notebook, sondern andere Rechner die hier rumstehen. Memtest habe ich schon laufen lassen.

Brachte leider alles nichts, hier mal ein Screenshot von dem Problem. Der orange balken wächst so lange, bis er alles "grüne" und somit das System und die Rechnung erwürgt hat. Dann stürzt das System auch ab.


Edit:


Weiß jemand, wie ich diese Windows Cache funktion deaktivieren kann? Ich meine die Nutzung des Arbeitsspeichers zum buffern für Datenträgerschreibzugriffe?
Oder wenn möglich, wie man sie begrenzen kann?

@Docfaustus

Memtest hab ich parallel 4mal bis 260% laufen lassen, RAM Fehler kann ich somit zu 99% ausschließen.

Edit:

Man kann des doch bestimmt in der Registry irgendwie einstellen? Dazu müsste ich nur wissen, wie der Spaß heißt, jemand ne Ahnung?
gruß
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    105,5 KB · Aufrufe: 407
Zuletzt bearbeitet:
danke für den link, da war aber leider nix dabei. Aber das Problem scheint recht ähnlich zu sein.


Es ist irgendeine Cache Geschichte, ich weiß nur nicht welche.


gruß
 
Also in NX/Nastran heißt die "Zusatzauslagerungsdatei" SCRATCH-File. Vielleicht gibt es sowas ja auch in MSC/Nastran
 
Ja, die gibt es, in der werden auch zig GB an temporäreren Daten generiert. Deshalb die SSD. Bei der großen Rechnung, wo mir der Speicher voll läuft, werden fast 70GB da drin hin und hergeschrieben, deshalb sind hohe IOPS werte auch so wichtig.

Und genau dabei, wenn nachdem die Steifigkeitsmatrix usw. erstellt wurde, und die eigentliche Rechnung fertig ist, und er für alle 3 Millionen Knoten die Steifigkeiten, Verformungen usw. runterschreibt, füllt sich der Speicher als Buffer und läuft voll und erwürgt alle anderen Anwendungen.
Das dürfte nicht sein.


gruß
 
Und wie sieht es mit Deinem Ziellaufwerk aus? Ist das evtl. voll - bei 70GB-Scratch kann da schon eine op2 von 45GB zusammenkommen.
Ansonsten würde mir nur noch einfallen, dass Du die Speicherbelegung (in NX/Nastran: Solution Memory) einfach weiter reduzierst. Das dürfte bei einer Scratch auf der SSD nicht sooo stark ins Gewicht fallen.
 
Das der Speicher ausgeht war meine erste Vermutung, deswegen wurde eine größere SSD rangeschafft. Nach dem Systemabsturz bleiben die Daten im Scratch Verzeichniss und es wären noch über 50GB verfügbar.

Zum Test hab ich es mal über eine externe Festplatte mit 300GB freiem Speicherplatz laufen lassen, ohne Erfolg.

solution memory? Ist das die Größe des Scratch Verzeichnisses? wenn ich scr=yes rausnehme schreibt er fast alles in die DBALL, müsste aber zum selben fatalen Abbruch kommen.


gruß
 
Jetzt kommt es sogar ab und an vor, dass sich dieser blöde orange balken gar nema reduziert, auch, wenn keine einzige Anwendung läuft.

Das gibt es doch nicht?


gruß
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    248,6 KB · Aufrufe: 371
Ich hab mir mal den XP mode installiert und es dort getestet. Dort passiert es nicht, es läuft durch, zwar sehr langsam (da nur ein Kern und pro Rechnung maximal 1,6gb ,da 32bit), aber es läuft problemlos durch.

Es scheint wirklich ein Speicherleak in Verbindung mit Win7 zu sein, schade.

gruß
 
Zurück
Oben