From: Jaleel Ahmed (jaleelahmed@yahoo.com)
Date: Thu Jun 27 2002 - 05:00:13 EDT
Hi Admins
Thanks to all who replied. I must have done some
homework before asking this ques. It seems this
question has been already asked and answered on this
list.I am posting the most comprehensive one of all
replies.
Fred Cassirer Wrote....
Absolutely! This is a direct result of the
amount of physically memory and swap space
allocated on your system and your current
user limits settings (ulimit). To know how
much space you have run swapon -s:
bash-2.01$ swapon -s
Swap partition /dev/disk/dsk9b (default swap):
Allocated space: 50079 pages (391MB)
In-use space: 7256 pages ( 14%)
Free space: 42823 pages ( 85%)
Swap partition /dev/disk/dsk3b:
Allocated space: 150928 pages (1.15GB)
In-use space: 6952 pages ( 4%)
Free space: 143976 pages ( 95%)
Total swap allocation:
Allocated space: 201007 pages (1.53GB)
Reserved space: 57288 pages ( 28%)
In-use space: 14208 pages ( 7%)
Available space: 143719 pages ( 71%)
In this example above there are 2 swap partitions
for a total of 1.53GB.
Every time you do a malloc() (or calloc() etc) the
system will "reserve" space for your allocation, this
basically means if you malloc(10MB) then 10MB comes
off the available swap allocation. Even if you don't
touch this memory it will still be reserved. Once you
touch it (i.e., array=malloc(10MB); array[1] = 1;) the
system now has to make sure there is a physical page
to put the data in and a place on swap to write it out
to if the system needs the physical page back.
Also, realize that even if you call free() this
doesn't
mean you actually return that space to the system,
just
to your program. The way it works is that when you
call malloc() the C library in turn calls the "sbrk()"
system call which requests that your program address
space be increased by some amount. Once the address
space is increased, swap space must be reserved by the
system to insure that those pages, if used, will have
some place to live. When you do a free(), you simply
link the available address space back into a list
within your own address space, it never does an
"sbrk()" to *reduce* the space since that would
require that the virtual space at the top of your
data area to be free (you can't make holes in your
address space). This means until you exit your
program,
that space is reserved for your program. In your
example,
you probably just caused sbrks() in 1MB increments
(broken
into pages).
There are lots of papers around that describe this in
much
more detail.
Now, since you were at 129, approx 128 MB's, I suspect
instead
of a system limit, you have hit a ulimit. Ulimit is a
per-process
limit for various resources, address space being one
of them.
I believe the default is 128MB:
bash-2.01$ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) 131072
file size (blocks) unlimited
max memory size (kbytes) 495856
open files 4096
pipe size (512 bytes) 8
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 1024
virtual memory (kbytes) 4194304
Note that the data seg size is about 128MB, that
is probably what you are hitting.
man ulimit to see how to change these limits, you'll
most likely have to put this ulimit call in your
.profile and logout/login to have the limit change.
-FredC
=====
May Innocence and Joy Prevail
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:44 EDT