free() function call don't work - HP UX

This is a discussion on free() function call don't work - HP UX ; 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...

+ Reply to Thread
Results 1 to 7 of 7

Thread: free() function call don't work

  1. free() function call don't work

    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



  2. Re: free() function call don't work

    "Ma, Derek" 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.

  3. Re: free() function call don't work

    Ma, Derek 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...

  4. Re: free() function call don't work

    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" ???
    news:m3hdc2prtx.fsf@somewhere.in.california.localh ost ???...
    > "Ma, Derek" 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.




  5. Re: free() function call don't work

    "Ma, Derek" 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.

  6. Re: free() function call don't work

    Hi Paul,

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

    Derek

    "Paul Pluzhnikov" ???
    news:m33bnlq5xx.fsf@somewhere.in.california.localh ost ???...
    > "Ma, Derek" 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.




  7. Re: free() function call don't work

    "Ma, Derek" 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.

+ Reply to Thread