CoCreate Modeling FAQ: Memory management
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 CoCreate Modeling 2005, another option is to
run 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 CoCreate Modeling 2006, a full 64-bit version will become available which can
use the vast amount of memory provided by 64-bit systems.
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ür Daten benutzt werden kann, auf 2 GB.
Die anderen 2 GB im 32-Bit-Adressraum werden fü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ügt sich das Betriebssystem mit 1 GB Adressraum und überläßt
die restlichen 3 GB der jeweiligen Anwendung. Damit erhält man
ein zusätzliches Gigabyte fü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.
CoCreate Modeling 2005 läuft auch unter Windows XP x64 Edition. Auf solch
einem System bekommen Anwendung Zugriff auf fast 4 GB Adreßraum,
also noch einmal 1 GB mehr als selbst im "4GT-Modus".
Ab CoCreate Modeling 2006 wird es eine volle 64-Bit-Version von CoCreate Modeling geben, die dann
auch den riesigen Adreßraum von 64-Bit-Systemen voll ausnutzen kann.
--
ClausBrod, last updated 3 December 2005
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).
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ür Daten,
sondern auch für Programmkomponenten verwendet, beispielsweise also
fü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ängt die maximale Datengröße, die man noch unterbringen
kann, auch von der Anzahl und Art der aktivierten Systemkomponenten (wie
etwa Treiber) ab.
--
ClausBrod
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.
--
ClausBrod
Warum zeigt der Windows-Taskmanager nur etwas über 3.5 GB Arbeitsspeicher an, obwohl ich 4 GB RAM installiert habe?
Einige BIOS-Versionen reservieren bestimmte Adreßbereiche unterhalb der 4-GB-Marke für sich und benutzen sie fü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ü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önnten übrigens die Hardwareregister einfach in den Speicherbereich oberhalb der 4-GB-Marke einblenden, so daß sich erst gar kein Konflikt ergibt. Allerdings wird das nicht besonders häufig getan, weil das nur funktioniert, wenn alle im System eingesetzten PCI-Karten sich an die vollständige PCI-Spezifikation halten. Die meisten PC-Systemhersteller wollen aber nicht, daß ihre Systeme abstürzen, nur weil ein Anwender eine veraltete PCI-Karte einsteckt, die sich nicht ganz an die Konventionen hät - der BIOS-Ausblendetrick ist hier das kleinere Übel.
--
MichaelMueller (translation) - 18 Jan 2005
How do I delete the UNDO buffer?
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.
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:
(undo :max_back 1)
In the same dialog, you can also set the maximum number of UNDO steps which are
kept in memory (
Limit/Steps
).
Wie löscht man den UNDO-Puffer?
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.
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:
(undo :max_back 1)
Im gleichen Dialog kann man auch die maximale Anzahl der gepufferten Zwischenschritte
einstellen (über
Grenzwert/Schritte
).
--
ClausBrod
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, 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).
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 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).
--
ClausBrod
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 CoCreate Modeling does not return
it to the operating system; rather, it assumes that it will be needed anyway by any 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.
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 CoCreate Modeling gibt ihn nicht an das Betriebssystem zurück. Stattdessen nimmt 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.
--
ClausBrod
Why deleting a model does not really delete the model
New 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!
Session 1: After loading a large model
Session 1: After deleting the model
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
previous
entry - 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 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.
Session 2: After loading a large model
Session 2: After UNDO
Warum beim Löschen des Modells nicht wirklich gelöscht wird
Wer neu ist in CoCreate Modeling, den verwirrt gelegentlich die folgende Beobachtung:
Man lädt ein großes Modell; laut Taskmanager in Windows wird
auch so einiger Speicher dafür verbraucht. Dann löscht man
das Modell - und es wird sogar noch ein wenig mehr Speicher verbraucht!
Das scheint widersinnig - denn schließlich hat man das Modell
gerade gelöscht; sollte es dann nicht
mehr freien Speicher
und nicht weniger?
Ein Teil der Erklärung ist umrissen in der Antwort auf die
vorige Frage - CoCreate Modeling verwaltet seine
Freispeicherlisten intern, anstatt einmal angeforderten und nach dem
Löschen von Daten wieder freigewordenen Speicher wieder ans
Betriebssystem zurückzugeben. Aber das erklärt noch nicht,
warum des Taskmanager behauptet, daß CoCreate Modeling nach dem
Löschen des Modells sogar
mehr Speicher verbraucht.
Wenn man einen Moment darüber nachdenkt, ist es alles ganz
einfach: Das Modell wird nur als gelöscht
markiert, aber tatsächlich bleibt es immer noch im Speicher -
einem UNDO-Puffer nämlich! Auf diese Weise kann man
das Löschen rückgängig machen, wenn man das
Modell doch noch einmal braucht. Das Modell als gelöscht
zu markieren, fügt dem Modell noch etwas Verwaltungsinformation
hinzu - und so ist es möglich, daß für ein Modell
im UNDO-Puffer sogar etwas mehr Speicher verbraucht wird als
für das gleiche, frisch geladene Modell.
Will man nach dem Laden ein Modell
wirklich aus dem Speicher entfernen,
löscht man das Modell nicht, sondern macht einfach die Ladeoperation
rückgängig und arbeitet dann weiter. LOAD-UNDO-LOAD kann
um einiges effizienter sein (was Speicherverbrauch und Geschwindigkeit
angeht) als LOAD-DELETE-LOAD.
--
ClausBrod - 09 Dec 2004
How do I use the memory-limit 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 CoCreate Modeling will request from the operating
system during a session. By default, i.e. without using the
memory-limit
command, 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, 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 CoCreate Modeling along with some other application on the same
machine, and you want to make sure that 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 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 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 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.
"Well, maybe using memory-limit
doesn't buy me much, but then,
it doesn't hurt either, right?" 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, 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.
"So if memory-limit
is so pointless, why didn't CoCreate simply
remove it from the product?" 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 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!
Wie verwende ich das Kommando memory-limit?
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 CoCreate Modeling innerhalb einer Sitzung vom
Betriebssystem anfordern darf. Normalerweise - also ohne das Kommando
memory-limit
- verhält sich CoCreate Modeling wie jede andere Anwendung: Speicher
wird einfach nach Bedarf vom Betriebssystem angefordert, sprich: Wenn das
Modell wächst, holt 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 CoCreate Modeling gleichzeitig mit einer anderen Anwendung
laufen lassen, aber sicherstellen, daß 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 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 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 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.
"Nun, vielleicht bringt mir memory-limit
nicht viel, aber
schaden tut es doch auch nicht, oder?" Falsch.
memory-limit-Kommandos
verbreiten sich gerne in alle möglichen Konfigurationsdateien und
werden dann leicht vergessen. Das Ergebnis ist, daß 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.
"Wenn memory-limit
so sinnlos ist, wieso hat CoCreate es nicht
einfach aus dem Produkt entfernt?" 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!
--
ClausBrod
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.
![](http://www.clausbrod.de/twiki/pub/CoCreateModeling/OsdmFaqMemoryManagement/taskmanager_commitcharge.png)
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.
--
ClausBrod - 26 Dec 2005