I am using redhat 8 (kernel 2.4.18 xsmp) on an old cluster (2CPU
each nodes, 2GB RAM, 4GB swap and NFS). Recently I had encountered a
problem about virtual memory. A parallel program terminated with
Segmentation fault (Signal 11). While using gdb to debug, it turns out
that the exact error message is "virtual memory exhausted". The
program was compiled using Intel compiler 8.1. I had compiled it on a
CentOS 5.2(2GB RAM, 4GB swap) with Intel compiler 10.1, and the
program runs well. It requires about 200 MB RAM, as watching by 'top'
command. And during its running, 'kswapd' demon would be awakened.
While running this program in the cluster, it always dies when the
RSS reach about 150MB with a signal 11 (or using gdb with 'virtual
memory exhaust'). During its running, the system has more than 1.2GB
free RAM, 4GB free swap and the 'kswapd' keeps in 'SW' status. I had
checked the /etc/security/limits.conf file, which sets no limit. And I
had tried bash and csh with the stack size, virtual memory, max memory
size, file size unlimited. I had also doubled the max_map_count in
/proc/sys/vm/. But all of the above actions had no effect on the
program, it still died when it occupies about 150MB RAM and reports
Sig 11 (in gdb 'VM exhauxted'). I had manually set some limits on the
virtual memory (such as 'virtual memory' limit in the shell or
max_map_count), the program dies with some different message like
'forrtl: not enough virtual memory ...."
Are there any other limits that restrain a process from getting
more virtual memory? I had tried to speed up the fresh frequency of
'kswapd', but I can't find 'freepages' file in my /proc/sys/vm
directory. It is said that this key had been removed since kernel 2.4,
so how can I increase the fresh frequency of 'kswapd'? Besides, are
there any special rules in virtual memory control of SMP kernel?
Thanks for reading my letters. I hope to get some helps.
First, do not confuse RSS with VSZ. Apparently your program tries to
allocate too much virtual memory, which does not mean that it really
uses it. For instance, it may allocate 1 GB but only use 150 MB. Then
the memory is not really allocated by the system as long as it is not
touched (otherwise you would go out buy RAM sticks every time you
start firefox). I don't now what's in RH 2.4.18, but it is likely
that this kernel does not allow a process to allocate more than one
gig, thus causing trouble to your process. 2.4.18 is quite old, and
a patched RH one makes it even harder to compare to recent things.
But you might be interested in trying to apply one patch which was
lying around at that time in 2.4-aa kernels, to change the memory
split to allow 2G for kernel and as much for user. Look for
You will not change the process' virtual memory size because it's
simply defined by the difference between the top and the bottom of
its address space. So only the process may change it using sbrk()
I hope this helps you a bit,