tracking down high memory user

Tru64 User · *nix forums addict Joined: 03 May 2002 Posts: 82

Greetings,
I have a situation where Total swap in-use space =95%
constant for over 1/2hr(Out of 2058MB), and can't
track down what is using it.

I have "monitor", "syd" and "ps" running with various
options , but no single process is even consuming more
than 2M.(+/- apart from kernel idle 56M)

Only thing i suspect is IDL.....
Not knowing its inner workings, i believe it reserves
space initially, even before actually using it, and
there are 4 such processes running...

How else could a person track down who is boggin this
system, if any, in addition to the above?

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Tru64 User · *nix forums addict Joined: 03 May 2002 Posts: 82

It seems everytime i post a question, my brain gets
challenged more and starts looking for a solution even
more rigourously. This article below seems to be
related to my situation!! Seems to be more of an IDL
problem.
I wouldn't call this is a summary for now....so as to
invite further suggestions..............

Article Title: How does IDL release Virtual Memory?
OS Platforms: MACINTOSH; UNIX; VMS; WINDOWS
IDL does free its dynamic memory when it is done with
it, and the IDL code has consistency checks that guard
against dynamic memory leaks.

DISCUSSION:

You can use the IDL command:

HELP, /MEMORY

to see how much memory IDL has allocated. However,
just because IDL frees its memory does not mean that
its virtual address space will shrink and reduce its
demand on the pagefile. In fact, it will not.

This seeming contradiction is due to the fact that IDL
uses the C language malloc(3) and free(3) functions to
allocate and free memory. When a process calls free,
the freed memory is not returned to the operating
system. It is simply placed into a free list. The next
time malloc is called, it will try to satisfy the
request from this free list before it asks the
operating system for more memory. Thus, the process
size (and demand on the pagefile) represents the high
water mark of memory usage, not its current usage.

It might be nice if free would return memory to the
operating system and reduce the amount of pagefile
currently claimed by the process, but this is not
done. To show why, consider an example in which a
process allocates two arrays, and then frees the first
one. Here is what would happen:

1) The first request causes malloc to request memory
from the operating system. The process address space
is enlarged and the request is satisfied.

2) The second request causes the address space to be
extended again.

3) The process frees the first array. free() wants to
return its memory to the operating system and shrink
the process size, but it can't because the second
array follows it in the virtual address space and this
would leave a hole.

4) At this point, free() could try to make things work
by copying the second array into the space occupied by
the first, but then it would have to search the
process address and fix up any pointers to the second
array to point at the new location. This is impossible
because there is no way to tell such pointers from
unrelated memory locations that happen to contain the
same bit pattern.

So, the dynamic memory is being freed, and it is
gathering in the free list. Since each request is
larger than the one before it, malloc makes the
process grow to satisfy it, until the pagefile quota
is hit. Arguably, malloc/free should be trying to
coalesce the free list to make large memory chunks out
of small ones, but for reasons known only to their
author, it is not.

Now of course, the question is what can you do to help
reduce this fragmentation?

To reduce fragmentation we recommend that you start
IDL, then make one massive array as large as possible,
i.e. an array which uses up most of your virtual
memory. Next set it to the integer zero. Then continue
with normal IDL usage. This will help reduce the
problem.

_Thanks

--- Tru64 User <tru64user@yahoo.com> wrote:

Google