On all operating systems D3PLOT has to co-exist with other processes, and
when its consumption of system resources is small this is not an issue. However
as you process larger models you will approach the capacity of you machine,
and control of memory use will become important. There are two key issues:
|
|
-
As this approaches 80 - 90% of the physical memory size of the
machine it will become necessary for the operating system to use
"virtual" memory. This is because other processes need to maintain
a presence in memory and, to make space, some of the D3PLOT process
will need to be paged ("swapped out") onto virtual memory on disk.
-
Paging, when some of the process pages
(1)
are swapped onto disk, has a major impact on speed because of
the delay in reading them back into memory again when needed.
The symptoms are a much slower response, accompanied by the disk
chattering away. However the process will continue to run, albeit
more slowly.
|
|
|
|
-
Operating systems maintain "swap space", which is an area of disk
set aside for pages of memory that have been "paged" out of physical
memory. This is known as "virtual" memory, and is usually up to 3 times
the size of physical memory, but can be any value set by the system
administrator.
-
Virtual memory allows computers to handle the situation where the
sum total of memory space requested by all processes is greater than
the physical memory available. They do this by swapping unneeded pages
of memory onto disk, then swapping them back into memory (evicting other
pages to make space) when they are required again. A "page fault" occurs
when an executing process requires a page that is not resident in memory
and has to be read in from disk.
-
Parking dormant processes on disk has no impact on the performance
of running ones. But it will be obvious that if a running process makes
excessive use of virtual memory it will generate a lot of page faults,
which will slow down its performance.
-
If virtual memory space is all used up then the operating system will
start to kill processes, and the machine may crash if essential services
cannot obtain the memory they need!
|
|
The
MEMORY
panel itself is shown here.
This section shows Physical memory statistics.
The machine has 253MB of memory. D3PLOT is using 11.5%. The alarm has
been set at 80%.
This section shows Virtual memory statistic s.
The machine has 2047MB of swap space, of which 7.4% is in use, alarm set
at 90%.
This section shows the results database memory usage summary.
Finally this section allows you to alter the graphics display mode. (Some
modes use more memory than others.)
|
|
|
The two usage bars (%age physical memory used by D3PLOT , and
total
%age virtual memory usage over the whole machine) are replicated in miniature
on the
MEM
button on the front panel for
easy reference. So long as they both stay in the green you don't have
a problem, and even light orange (60%) is probably OK. More than that
and you may need to take action - see below.
|
Both physical and virtual limits have alarm values set at 80 and 90% respectively.
If an alarm limit is reached D3PLOT stops what it is doing and maps an alarm
panel explaining the problem. You can change alarm values at any time, and set
them to large values (eg 1000%) if you want to ignore them altogether.
This summarises the settings of the results database, and the
VIEW...
button takes you to the main database manager.
Allows you to select an animation mode as described in
DISPLAY_MODE The display mode used for graphics
. (The same as
ANIM > DISPLAY_MODE
).
Some modes use more memory than others.
-
If virtual memory is short see if there is anything else running on
the machine that you can shut down (remember the virtual memory bar
is for the whole machine, not just D3PLOT).
-
This usually happens when building animations. See if you can cut
down what is displayed to save memory:
-
Display alternate states instead of every state;
-
Use a simpler display mode (eg flat shading, not smooth;
SI
not
CT
)
-
Turn off unneeded display items (node symbols, labels)
-
If the results database is very full use its
OPTIONS
> EMPTY_xxx
commands to release some space, and reduce the
soft and hard %ages. (This may not release space back to the operating
system, but the space freed can be re-used internally.)
-
Use a less expensive display mode:
-
DIRECT
uses no display memory, but
is slow.
-
VECTOR
is a reasonable compromise
(the default)
-
OBJECT
use a lot of display
memory in the server process
|
In extreme cases you may find that none of the above free enough memory and
you have to exit and start again with "cheaper" (in terms of memory) settings.
If this happens:
-
Before reading in a model use the
MEMORY
button on the filename panel to select the display mode and database
soft/hard %ages.
-
Then define a filename and read in the model. The new settings will
be used ab initio and will result in lower memory usage.
|
Another problem that can occur following
OBJECT
mode animations is that the graphics
server process (owned by the operating system) may grow to a very large size
and cause problems. This is because some operating systems don't allow memory
to be released once it has been allocated.
It will be necessary to shut down and restart this process in the following
way:
-
Logout from the display.
-
At the "login" prompt choose the "no windows" or "console" mode (usually
under an "options" menu). This will shut down the X server completely.
-
Most "Common Desktop Environment" (CDE) window managers will automatically
restart the X server after a short delay.
|
|
If, despite everything you do, your model is too big to fit into your
machine you may still be able to deal with it by splitting the job over
two machines. The "client" machine runs the D3PLOT process, and the remote
"server" displays the graphics.
-
On the client set the
DISPLAY
environment variable to point to the display on the server machine.
(Eg
setenv DISPLAY remote_name:0
)
-
Use
OBJECT
mode this results in the graphics data being displayed in the
server, not the client.
-
The initial transfer of graphics data from client to server
will be slow, since it has to go down a network. But subsequent
animation, performed locally on the server, will be fast.
-
Keep and eye on the memory usage on the server: D3PLOT does
not monitor this for you. (It only "knows" about the client machine.)
|
|
DISPLAY_MODE The display mode used for graphics
explains how
animation works in client/server mode.
If D3PLOT Will Not Open a Window on Your Display
and
Client/Server Graphics Using OpenGL
give more
information on specifying network addresses.
1.
A "page" of memory is a conveniently sized quantum, typically
4kB: this varies between systems.