The original question:
I have a problem with a large process (a Fortran77/90 program) running
on a Digital Alphastation under UNIX V4.0B. The total amount of RAM is
128 Mbytes.
When I run the process there is a large amount of thrashing to disk.
If I use the command "ps v" to examine what is happening, it indicates
that the process is using only 64 % of memory ... etc.
-------------------------
Thanks to the following people for their replies:
Alan,
Dr. Thomas P. Blinn
Toni Harbaugh-Blackford,
Tim Janes
Gyula Szokoly
and Jean Dubois.
It appears as if my process is using all the available memory.
The system has 128 Mbytes of RAM to start with, however, during the boot
process a message is display indicating that only 110.93 Mbytes is
available. i.e. 86.7% is the upper limit on the memory available.
While my process is running, there are a whole bunch of smaller processes
(mostly owned by root) running in the background. Using the output from
"ps vgx" it seems as if these consume a further 9.4% of memory in my
case. The largest of these processes are "kernel idle" (4.8%),
"/usr/bin/X11/X" (1.2%), and "dtfile" (0.8%).
With the default kernel, the UBC (used for I/O) can use between 10-100%
of physical memory. Assuming it uses around 12%, this only leaves a total
of 65% of RAM available for the Fortran code.
The only system tuning that appears to help in my case is to modify the
UBC parameters in the Virtual Memory Subsystem Attributes (i.e. "vm:").
The Kernel Tuner (dxkerneltuner) is a nice way to do this. I've been able
to improve the use of RAM by about 5%. Other than that the size of the
process needs to be reduced, or more RAM added.
I should have mentioned earlier that I issue the command "limit datasize
unlimited" before I run the process. Without this the program will not
run at all, indicating "failed to set heap start". Also, the program does
perform conventional I/O to disk, writing raw data (arrays) in a
sequential unformatted/binary mode, however, this should only occur every
5-10 minutes or so.
I've attached below a reply from Alan where some of the reasons for the
operating system consuming so much memory are explained.
Thanks again for all the replies,
Craig.
----------------------------
Of the starting memory, the kernel uses a minimum of
the sum of its text, initalized data and uninitialized
data sizes:
% size /vmunix
text data bss dec hex
2620528 414752 270048 3305328 326f70
around 3 MB. Then it starts allocating table space; proc,
file, text, vnode, etc. All of these tables are allocated
dynamically as the kernel runs. Some of these may not even
be tables anymore and are allocated dynamically as the system
runs. Then a whole bunch of space gets taken for the kernel
memory allocator so that drivers which need dynamic memory
can easily get it. Then come the loadable drivers that allocate
what they need when they start. Have a look at the output of
"vmstat -M".
UFS wants to use a minimum of 3% of physical memory for buffer
cache headers. The buffers themselves come from free memory
as needed up to ubc-maxperent, which defaults to 100%.
Also, I think the kernel memory allocator is dynamic as well
and may expand as drivers need more memory.
So, 18 MB of memory for the running kernel isn't too surprising
and it probably gets bigger by the time it forks off init and
other base system processes.
As for your process, running ps(1) will affect the amount of
memory your process has because ps will need some and that
may force your program to have some paged away from it. An
application of Heisenburg I suppose (or was it Mach). So,
see what processes you can trim and then pick up the guide
to real time programming. It may have something that will
let you lock a fair amount of memory for your private use.
It will put a dent in the rest of the system performance, but
all you're trying to do is run memory hungry program, that's
the tradeoff.
Received on Fri May 09 1997 - 10:57:39 NZST