---

Speicher.jpg

Hallo zusammen!

Ich habe eine interessante Feststellung gemacht:
Wenn ich zu einer kleinen Baugruppe eine große Unterbaugruppe hinzufüge, dann wird der Speicher (RAM) ordentlich aufgefüllt => Geht ja nicht anders. Lösche ich diese große Unterbaugruppe wieder, dann bleibt der Speicher so lange voll bis ich STRG+Q drücke. Erst dann gibt SWX den Speicher wieder frei.
So weit so gut => Wenn mans weiß ist es ja kein Problem.

ABER: Komischerweise wenn ich diese große Baugruppe anstatt einzufügen einfach nur parallel öffne und wieder schließe, bleibt der Speicher voll, und es gibt keine Möglichkeit mit STRG+Q irgendwie den "Müll" wieder aus dem Speicher zu bekommen. => d.h. ich hab grad mal eine kleine paar MB große Baugruppe offen, das SWX belegt jedoch zB. 1,8 GB Speicher.   

Ergo: Ich MUSS das SWX schließen und wieder öffnen, damit ich wieder freien Speicher hab. Das kanns doch nicht sein, oder!!??!?!? 

Ihr werded euch jetzt fragen wo das Problem liegt weil die kleine Baugruppe dann eh schnell geschlossen und wieder geöffnet ist, aber das kann ich ganz leicht beantworten: Bei uns sind auch die kleinen Baugruppen paar 100MB groß => Somit ergeben sich enorme Ladezeiten.

=> Hat jemand eine Idee???

Grüße,
Horst

(SWX 2006 SP5.1 unter XP SP2)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Das ist halt die Speicherverwaltung von Windows, im XP ists auch wesentlich besser geworden wie es im 2k noch war. Tja entweder auf Vista hoffen oder mal ein professionelles Windows probieren, würde da zu 2003 Server raten, das auf XP aufsetzt und auch zu einem Workstation Betriebssystem leicht umkonfiguriert werden kann, aber mehr kostet als XP und ähnlich viel wie Vista Business.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielleicht kannst Du etwas in der Art versuchen: http://www.snapfiles.com/get/foptimizer.html

------------------
<# while ( not asleep ) { sheep++; } />

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

Was passiert, wenn Du Solidworks minimierst?

Ich habe damals unter dem Inventor beobachtet, dass wenn Anwendungen minimiert werden auch Speicher frei gegeben wird.
Ein Systemadmin hat mir dann erklärt, dass dies unter XP immer funktionieren sollte.

------------------
Gruß Daniel

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

[...]
Ergo: Ich MUSS das SWXSolidWorks schließen und wieder öffnen, damit ich wieder freien
Speicher hab. Das kanns doch nicht sein, oder!!??!?!?
[...]

Es sind z.Zt noch 1,7GB RAM frei ....

Zunaecht mal hat die Belegung der Auslagerungsdatei nichts mit der aktuellen
RAM-Nutzung zu tun. Je mehr Prozesse aktiv sind, desto groesser die Belegung
der Auslagerungsdatei. Ein Programm wird in der Auslagerungsdatei 'geparkt'.
Somit erhoeht sich die Ausnutzung der Auslagerungsdatei sobald ein Programm
gestartet wird. Zur  Ausfuehrung wird das Programm dann pageweise (a 4K) in
den RAM geladen.  Fordert ein Programm jetzt Speicher an (immer virtuell) oder
laedt Module nach so aendert sich die Belegung dito. bei Freigaben.

Die Belegung im RAM wird im Taskmanager unter 'Speicher-Nutzung' ausgewiesen.
Dies stellt aber nur das dar was ein Programm max. mal belegt hatte und nicht
das was effektiv noch benoetigt wird. Solange im RAM noch genuegend Speicher
vorhanden ist wird kein OS unbenutzte Pages loeschen. Minimiert/Maximiert man
die Anwendung so reduziert sich die RAM-Nutzung die im Taskmanger angezeigt wird
auf den 'Current Workingset' also das was effektiv momentan benoetigt wird. Die
VM-Size wird davon nicht beinflusst und damit auch nicht die Auslagerungs-Datei.
Die Auslastung sinkt erst wenn das Programm beendet wird oder es angeforderten
Speicher/Module wieder freigibt (hier STRG-Q)

Die Groesse des Adressraumes den ein Programm zur Verfuegung
hat ist fuer ein 32-Bit Windows ca. 1,9GB, mit dem /3GB Switch
in der Boot.ini 2.9GB. Mehr kann ein Programm nicht belegen. Das
ist aber, wie gesagt, die Groesse des virtuellen Speichers, die
mit dem realen RAM nichts zu tun hat, den verwaltet das OS.

Klaus

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

[Diese Nachricht wurde von modeng am 25. Mrz. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo HH,
vielleicht hilft dir das ja weiter:
http://www.sybyte.de/pcw/wxp/Speicher_defagmentieren/Speicher_defragmentieren.htm[/URL]

------------------
Gruß  Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

http://www.sybyte.de/pcw/wxp/Speicher_defagmentieren/Speicher_defragmentieren.htm

------------------
Gruß  Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Warum hängt der mehr an den Link als ich einfüge?!
Einfach mal so Googlen: "script zum speicher leeren"

------------------
Gruß Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen!

Erstmal danke für die Antworten.
@Daniel:
Wenn ich SWX minimiere passiert gar nix. Leider.

@Thorsten:
Danke für den Link, werd ich gleich mal ausprobieren.

@Klaus:
Das was du schreibst mag richtig sein, ABER:
Fakt ist, dass wenn ich oben genannte Situation habe (fast nichts im SWX geöffnet hab) mir trotzdem das SWX abstürzt wenn ich eine Baugruppe öffne. Speicherverwaltung hin und her.
Zitat "...Die Auslastung sinkt erst wenn das Programm beendet wird oder es angeforderten Speicher/Module wieder freigibt (hier STRG-Q)..."
Eben, STRG+Q bewirkt die Speicherfreigabe zB. nach Löschen einer Unterbaugruppe, aber es fehlt die Funktion für die Speicherfreigabe nach schließen einer Baugruppe.

Grüße,
Horst

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

dann ist das ein SWX-Problem. Wie hoch ist denn die VM-Size (siehe
Prozesse)? Im RAM und im Page-Dataset ist noch genuegend frei. Ausserdem
mit welcher Meldung stuerzt den SWX ab?

Klaus

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

[Diese Nachricht wurde von modeng am 26. Mrz. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Speicher_01.jpg Speicher_02.jpg Speicher_03.jpg

Hi

Also ich bin mir nicht sicher welche Spalte du jetzt genau meinst, deswegen hab ich mal printscreens von 3 Situationen gemacht:
Bild_01: Während dem Laden.
Bild_02: Bei besagter Situation: Nach öffnen und wieder schließen größerer Baugruppen, UND nach minimieren und wieder maximieren von SWX!!!
Bild_03: Nach neuöffnen von SWX (praktisch Jungfräulich)!

Grüße,
Horst

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

im Bild 1 ist SWX  bei 86% CPU-Auslastung
          SWX belegt im RAM (Speicherauslastung) 1.4GB
          Virtueller Speicher (VM-Size) 1,3GB 
            es sind noch ca. 600MB frei falls
            der /3GB Switch nicht gesetzt ist
         
im BIld 2 ist SWX bei 0% CPU-Auslastung
          SWX belegt im RAM (Speicherauslastung) 6,1MB
          Virtueller Speicher (VM-Size) 696MB
         
im BIld 3 ist SWX bei 0% CPU-Auslastung
          SWX belegt im RAM (Speicherauslastung) 172MB
          Virtueller Speicher (VM-Size) 148MB

Das seh' ich kein Problem. Falls SWX sich den virtuellen Addressraum selbst
fragmentiert und dadurch ein Problem bekommt gibt es keine Moeglichkeit
das von aussen zu korrigieren.

Anmerkung: werden neben SWX  andere Prozesse wie Outlokk, Google, etc.
momemtan wirklich alle benoetigt? Sie vermindern den noch nutzbaren RAM
und koennen u.U. verhindern das benoetigte Pages von SWX ins RAM
geladen werden koennen, da sie nicht asugelagert werden koennen
und auch nicht verschiebbar sind. Das waer' dann ein 'hausgemachtes'
Problem.

Klaus

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

[Diese Nachricht wurde von modeng am 26. Mrz. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

SWSpeicherbedarf+CPU.JPG

Morgen erstmal 

ich weiß ja nicht wie sich das bei euch auswirkt, aber vielleicht ändert sich ja das Speicherverhalten bei euch, wenn Ihr den virituellen Speicher deaktiviert!? Bei genug Speicher ist der nicht wirlich mehr nötig... wobei ich natürlich nicht weiß, bis zu was für einer Baugruppengröße das funktioniert. Aber zu der im Bild angehängte BG (ca. 10MB) kann ich noch zig andere öffnen, ohne dass das System arg belastet ist und wenn ich welche schließe, bekomme ich auch Speicherplatz zurück. Davon aber kein Screenshot, denn sonst haben wir hier nachher eine Art Daumenkino 

------------------
Gruß Thorsten

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Mei lieb, Baugruppen von 10MB.   
Unsere großen Baugruppen haben ca. 1GB.
Unterbaugruppen von 500MB sind bei uns nichts besonderes.
Deswegen steigen wir auch bald um auf das X64 (64 bit).
Dann können wir unsere 8GB RAM die wir schon seit einem Jahr in unseren Rechnern haben eeeeeendlich ausnutzen. 

Grüße,
Horst

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

[...]
hne dass das System arg belastet ist und wenn ich welche schließe, bekomme ich auch Speicherplatz zurück.
[...]

das RAM wird auch freigegeben nur laesst das OS diese Pages im Speicher
sie sind jedoch jederzeit ueberschreibbar. Siehe Differenz Bild-1 zu
Bild-2. Es waren ca 1.4 GB RAM nicht mehr von SWX belegt. Der Adressraum
verkleinerte sich um 1.3 GB. Fazit: sowohl im Adressraum als auch
im RAM wurde Speicher freigegeben. Der Pagedataset hat darauf keinen
Einfluss und er ist auch nicht identisch mit dem 'virtuellen Speicher'

Wenn ein 32-Bit Programm Speicher im Adressraum (immer virtuell) anfordert
und dabei die 1.9/2.9 GB Grenze ueberschreitet gibt's einen Abbruch. Das
hat mit dem verfuegbaren RAM nichts zu tun. Fuer ein 64-Bit Programm
ist die Grenze bei einigen TB (2^64). Wie weit das RAM ausgenutzt
wird haengt von OS ab, es kann also sein das 8GB Ram vorhanden sind
dennoch die Auslastung bei 2GB liegt.

Klaus 

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

[Diese Nachricht wurde von modeng am 26. Mrz. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Anbei News bzgl. der Speicherauslastung vom Cheffentwickler von SW-GB

The task manager is not an accurate report of memory used and the customer would be advised to use Private bytes for the SolidWorks Process through perfomon when looking at memory usage.  When an assembly is closed part of the memory used will be held in use by the library files being used, these would not be unloaded after use.  Memory allocated to model data may be retained for re-use or in case the part / sub-assmebly model referenced is reloaded in the same session, such a use of memory would be expected to improved performance on subsequent loading of the file.

Without reference to customer models and workflow it is not possible to provide more specific advice.
________________________________________________

=> Ich interpretier das so, dass offiziell zugegeben wird dass SWX den Speicher zumüllt.

mfg
Horst

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von - HH -:
...Ich interpretier das so, dass offiziell zugegeben wird dass SWX den Speicher zumüllt...

---

Hallo Horst,
zunächst einmal: vielen Dank für die Info (wobei mir nicht klar ist was Privat bytes bedeutet  ).

Offiziell zugeben ist gut  Die bekennen sich nur dazu, womit sie vor Jahren angetreten sind: ein CAD-System auf Windows-Plattform.
Was auch immer der Grund für diese Art der Speichernutzung ist, da läßt sich bestimmt auch was verändern.

IMHO würde da vielleicht ein Verbesserungsvorschlag in Richtung SolidWorks.com helfen, damit dies (vielleicht als Option  ) einstellbar ist. Ich gehe fest davon aus, das die Programmierer (notfalls auch in Verbindung mit Gill Bates) dieses Ziel erreichen können.

Beste Grüße,
Ralf
@T.C.: ein Leerzeichen und Enter/CarriageReturn sorgen für den richtigen Link 

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

da braucht nichts zugegeben werden, das ist gute Programmerung und
hat nichts mit 'zumuellen' zu tun. ;-)

Aus Performancegruenden werden beim Schliessen nicht alle Objekte
freigegeben, das ist richtig und auch nicht weiter tragisch. Das
vermindert nur den noch verfuegbaren Adressraum mehr nicht. Der
Begriff 'Memory' bezieht sich nicht auf das RAM.
Sofern SWX feststellt das diese Objekte nicht mehr benoetigt werden
weil eine andere Datei geoeffnet wird, werden diese freigegeben.

Gleiches macht auch Windows: der Erststart eines (grossen) Programms
dauert laenger als ein folgender Neustart da viele Dinge im Cache
gehalten werden.

Ist *keine* Auslagerungsdatei vorhanden *und* laufen viele Prozesse
gleichzeitig, die u.U alle ihren Adressraum gut ausnutzen, so kann
es zu einem Engpass im RAM/Cache kommen. In diesem Fall wird das OS
einen oder mehrere Prozesse abbrechen muessen, da eine Auslagerung
auf den Pagedataset nicht moeglich ist.

Ist dagegen eine Auslagerungsdatei vorhanden lagert das OS auf den
Pagedatset aus um 'Luft' im RAM fuer einen Prozess zu schaffen. Das
kann im Extremfall zu sehr hohen Pagingraten (Thrashing) fuehren
mit der Folge das vor lauter Paging kaum noch ein Prozess effektiv
arbeiten kann. Hier hilft nur RAM vergroessern oder Prozessanzahl
vermindern.

Auch das 64-bit OS ist davor nicht gefeit wenn es ein Missverhaeltniss
zwischen der Anzahl der laufenden Prozesse und dem verfuegbaren RAM
gibt.

Klaus

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von modeng:
Gleiches macht auch Windows: der Erststart eines (grossen) Programms
dauert laenger als ein folgender Neustart da viele Dinge im Cache
gehalten werden.

---

Welches mit diversen TweakTools (X-Setup ist eines davon) geändert werden kann, so dass Windows die geladenen DLLs sofort nach Programmende freigibt.
Ich bin mir jetzt nicht mehr sicher, ob das TweakUI von Microsoft das auch kann.

Oder  für den Fall das jemand ZUVIEL RAM hat: http://www.xteq.com/downloads/  -> Xteq RAM Alloc 1.0

------------------
<# while ( not asleep ) { sheep++; } />

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

[...]
Welches mit diversen TweakTools (X-Setup ist eines davon) geändert werden kann, so dass Windows die geladenen DLLs sofort nach Programmende freigibt.
[...]

und wozu? Das wird es schon selbst machen wenn es Platz braucht.

Klaus

------------------
Kein Problem wird gelöst, wenn wir darauf warten, daß sich andere darum kümmern (M.L. King)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Horst,

Ich habe da ein ähnliches Problem festgestellt.
Es ist bei mir allerdings etwas anders.
Ich habe diese Probleme mit dem vollen Speicher noch nie derart gehabt, bis ich das System neu aufgesetzt habe, bzw. den richtigen Grafikkartentreiber installiert habe nachdem ich das System neu aufgesetzt hatte. Mein Rechner ist verhältnismäßig schwach (zwei Jahre alt und vom Aldi) und ich mache auch nichts großartiges mit Solidworks. Der Apparat hat mit all seinen Untergruppen ca. 50 MB.

Bevor ich windows neu installiert habe ging das System einigermaßen einwandfrei, zumindest ohne diese komische Fehlermeldung und zu schnellen Speicherüberladungen. Dann hatte ich nach der Neuinstallation SWX ohne den Nvidia Treiber ausprobiert. Die Transparenzeffekte und dynamische Schatten fehlten, was vorher ging.

dann habe ich die original Treiber CD rausgekramt und den Treiber installiert. Beim ersten man SWX Starten kam dann nach einer gewissen (verhältnismäßig viel zu kurzen Zeit) diese seltsame Fehlermeldung und SWX wurde beendet. Leider kann ich mich nicht mehr an den Text erinnern.
Bei erneutem Versuch die Situation zu provozieren ist mir aufgefallen, dass sich der Speicher nur dann auflädt, wenn man das Objekt rotiert oder zoomt, und das auch nur im geshadeten Modus. Wenn man nicht mehr um die Objekte rotiert, geschieht auch nichts mehr mit dem Speicher. Also habe ich solange die Ansicht gedreht, bis der die Auslagerungsdatei eine Größe von 1,62 GB erreicht hatte (ich habe nur 1 GB RAM). Bei ca. 920 MB hat SWX den Arbeitsspeicher wieder freigeräumt, d.h. dass der tatsächlich verbrauchte Platz im RAM von ca. 170 MB auf 60 MB reduziert wurde ("Speicherauslastung" im Taskmanager). Bei einem Wert von 1,62 GB ist die Größe der Auslagerungsdatei stehengeblieben, egal ob ich weiter rotiert habe, oder den gesamten Apparat geschlossen habe und neu aufgerufen. Dann schließlich, ist es aber zu Fehlern im Programm gekommen, ohne dass eine Meldung angezeigt wurde. Ich habe es also nicht geschafft, diese Fehlermeldung nocheinmal zu provozieren.
Ich wollte das Modell weiter einfach rotieren aber es reagierte nicht. und es wurden rote Punkte im Modell angezeigt die ich nicht zuordnen konnte. Ach ja..und die Fläche, auf die der Schatten projeziert wird wurde auf einmal vollkommen schwarz dargestellt.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP