| |
| Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für Creo |
| |
| Integriertes PTC-Add-On ModelSearch , ein Anwenderbericht
|
Autor
|
Thema: Hauptspeicher Überlauf (2854 mal gelesen)
|
janzi Mitglied Konstrukteur
Beiträge: 97 Registriert: 23.01.2002 Creo Elements / Direct Modeling 19.0 M030
|
erstellt am: 04. Mrz. 2004 17:38 <-- editieren / zitieren --> Unities abgeben:
Hallo zusammen, wir haben ein Poblem mit der Größe des Hauptspeichers. Hier als Beispiel mal die Zuwächse: System 160 MB OSD mit Machining + STEP 340 MB Part Data von Cadenas 380 MB OSD Baugruppe Größe (49MB) 675 MB z.B Schraube aus Part Data dazugeladen 830MB etc. Wenn man dann eine neue Sitzung eröffnet ohne OSD herunterzufahren bleiben die 830 MB bestehen. Was mich zudem verblüfft, lade ich die Schraube(vorher 155 MB Hauptspeicherzuwachs) bevor ich unsere OSD Baugruppe lade, also bei 380 MB ist kein merklicher Zuwachs zu verzeichnen. Gibt es dafür eine Erklärung. Gruß Jürgen Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
clausb Ehrenmitglied V.I.P. h.c.
Beiträge: 2914 Registriert: 20.12.2000 Ich schreibe das hier in meiner Freizeit und spreche weder für meinen Arbeitgeber noch für andere Firmen. Mehr Unsinn von mir unter clausbrod.de.
|
erstellt am: 04. Mrz. 2004 19:05 <-- editieren / zitieren --> Unities abgeben: Nur für janzi
Der erste Schritt zur Klaerung besteht darin zu erfahren, wie genau Du gemessen hast. Wie sind die MB-Zahlen zustandegekommen? Ansonsten ein paar allgemeine Hinweise: 1. OSDM reserviert immer dann zusaetzlichen virtuellen Speicher vom Betriebssystem, wenn der bereits angeforderte, interne Speicher nicht mehr ausreicht. 2. Einmal vom Betriebssystem angeforderter virtueller Speicher wird nicht an das Betriebssystem zurueckgegeben. Das ist aber auch nicht noetig, weil das Betriebssystem automatisch nicht mehr benutzte Speicherseiten auf Platte auslagert und damit Platz im Hauptspeicher gewinnt. Man kann diesen Prozess unter "Mem Usage" im Task Manager beobachten, wenn man OSDM eine Weile lang inaktiv stehenlaesst. Alternativ kann man das OSDM-Fenster auch mal kurz minimieren; das "erzwingt" eine sofortige Deaktivierung der meisten Speicherseiten, die zu OSDM behoeren. 3. OSDM fordert zunaechst grosse Speicherbloecke vom Betriebssystem an, die es dann fuer seine eigenen Zwecke in kleine Bloecke zerlegt. Wenn Speicher freigegeben wird (weil beispielsweise ein Modell geloescht wird), werden die kleinen Bloecke auch tatsaechlich als frei markiert, bleiben aber so klein, wie sie gerade sind. So fragmentiert also mit der Zeit der interne Speicher, und irgendwann liegen nur noch viele kleine freie Bloecke herum. Wenn nun fuer eine Operation (beispielsweise das Laden der Schraube) grosse Speicherbloecke gebraucht werden, werden eventuell keine mehr gefunden, und OSDM fordert neue grosse Speicherbloecke vom Betriebssystem an. 4. OSDM versucht allerdings auch, seinen internen Speicher zu defragmentieren und damit zusaetzlichen Platz zu gewinnen. Da das aber eine eventuell zeitaufwaendige Massnahme ist, geschieht das nur bei bestimmten Gelegenheiten und nicht bei jeder Speicheranforderung, und auch nicht direkt nach jeder Speicherfreigabe. Zusammenfassung: Ohne *genaue* Messdaten kann ich nur Vermutungen anstellen, aber ein Erklaerungsmodell ist, dass das Laden der Baugruppe den internen Speicher fragmentiert, so dass dann beim Laden der Schraube neuer Speicher angefordert werden muss. Claus
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
janzi Mitglied Konstrukteur
Beiträge: 97 Registriert: 23.01.2002 Creo Elements / Direct Modeling 19.0 M030
|
erstellt am: 05. Mrz. 2004 08:59 <-- editieren / zitieren --> Unities abgeben:
|
clausb Ehrenmitglied V.I.P. h.c.
Beiträge: 2914 Registriert: 20.12.2000 Ich schreibe das hier in meiner Freizeit und spreche weder für meinen Arbeitgeber noch für andere Firmen. Mehr Unsinn von mir unter clausbrod.de.
|
erstellt am: 05. Mrz. 2004 15:21 <-- editieren / zitieren --> Unities abgeben: Nur für janzi
Der Task Manager hat verschiedene Methoden, den Speicherverbrauch anzuzeigen: 1. Die verschiedenen Speicherwerte unter "Performance". Diese Werte sind global und gelten fuer alle Prozesse. Da hier auch der Einfluss anderer Prozesse hineinspielt, verwende ich i.a. diese Werte nicht so gern. 2. Die Speicherwerte in der Prozessliste. In der englischen Version gibt es hier beispielsweise die Spalten "Mem Usage", "Peak Memory Usage" und "Virtual Memory Size". Nur die erste dieser Spalten ist per Voreinstellung aktiv; die anderen kann man ueber "View/Select Columns" zuschalten. "Mem Usage" zeigt an, wieviel virtueller Speicher pro Prozess *aktiv* ist, also in juengerer Vergangenheit noch benutzt wurde. (Das entspricht in etwa dem, was man anderswo auch als "working set" bezeichnet.) Wenn man eine Applikation eine Weile lang untaetig herumstehen laesst oder sie minimiert, verringert sich der Wert in dieser Spalte, weil das Betriebssystem dann naemlich vom Prozess angeforderte Speicherseiten peu a peu (oder aber - beim Minimieren - ziemlich ploetzlich) auf Platte auslagert und damit den Hauptspeicher freiraeumt. "Virtual Memory Size" hingegen zeigt an, wieviel virtuellen Speicher eine Applikation beim Betriebssystem fuer sich reserviert hat. Dieser Wert verringert sich i.a. nicht. Uebrigens gilt dies fuer viele Applikationen und nicht nur fuer OSDM. Claus
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
janzi Mitglied Konstrukteur
Beiträge: 97 Registriert: 23.01.2002 Creo Elements / Direct Modeling 19.0 M030
|
erstellt am: 09. Mrz. 2004 09:16 <-- editieren / zitieren --> Unities abgeben:
Hallo Claus, habe es jetzt mal so gemacht wie du es beschrieben hast. Die Zahlenwerte sind etwas anders, im Prinzip verhält sich mein Hauptspeicher exakt gleich. Habe jetzt zwar für einen Client 2GB Hauptspeicher zusätzlich bestellt (sprich 3GB komplett), trotzdem macht mich die Sache etwas nervös. Wenn das Verhalten nähmlich so bleibt, kann ich halt ca. 15-20 verschiedene Normteile zusätzlich laden, dann habe das System wieder an die Wand gefahren. Gruß Jürgen Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
clausb Ehrenmitglied V.I.P. h.c.
Beiträge: 2914 Registriert: 20.12.2000 Ich schreibe das hier in meiner Freizeit und spreche weder für meinen Arbeitgeber noch für andere Firmen. Mehr Unsinn von mir unter clausbrod.de.
|
erstellt am: 10. Mrz. 2004 08:18 <-- editieren / zitieren --> Unities abgeben: Nur für janzi
Zitat: Original erstellt von janzi: Wenn das Verhalten nähmlich so bleibt, kann ich halt ca. 15-20 verschiedene Normteile zusätzlich laden, dann habe das System wieder an die Wand gefahren.
Wenn der Taskmanager anzeigt, dass fuer den Prozess beispielsweise 700 MB reserviert sind, heisst das noch lange nicht, dass das Modell tatsaechlich auch 700 MB belegt. Denn intern kann OSDM zu diesem Zeitpunkt sehr wohl eine Menge freien Speicher parat haben - er gibt ihn halt nur nicht direkt wieder ans Betriebssystem zurueck, sondern haelt ihn fuer kommende Aufgaben vor, also beispielsweise fuer das Laden der naechsten 20 Normteile. Man huete sich also vor vorschnellen Interpretationen der Anzeigen im Task Manager. Claus
[Diese Nachricht wurde von clausb am 10. Mrz. 2004 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
janzi Mitglied Konstrukteur
Beiträge: 97 Registriert: 23.01.2002 Creo Elements / Direct Modeling 19.0 M030
|
erstellt am: 10. Mrz. 2004 08:50 <-- editieren / zitieren --> Unities abgeben:
Hallo Claus, bei uns fängt dann aber leider der Prozess der Auslagerns auf die Festplatte an, und damit wird der OSD unendlich langsam. Sollte es hier noch eine andere Testmöglichkeit wie über den Taskmanager geben, bin ich gerne bereit sie durchzuführen. Gruß Jürgen Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
clausb Ehrenmitglied V.I.P. h.c.
Beiträge: 2914 Registriert: 20.12.2000 Ich schreibe das hier in meiner Freizeit und spreche weder für meinen Arbeitgeber noch für andere Firmen. Mehr Unsinn von mir unter clausbrod.de.
|
erstellt am: 10. Mrz. 2004 09:59 <-- editieren / zitieren --> Unities abgeben: Nur für janzi
Zitat: Original erstellt von janzi: bei uns fängt dann aber leider der Prozess der Auslagerns auf die Festplatte an, und damit wird der OSD unendlich langsam.Sollte es hier noch eine andere Testmöglichkeit wie über den Taskmanager geben, bin ich gerne bereit sie durchzuführen.
Wenn man explizit erreichen will, dass OSDM maximal den verfuegbaren Hauptspeicher benutzt, kann man (ausnahmsweise) das gute alte Kommando memory-limit verwenden. Beispiel fuer ca. 1 GB RAM: Code:
(memory-limit :data 1000)
Damit gaukelt man OSDM vor, dass das System maximal etwa 1 GB Speicher hat. Das hat zur Folge, dass nie mehr als etwa dieses eine GB vom Betriebssystem angefordert wird, also kann (wenn nicht andere Applikationen dazwischen aktiv werden oder selbst viel Speicher brauchen) fast alles im RAM abgewickelt werden. Der Nachteil ist natuerlich, dass man halt nur maximal 1 GB echte Daten laden und bearbeiten kann. Im allgemeinen sollte man memory-limit nicht benutzen; fuer Deine Testzwecke koennte es aber nuetzlich sein, denn so kannst Du ohne uebermaessiges Paging ein Modell nach dem anderen hinzuladen und herausfinden, wieviel schon mal in ein GB passt. Von dort aus kannst Du dann extrapolieren. Zum zweiten Punkt: Da der Taskmanager nicht wissen kann, wie OSDM (oder andere Applikationen) intern ihren Speicher verwalten, kommst Du damit vermutlich nicht wirklich weiter. Rufe stattdessen testweise nach jedem Schritt die (undokumentierte und inoffizielle) Funktion memory-malloced auf: Code:
(display (f2::memory-malloced))
Das sagt Dir (in Bytes), wieviel Speicher tatsaechlich gerade fuer Modell und Verwaltungsdaten (inklusive UNDO-Puffer) belegt sind. Nicht enthalten sind ein paar Bloecke wie beispielsweise der LISP-Speicher, aber den kann man fuer diese Tests zunaechst ignorieren. Apropos UNDO: Der UNDO-Puffer sammelt sich natuerlich auch ueber die Zeit an. Normalerweise werden maximal etwa 30 UNDO-Schritte (vom Anwender einstellbar) zwischengespeichert, damit man jederzeit zurueck zum alten Modellzustand kann. Erst wenn der Speicher knapp wird, wird der UNDO-Puffer zwangsweise abgeraeumt. Auch dieses Verhalten kann also zu zunaechst verwirrenden Testergebnissen fuehren. Viel Erfolg, Claus
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
brando Mitglied Betriebsleiter
Beiträge: 1 Registriert: 05.05.2004
|
erstellt am: 05. Mai. 2004 23:44 <-- editieren / zitieren --> Unities abgeben: Nur für janzi
Ich hab mich gerade erst eingelogt, arbeite aber schon einige Zeit mit SD 8 und hatte das problem auch Falls das Problem noch nicht gelöst ist ich hab mir das Programm freemem aus dem Netz geholt und in die Start Datei installiert Sobald der Rechner luft hat schaufelt er den Speicher leer grüße otto ------------------ Mfg Brand Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |