hmm,

free() doesn't do sbrk() with a negative to reduce the process space. So yes
the space stays allocated.

Anjo.

----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Monday, February 03, 2003 7:58 AM


> Hi
>
> SITUATION - On a production APP Server having about 4000 Concurrent
application processes ,
> the memory allocated does NOT seem to be getting freed even though the
application program is issuing the respective call to Free the memory .
>
> Qs Any /etc/system parameters , OS patches which should help ?
>
> Qs Is our approach of using the pmap command Correct ?
> else what Command to find the "Private" memory taken up by a process would
be advisable ?
>
> Qs How to find the Total Amount of Swap Consumed  ?
> [ We probably do NOT know how to interpret the vmstat output Correctly ,
> top/swap -s commands show an output Differing greatly from df -k output
for /tmp filesystem ]
>
> Qs Any Body has encountered such as situation before ?
>
>
> Configuration -
> Solaris 2.8
> Patch - Generic 108528-16 patch
> Machine SF15K
> CPUs = 36
> RAM  = 96 GB
>
>
> We created a Small Sample C program which allocates & FREEs memory but
found that even after
> FREEing , the memory does NOT show as Freed in the pmap output . Is the
following approach correct ?
>
> DETAILS :-
>
> @@@@@@@@@@@@@@@@@ SAMPLE C PROGRAM @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> #include <stdio.h>
> main()
> {
>         char *abc = NULL ;
>         int     i = 0 ;
>         for (i = 1; i < 10; i++){
>                 printf("allocating [%d] bytes\n", 10*1024*(i+1));
>                 abc = (char *)malloc(10*1024*(i+1));
>                 memset(abc, '\0', 10*1024*(i+1));
>                 getchar();
>
>                 free(abc);
>                 printf("Freeing [%d]\n", i);
>                 getchar();
>         }
>         exit() ;
> }
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>
> RUN Output :-
>
> STEP 1 - allocating [20480] bytes
>
> pmap -x <PID of Above program process>
>
>  Address   Kbytes Resident Shared Private Permissions       Mapped File
> 00010000       8       8       8       - read/exec         a.out
> 00020000       8       8       -       8 read/write/exec   a.out
> 00022000      24      24       -      24 read/write/exec     [ heap ]
> FF280000     688     688     688       - read/exec         libc.so.1
> FF33C000      32      32       -      32 read/write/exec   libc.so.1
> FF370000      16      16      16       - read/exec         libc_psr.so.1
> FF390000       8       8       8       - read/exec         libdl.so.1
> FF3A0000       8       8       -       8 read/write/exec     [ anon ]
> FF3B0000     152     152     152       - read/exec         ld.so.1
> FF3E6000       8       8       -       8 read/write/exec   ld.so.1
> FFBEC000      16      16       -      16 read/write/exec     [ stack ]
> --------  ------  ------  ------  ------
> total Kb     968     968     872      96
>
> THE "Private" memory allocated by the [ heap ] is 24 K
>
> STEP 2 - Freeing the memory allocated in the above Step
>
> Freeing [1]
>
> pmap -x <PID of Above program process>
>
>  Address   Kbytes Resident Shared Private Permissions       Mapped File
> 00022000      24      24       -      24 read/write/exec     [ heap ]
>
> RESULT - THE "Private" memory allocated previously does NOT get Freed &
> [ heap ] continues to be 24 K
>
> STEP 3 -
> allocating [30720] bytes
>
> pmap -x <PID of Above Program process>
>
>  Address   Kbytes Resident Shared Private Permissions       Mapped File
> 00022000      32      32       -      32 read/write/exec     [ heap ]
>
> STEP 4 - Freeing the memory allocated in the above Step
> Freeing [2]
>
> pmap -x <PID of Above program process>
>
>  Address   Kbytes Resident Shared Private Permissions       Mapped File
> 00022000      32      32       -      32 read/write/exec     [ heap ]
>
> RESULT - THE "Private" memory allocated previously in Step 3 does NOT get
Freed &
> [ heap ] continues to be 32 K
>
> Thanks
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: VIVEK_SHARMA
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
> San Diego, California        -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Anjo Kolk
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to