Hi Team,

We found the C function call - free() in HPUX won't release the memory ( in
swap/virtual memory) and I was told it is normal. I would like to know any
solution to this. Thanks,

Ma

"Ma, Derek" <matehsiang@hotmail.com> writes:

> We found the C function call - free() in HPUX won't release the memory ( in
> swap/virtual memory) and I was told it is normal.

That is correct: most free() implementations do not release memory
back to the OS. One exception is Glibc (and Doug Lea's dlmalloc it
is based on).

> I would like to know any solution to this.

Why do you think it is a problem?

Cheers,

PS: I know under what conditions this could be a problem, but I
wonder if OP understands that and has in fact these conditions.
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Ma, Derek <matehsiang@hotmail.com> wrote:
> We found the C function call - free() in HPUX won't release the
> memory ( in swap/virtual memory) and I was told it is normal. I
> would like to know any solution to this.

One solution would be to not write an application that allocates great
gobs of memory for a one-shot deal, then free()'s it and continues to
run. The expectation of the memory allocator is that the memory usage
of an application is not massively "spikey."

You could of course, terminate the process, at which point all memory
and swap allocated to the process is fully free'd.

rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Hi Paul,

The process ( accessing SAP R3 ) has already written and can't be changed.
Sometimes it will dump more than 100K records from SAP and then it will
occupy more than 1GB memory ( real+swap ). As we know, the swap is still
limited ( ie may be 2 or 3 times of real memory ), how do we face such
problem? I mean if the SAP process hold all swap memory but not release?
Increasing the swap size is the only solution to this *issue*?

Thank you,

Ma


"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> ???
news:m3hdc2prtx.fsf@somewhere.in.california.localh ost ???...
> "Ma, Derek" <matehsiang@hotmail.com> writes:
>
> > We found the C function call - free() in HPUX won't release the memory
( in
> > swap/virtual memory) and I was told it is normal.
>
> That is correct: most free() implementations do not release memory
> back to the OS. One exception is Glibc (and Doug Lea's dlmalloc it
> is based on).
>
> > I would like to know any solution to this.
>
> Why do you think it is a problem?
>
> Cheers,
>
> PS: I know under what conditions this could be a problem, but I
> wonder if OP understands that and has in fact these conditions.
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

"Ma, Derek" <matehsiang@hotmail.com> writes:

> The process ( accessing SAP R3 ) has already written and can't be changed.

Please do not top-post:
http://catb.org/~esr/jargon/html/T/top-post.html

If the process can't be changed, then you effectively have no means
to deal with its memory requirements, short of killing/restarting
it on a regular basis.

> Sometimes it will dump more than 100K records from SAP and then it will
> occupy more than 1GB memory ( real+swap ).

Does it exit after it has "dumped records", or does it hang around?
If the former, you don't have a problem.

> how do we face such problem?
> I mean if the SAP process hold all swap memory but not release?

We bitch to SAP consultants, until they fix it

> Increasing the swap size is the only solution to this *issue*?

That, and restarting the process periodically.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Hi Paul,

Thanks. Which one do you prefer ( ie increasing SWAP or restart the process
periodically ) ? Thanks,

Derek

"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> ???
news:m33bnlq5xx.fsf@somewhere.in.california.localh ost ???...
> "Ma, Derek" <matehsiang@hotmail.com> writes:
>
> > The process ( accessing SAP R3 ) has already written and can't be
changed.
>
> Please do not top-post:
> http://catb.org/~esr/jargon/html/T/top-post.html
>
> If the process can't be changed, then you effectively have no means
> to deal with its memory requirements, short of killing/restarting
> it on a regular basis.
>
> > Sometimes it will dump more than 100K records from SAP and then it will
> > occupy more than 1GB memory ( real+swap ).
>
> Does it exit after it has "dumped records", or does it hang around?
> If the former, you don't have a problem.
>
> > how do we face such problem?
> > I mean if the SAP process hold all swap memory but not release?
>
> We bitch to SAP consultants, until they fix it
>
> > Increasing the swap size is the only solution to this *issue*?
>
> That, and restarting the process periodically.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

"Ma, Derek" <matehsiang@hotmail.com> writes:

> Thanks. Which one do you prefer

I prefer helping people who listen to advice, and ignore those
who don't. You are now in my kill-file.

Good luck with your problem.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.