CoCreate Modeling FAQ: Memory Management

topic end
<!--
   * Set TOPICTITLE = <nop>CoCreate Modeling FAQ: Memory Management
-->

---++!! CoCreate Modeling FAQ: Memory management

%TOC%

#LoadingLargeModels
---+++ %ENGLISH% How can I load models which exceed 2 GB in data size?

By default, both HP-UX and Windows limit the application's data space to
2 GB. The other 2 GB of the 32-bit address space are used for the system.

Various server versions of Windows, and recently also Windows XP Professional,
provide a boot-time option which switches the operating system
kernel into the so-called "4GT mode" where the kernel leaves 3 GB of
address space to the application. This gives us an additional gigabyte
of maenouvring space for model data.

Background explanations and instructions on the 4GT mode can be found
in the Microsoft Knowledge Base at http://support.microsoft.com/kb/q171793
and http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx.

With <nop>CoCreate Modeling 2005, another option is to 
[[#WindowsXp64][run <nop>CoCreate Modeling under Windows XP x64 Edition]].
On such a system, the available virtual address space for the application
is close to 4 GB.

With <nop>CoCreate Modeling 2006, a full 64-bit version will become available which can
use the vast amount of memory provided by 64-bit systems.

---++++ %GERMAN% Wie kann ich Modelle laden, die mehr als 2 GB Speicher belegen?

Normalerweise begrenzen sowohl HP-UX als auch Windows den Adressraum,
der von einer Anwendung f&uuml;r Daten benutzt werden kann, auf 2 GB.
Die anderen 2 GB im 32-Bit-Adressraum werden f&uuml;r das Betriebssystem
gebraucht.

Verschiedene Server-Versionen von Windows und neuerdings auch Windows XP
Professional kann man in einem speziellen Modus starten, der den
Betriebssystemkern in den sogenannten "4GT-Modus" schaltet. Dabei
begn&uuml;gt sich das Betriebssystem mit 1 GB Adressraum und &uuml;berl&auml;&szlig;t
die restlichen 3 GB der jeweiligen Anwendung. Damit erh&auml;lt man
ein zus&auml;tzliches Gigabyte f&uuml;r Modelldaten.

Hintergrundinformationen und Anweisungen zum 4GT-Modus findet
man bei Microsoft in der "Knowledge Base" unter http://support.microsoft.com/kb/q171793
und http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx.

<nop>CoCreate Modeling 2005 l&auml;uft auch unter Windows XP x64 Edition. Auf solch
einem System bekommen Anwendung Zugriff auf fast 4 GB Adre&szlig;raum,
also noch einmal 1 GB mehr als selbst im "4GT-Modus".

Ab <nop>CoCreate Modeling 2006 wird es eine volle 64-Bit-Version von <nop>CoCreate Modeling geben, die dann
auch den riesigen Adre&szlig;raum von 64-Bit-Systemen voll ausnutzen kann.

-- Main.ClausBrod, last updated 3 December 2005

---

---+++ %ENGLISH% I have enabled the /3GB mode, but still cannot load models which require more than 2.6 or 2.7 GB. How come?

The 3 GB of address space which are left to the application are not used solely
for data, but also for program components, such as the application code, any loaded
DLLs, buffers which those DLLs allocate etc. For example, there are graphics
drivers which allocate up to 256 MB in the application's part of the address
space. Therefore, the maximum amount of data which can be loaded also depends
on the number of activated system components (such as drivers).

---++++ %GERMAN% Ich habe den /3GB-Modus eingeschaltet, kann aber immer noch keine Modelle laden, die mehr als 2.6 oder 2.7 GB brauchen.

Die 3 GB Adressraum, die der Anwendung zugeordnet sind, werden nicht nur f&uuml;r Daten,
sondern auch f&uuml;r Programmkomponenten verwendet, beispielsweise also
f&uuml;r den Programmcode selbst, mitgeladene Systembibliotheken (DLLs),
von diesen DLLs angelegte Puffer und anderes. Beispiel: Manche Grafiktreiber
legen einen Puffer von bis zu 256 MB im Adressraum der Anwendung an.
Daher h&auml;ngt die maximale Datengr&ouml;&szlig;e, die man noch unterbringen
kann, auch von der Anzahl und Art der aktivierten Systemkomponenten (wie
etwa Treiber) ab.

-- Main.ClausBrod
 
---

---+++ %ENGLISH% Why does the Windows taskmanager only display a little more than 3.5 GB of physical RAM even though I have 4 GB of RAM in the system?

Some BIOS versions reserve certain address areas below the 4 GB line 
for themselves which they then use for _memory-mapped I/O_. Memory-mapped I/O
is a method to integrate hardware components into the system. The system
talks to those hardware components by reading from and writing to hardware
registers which appear in the address space just as if they were part
of regular memory.

Because those hardware registers are mapped into the address space below the 4 GB
address line, no real RAM can be mapped into the same address space.
To avoid conflicts between those hardware registers and RAM,
the BIOS will hide the RAM in those address areas - which is why the
Windows task manager cannot find it.

Advanced 32-bit systems could actually try to map the hardware registers
into address space above the 4 GB line. However, this is often not done
because this requires full PCI compliance from all PCI hardware devices in
the system, and vendors do not want their systems to crash just because
a user plugs in a PCI card which does not implement the full PCI
specification. Hiding some RAM in the BIOS is probably the lesser
evil in this case.

-- Main.ClausBrod

---++++ %GERMAN% Warum zeigt der Windows-Taskmanager nur etwas &uuml;ber 3.5 GB Arbeitsspeicher an, obwohl ich 4 GB RAM installiert habe?

Einige BIOS-Versionen reservieren bestimmte Adre&szlig;bereiche unterhalb der 4-GB-Marke f&uuml;r sich und benutzen sie f&uuml;r _memory-mapped I/O_. Das ist eine Methode, um Hardwarekomponenten im System zu integrieren. Das System kommuniziert mit den Komponenten, indem es aus Hardwareregistern liest und in diese hineinschreibt. Diese Hardwareregister werden in den normalen Arbeitsspeicher eingeblendet; f&uuml;r den Prozessor sehen sie wie ganz normale RAM-Speicherstellen aus.

Weil diese Hardwareregister in den Speicherbereich unterhalb von 4 GB abgebildet werden, kann in diesem Bereich nicht gleichzeitig echter Speicher benutzt werden. Um Konflikte zwischen den Hardwareregistern und dem echten Speicher zu vermeiden, wird der echte Speicher vom BIOS "versteckt" und daher auch nicht vom Windows-Taskmanager gefunden.

Etwas schlauere Systeme k&ouml;nnten &uuml;brigens die Hardwareregister einfach in den Speicherbereich oberhalb der 4-GB-Marke einblenden, so da&szlig; sich erst gar kein Konflikt ergibt. Allerdings wird das nicht besonders h&auml;ufig getan, weil das nur funktioniert, wenn alle im System eingesetzten PCI-Karten sich an die vollst&auml;ndige PCI-Spezifikation halten. Die meisten PC-Systemhersteller wollen aber nicht, da&szlig; ihre Systeme abst&uuml;rzen, nur weil ein Anwender eine veraltete PCI-Karte einsteckt, die sich nicht ganz an die Konventionen h&auml;t - der BIOS-Ausblendetrick ist hier das kleinere &Uuml;bel.

-- Main.MichaelMueller (translation) - 18 Jan 2005

---

---+++ %ENGLISH% How do I delete the UNDO buffer?
---+++ %ENGLISH% How do I define the maximum number of UNDO steps kept in memory?

While working with CoCreate Modeling, the software keeps track of previous
states of the model during the session in the so-called _UNDO buffer_. This, obviously,
consumes some memory.

<nop>CoCreate Modeling will delete the UNDO buffer automatically every now and then, i.e. it only
keeps a user-definable number of UNDO steps in memory. You can also explicitly
clear the UNDO buffer:
   * Open the Undo dialog using =Edit/Undo/=.
   * Check the =Expand= option for advanced parameters
   * Set the =Max Back= value to 1

Alternatively, you can achieve the same with a Lisp one-liner:
<pre>
  (undo :max_back 1)
</pre>

In the same dialog, you can also set the maximum number of UNDO steps which are
kept in memory (=Limit/Steps=).

---++++ %GERMAN% Wie löscht man den UNDO-Puffer?
---++++ %GERMAN% Wie stellt man die maximale Anzahl der UNDO-Schritte im Speicher ein?

Während man mit CoCreate Modeling arbeitet, merkt sich die Software
Zwischenstände des Modells innerhalb der aktuellen Sitzung im sogenannten
_UNDO-Puffer_. Das kostet natürlich Speicher.

<nop>CoCreate Modeling löscht den UNDO-Puffer hin und wieder automatisch; nur eine - vom Anwender
definierbare - Anzahl von Zwischenschritten wird im Speicher gehalten. Man kann
auch den UNDO-Puffer explizit löschen:
   * Den UNDO-Dialog über =Bearbeiten/Rückgangig/= öffnen.
   * Die Option =MenüLang= aktivieren
   * Den Wert =Max rückw= auf 1 setzen

Man kann dasselbe auch mit einem Einzeiler in Lisp erreichen:

<pre>
  (undo :max_back 1)
</pre>

Im gleichen Dialog kann man auch die maximale Anzahl der gepufferten Zwischenschritte
einstellen (über =Grenzwert/Schritte=).

-- Main.ClausBrod

---
---+++ %ENGLISH% Limiting the UNDO buffer to 10 steps does not seem to work - sometimes the UNDO dialog reports more than 10 steps in the buffer!

This is quite normal - the limit which you specify is actually the _minimum_ number
of steps which will be kept. Every once in a while, <nop>CoCreate Modeling will check the number
of modelling steps in the UNDO buffer, and removes all _but_ the most recent
10 steps from the UNDO buffer (if 10 is the limit you specified, that is).

---++++ %GERMAN% Die Anzahl der Schritte im UNDO-Puffer auf 10 zu begrenzen, scheint nicht zu funktionieren - manchmal zeigt der UNDO-Dialog mehr als 10 Schritte im Puffer an!

Das ist ganz normal - das Limit gibt die _minimale_ Anzahl der Modellierschritte an,
die aufgehoben werden. Ab und an prüft <nop>CoCreate Modeling, ob die Anzahl der Modellierschritte im
Puffer das angegebene Limit überschreitet - wenn ja, werden alle überzähligen
Schritte entfernt; die jeweils letzten 10 bleiben übrig (wenn man 10 als
Limit angegeben hat).

-- Main.ClausBrod

---
<a name="returningmemory"></a>
---+++ %ENGLISH% I deleted all UNDO buffers, but the Windows task manager tells me that the application still uses the same amount of memory. How can this be true?

The memory which was previously used for UNDO buffers is now free, but <nop>CoCreate Modeling does not return
it to the operating system; rather, it assumes that it will be needed anyway by any <nop>CoCreate Modeling
commands that follow, and so it keeps the memory around instead of returning it to the OS,
figuring out after a few seconds that it actually still needs the memory, and requesting it
from the OS again. So in this case, the values displayed in the Windows task manager are
_not_ a good indication of what is really going on.

---++++ %GERMAN% Ich habe den gesamten UNDO-Puffer gelöscht, aber der Windows-Taskmanager sagt mir, daß die Applikation immer noch genausoviel Speicher belegt. Wie kann das sein?

Der Speicher, der zuvor für den UNDO-Puffer benutzt wurde, ist nun tatsächlich frei, aber <nop>CoCreate Modeling gibt ihn nicht an das Betriebssystem zurück. Stattdessen nimmt <nop>CoCreate Modeling an, daß der Speicher ohnehin bald wieder für irgendwelche Folgekommandos gebraucht wird, und daher wird der freie Speicher intern bereitgehalten, anstatt ihn erst an das Betriebssystem zurückzugeben, nur um nach ein paar Sekunden festzustellen, daß man den Speicher doch wieder braucht, und ihn dann umständlich und zeitaufwändig beim Betriebssystem wieder anzufordern. In diesem Fall sind also die Werte im Windows-Taskmanager _kein_ guter Anhaltspunkt dafür, was wirklich vorgeht.

-- Main.ClausBrod

---+++ %ENGLISH% Why deleting a model does not <i>really</i> delete the model

New <nop>CoCreate Modeling users are sometimes confused by the following observation: They load
a large model; some memory is consumed, according to the Windows task manager.
Then they delete the model - and even more memory is consumed!

<center>
<img src="%ATTACHURL%/afterload.jpg" alt="After loading large model" border="1" align="center" />
<br clear="all" />
Session 1: After loading a large model
</center>

<center>
<img src="%ATTACHURL%/afterdelete.jpg" alt="After deleting large model" align="center" border="1" />
<br clear="all" />
Session 1: After deleting the model</center>

This seems counterintuitive - after all, the model was just
deleted, so shouldn't there be _more_ free space now rather than less?

One part of the explanation is outlined in the <a href="#returningmemory">previous
entry</a> - <nop>CoCreate Modeling maintains its "free memory lists" internally, rather than
returning once allocated virtual memory to the operating system. But this
does not explain yet why the Windows task manager claims that <nop>CoCreate Modeling consumes
even _more_ memory after deleting the model.

If you think about it for a moment, however, it's all very simple: The
model was only _marked_ as deleted, but it is actually still in memory
- in an UNDO buffer! This way,
you can undo the deletion when you find that you actually still need
the model. Marking the model as deleted, however, adds more administrative
data to the model, which is why it is possible that more memory is required
for a model in an UNDO buffer than for the same, freshly loaded model.

If, after loading a model, you _really_ want to remove the model from
memory, simply UNDO the load operation, then proceed modelling. 
LOAD-UNDO-LOAD can be a lot more efficient (in terms of memory
and performance) than LOAD-DELETE-LOAD.

<center>
<img src="%ATTACHURL%/afterload2.jpg" alt="After loading large model" border="1" />
<br clear="all" />
Session 2: After loading a large model
</center>

<center>
<img src="%ATTACHURL%/afterundo.jpg" alt="After LOAD/UNDO" border="1" />
<br clear="all" />
Session 2: After UNDO
</center>

---++++ %GERMAN% Warum beim L&ouml;schen des Modells nicht wirklich gel&ouml;scht wird

Wer neu ist in <nop>CoCreate Modeling, den verwirrt gelegentlich die folgende Beobachtung:
Man l&auml;dt ein gro&szlig;es Modell; laut Taskmanager in Windows wird
auch so einiger Speicher daf&uuml;r verbraucht. Dann l&ouml;scht man
das Modell - und es wird sogar noch ein wenig mehr Speicher verbraucht!

Das scheint widersinnig - denn schlie&szlig;lich hat man das Modell
gerade gel&ouml;scht; sollte es dann nicht _mehr_ freien Speicher
und nicht weniger?

Ein Teil der Erkl&auml;rung ist umrissen in der Antwort auf die
<a href="#returningmemory">vorige Frage</a> - <nop>CoCreate Modeling verwaltet seine
Freispeicherlisten intern, anstatt einmal angeforderten und nach dem
L&ouml;schen von Daten wieder freigewordenen Speicher wieder ans
Betriebssystem zur&uuml;ckzugeben. Aber das erkl&auml;rt noch nicht,
warum des Taskmanager behauptet, da&szlig; <nop>CoCreate Modeling nach dem
L&ouml;schen des Modells sogar _mehr_ Speicher verbraucht. 

Wenn man einen Moment dar&uuml;ber nachdenkt, ist es alles ganz
einfach: Das Modell wird nur als gel&ouml;scht
_markiert_, aber tats&auml;chlich bleibt es immer noch im Speicher -
einem UNDO-Puffer n&auml;mlich! Auf diese Weise kann man
das L&ouml;schen r&uuml;ckg&auml;ngig machen, wenn man das
Modell doch noch einmal braucht. Das Modell als gel&ouml;scht
zu markieren, f&uuml;gt dem Modell noch etwas Verwaltungsinformation
hinzu - und so ist es m&ouml;glich, da&szlig; f&uuml;r ein Modell
im UNDO-Puffer sogar etwas mehr Speicher verbraucht wird als
f&uuml;r das gleiche, frisch geladene Modell.

Will man nach dem Laden ein Modell _wirklich_ aus dem Speicher entfernen,
l&ouml;scht man das Modell nicht, sondern macht einfach die Ladeoperation
r&uuml;ckg&auml;ngig und arbeitet dann weiter. LOAD-UNDO-LOAD kann
um einiges effizienter sein (was Speicherverbrauch und Geschwindigkeit
angeht) als LOAD-DELETE-LOAD.

-- Main.ClausBrod - 09 Dec 2004

---

#MemoryLimit
---+++ %ENGLISH% How do I use the <tt>memory-limit</tt> command?

Short answer: Don't use it at all. This will make your life a lot easier.

Long answer: The =memory-limit= command can be used to artificially limit
the maximum amount of memory which <nop>CoCreate Modeling will request from the operating
system during a session. By default, i.e. without using the =memory-limit=
command, <nop>CoCreate Modeling will simply behave like any other application: It will
request memory from the operating system on demand,
i.e. when the model grows, <nop>CoCreate Modeling will ask for more memory.

Why would anyone prefer any different behavior? There are, in fact,
some corner cases where =memory-limit= still serves or served some purpose:
   * You run <nop>CoCreate Modeling along with some other application on the same
     machine, and you want to make sure that <nop>CoCreate Modeling does not allocate
     all the RAM, forcing the other application to page data out.
   * You want to avoid paging at all, even while working in <nop>CoCreate Modeling
     only. (In that case, you'l want to specify the size of your
     machine's RAM as the =memory-limit=.)
   * On HP-UX, the operating system is actually free to terminate
     processes without warning when it runs out of swap space.
     (At least this used to be true in older versions of HP-UX.
     I haven't checked the current status in a while.) In that
     case, you would lose all your data. However, this problem
     should be avoidable by proper swap space configuration - which
     is preferable to trying to work around the issue via
     =memory-limit=. Also, the problem seems to be rare in practice.
   * In very old versions of <nop>CoCreate Modeling (in the golden days of HP-UX),
     the code established a rather low default memory limit
     because we wanted to be conservative and "nice" both to
     the operating system and to other running applications.
     In those versions, you actually _had_ to use =memory-limit=
     if you wanted to load any sizable model at all. 

The good ol' days are long gone, and <nop>CoCreate Modeling by default now grabs as 
much memory as it needs, relying on the operating system's
memory management services to deal with the above issues.
And that is actually the best solution; after all, it is the
operating system which knows best about all running applications
and can therefore make the best decisions about which pages
should be swapped out and which application needs the highest
priority.

<i>"Well, maybe using =memory-limit= doesn't buy me much, but then,
it doesn't hurt either, right?"</i> Wrong. =memory-limit= commands
tend to be added to some magic customization file and then
be forgotten. As a result, when the machine is upgraded with more
RAM, <nop>CoCreate Modeling will not be able to use it, and the user and/or sysadmin
will have to figure out why, unnecessarily spending time and
effort.

<i>"So if =memory-limit= is so pointless, why didn't CoCreate simply
remove it from the product?"</i> Good question, this one.
As a CoCreate developer, I can say:
It is actually _very_ tempting to remove the command. However,
there are those corner cases (see above), and 
enough people out there still have =memory-limit= commands buried 
deep down in their configuration files, and if we no longer
provided this function with a new release, they would run 
into Lisp errors when they start up the new code for the first
time.

But from quite a number of years of experience in supporting <nop>CoCreate Modeling
customers, I can say: Using =memory-limit= usually causes at least
as many problems as it solves.

Summary: =memory-limit=? Just say no!

---++++ %GERMAN% Wie verwende ich das Kommando <tt>memory-limit</tt>?

Kurze Antwort: Am besten gar nicht. Damit wird das Leben viel leichter.

Lange Antwort: Das Kommando =memory-limit= kann man benutzen, um die maximale
Menge von Speicher zu konfigurieren, die <nop>CoCreate Modeling innerhalb einer Sitzung vom
Betriebssystem anfordern darf. Normalerweise - also ohne das Kommando
=memory-limit= - verhält sich <nop>CoCreate Modeling wie jede andere Anwendung: Speicher
wird einfach nach Bedarf vom Betriebssystem angefordert, sprich: Wenn das
Modell wächst, holt <nop>CoCreate Modeling mehr Speicher.

Wieso sollte sich überhaupt jemand ein anderes Verhalten wünschen?
Tatsächlich gibt es ein paar Randfälle, in denen =memory-limit= 
einen Zweck erfüllt oder zumindest früher erfüllte:
   * Man möchte <nop>CoCreate Modeling gleichzeitig mit einer anderen Anwendung
     laufen lassen, aber sicherstellen, daß <nop>CoCreate Modeling nicht den gesamten
     Hauptspeicher für sich belegt und damit die andere Anwendung
     zwingt, ihren Speicher temporär auf Platte auszulagern.
   * Man möchte überhaupt jede Auslagerung auf Platte vermeiden,
     auch innerhalb von <nop>CoCreate Modeling selbst. (In diesem Fall gibt man
     die Größe des Hauptspeichers bei =memory-limit= an.)
   * Wenn der konfigurierte Swapspace zum Auslagern auf Platte
     unter HP-UX knapp wird, kann das Betriebssystem sogar
     Prozesse ohne jede Warnung und vorherige Datensicherung beenden.
     (Zumindest traf das auf ältere Versionen von HP-UX zu; ich
     habe den aktuellen Status seit einer Weile nicht mehr verfolgt.)
     In so einem Fall verliert man alle Daten. Allerdings ist dieses
     Problem vermeidbar, indem man den Swapspace ausreichend
     konfiguriert - was in jedem Fall einem Notbehelf wie
     =memory-limit= vorzuziehen ist. Das Problem scheint in der Praxis
     auch eher selten.
   * In sehr alten Versionen von <nop>CoCreate Modeling (in den guten alten
     HP-UX-Zeiten) stellte der Code automatisch einen
     sehr niedrigen Ausgangswert für =memory-limit= ein,
     weil wir sehr konservativ und besonders zurückhaltend
     gegenüber dem Betriebssystem und anderen Anwendungen
     agieren wollten. In diesen alten Versionen mußte man in
     der Tat =memory-limit= verwenden, wenn man größere
     Modelle laden wollte.

Die guten alten Zeiten sind indes lang vorüber, und <nop>CoCreate Modeling greift
sich nun einfach soviel Speicher, wie es eben braucht. Dabei
verläßt es sich auf die Dienste des Betriebssystems für die
Speicherverwaltung, um mit Situationen wie den obigen zurechtzukommen.
Und das ist auch tatsächlich die beste Lösung, denn schließlich
weiß das Betriebssystem am besten Bescheid über alle
gerade laufenden Anwendungen und ihren Speicherbedarf, und kann
daher am besten sinnvolle Entscheidungen darüber treffen, welche
Speicherbereiche auf Platte ausgelagert werden sollten und welche
Anwendung gerade die höchste Priorität genießen sollte.

<i>"Nun, vielleicht bringt mir =memory-limit= nicht viel, aber
schaden tut es doch auch nicht, oder?"</i> Falsch. <tt>memory-limit</tt>-Kommandos
verbreiten sich gerne in alle möglichen Konfigurationsdateien und
werden dann leicht vergessen. Das Ergebnis ist, daß <nop>CoCreate Modeling nach einer
Hauptspeicheraufrüstung des PCs den zusätzlichen Speicher nicht benutzen
kann, und prompt verlieren Anwender und/oder Systemverwalter
eine Menge Zeit mit dem Versuch, die Ursache des Problems zu finden.
Ich spreche aus Erfahrung.

<i>"Wenn =memory-limit= so sinnlos ist, wieso hat CoCreate es nicht
einfach aus dem Produkt entfernt?"</i> Eine gute Frage.
Als CoCreate-Entwickler kann ich sagen: Es ist in der Tat eine
_große_ Versuchung, das Kommando ersatzlos zu entfernen. Allerdings:
Es gibt noch diese Randfälle (siehe oben), auch wenn sie immer unwichtiger
geworden sind, und zudem verwenden genügend Anwender das Kommando in
Konfigurationsdateien. Würden wir das Kommando einfach in einer
neuen Version entfernen, liefen viele dieser Anwender beim ersten
Start der neuen Version in einen Lisp-Fehler.

Aus der Support-Erfahrung einiger Jahre kann ich aber sagen: Das
Kommando =memory-limit= verursacht im allgemeinen mehr Probleme, als
es in der Praxis wirklich löst.

Zusammenfassung: =memory-limit=? Just say no!

-- Main.ClausBrod
---

#HowMuchMemory
---+++ %ENGLISH% How much memory do I need in my system? How large should my paging file be?

These two questions are connected, because the paging file basically acts 
as substitute RAM in modern operating systems.

The questions which you really need to answer are:
   * How much memory in total do I need in a session?
   * How much of this memory should be RAM?

As a rough rule of thumb, the more RAM you have, the faster your system will be.
However, depending on the kind of models you work with, you may not even come
close to exhausting your memory, so adding RAM may also simply be a waste of
money.

<img src="%ATTACHURL%/taskmanager_commitcharge.png" align="right" />
The right memory size always depends on the applications running on your system
and the amount of data you handle in them. Therefore, a good way to
determine paging file size is to measure actual memory consumption and
then adjust the paging file or add RAM according to those data. Reasonable
indicators are the "Commit Charge Peak" and "Commit Charge Limit" values
in Windows Task Manager. "Commit Charge Limit" is the maximum amount of
active memory which you can have in the system; its size is roughly determined
by the amount of RAM plus the size of the paging file. The "Commit Charge Peak"
tells you the maximum amount of memory which has actually been in use since
you started the system. If the "Peak" value approaches the "Limit" value,
it is definitely time to either think about ways to reducing memory consumptions
in the applications you are running, or to add memory to the system, either
as RAM or by increasing the paging file size.

Comparing the commit charge peak against the commit charge limit helps
you answer the first question above, i.e. how much memory you need in total,
RAM and paging file combined.
In the example to the right, the commit charge peak is roughly at 1 GB,
and the limit is at 1.5 GB. So if the test session was typical for the
system, you can continue to work with that system without expanding the
paging file or adding RAM.

However, the amount of physical memory in the system is 512 MB (see
the "Physical Memory/Total" field in the dialog), while the test session
actually consumed 1 GB. This is an indication that you might be able to
gain significant performance during the test session by adding more RAM
to the system.

-- Main.ClausBrod - 26 Dec 2005

---
%COMMENT{type="below" nonotify="on"}%
to top
End of topic
Skip to action links | Back to top
You are here: CoCreateModeling > OsdmFaqMemoryManagement

r1.7 - 24 Jul 2009 - 20:58 - ClausBrod to top
CoCreateModeling
Welcome
