Pawel (privately) wrote:
> Hi,
>
> This is definetely not easy subject - that is why I am coming back.
>
> I was complaining on memory leaks, but there may not be any memory leaks 
> :)
>   
Nope. It would be that your query is just working on a data set that is 
too big. Changing to SELECT READNEXT and forgetting about sorting would 
cure that.
> Can anyone explain me what "Free" and "Used" means in below output:
>   
Yes ;-)
>  858    16         rx0044       3981556  Port 858 details at 06:08:08 06 
> FEB 2009
>                                          Thread type Normal
>                                          Usage Count 72 from 100K
>                                          Application Open Files 14654 , 
> Actual O/S Open Files 181
>                                          Memory: Free 43,755,392   Used 
> 2,095,398,288
>                                          READ's 192042 , WRITE's 14167
>                                          DELETE's 1315 , CLEARFILE's 0
>                                          EXECUTE's 3 , INPUT's 0
>                                          OPEN's 14676
>                                     ---- jsh -Jb -c tSA 60
>                                          Program performing EXECUTE/PERFORM 
> at jsh.b,59
>                                     ---- tSA 60
>                                          Program running normally at 
> F.WRITE,72
>
> I am asking because if process will free say 1,8 GB situation will not 
> change from OS level. Memory once allocated (disregarding from "Free" / 
> "Used" jBASE indicator) seems not to be given to other processes. Why?
>   
This is the info that is coming back from the mallinfo() system call. It 
is telling you that the heap size contains 43,755,392 bytes that have 
been placed back into the allocation pool but coudl not be released back 
to the system. It is also telling you about a huge amount of space that 
is in use. This only tells you that it is in use though, not that it was 
leaked. We know that it has not been free()d yet, but that might be 
normal for a huge SSELECT.

There is a lot more to memory management than I could explain here, but 
you need to think of it more in terms of address space than some 
physical quantity that is doled out or given back.
> In this way it may happen that multiple processes had their own "peaks" 
> in processing and each one allocated (but is not longer using) 1 GB. 
> Then memory runs out.
>
> So why "Free" is not free? I am completely lost :(
>   
The free table is giving you the amount of free bytes, but it is not 
telling you about their order and structure.  That could be 43,755,392 
blocks all with one byte each, which means if you ask for 2 bytes, then 
the system has to tell you it is out of memory. It won't all be 1 byte 
blocks of course as the minimum allocation is probably 16 bytes or more, 
but unless there is a contiguous block available of the size you need 
then the computer say naahhh!

Change to the watson alocator and see if it makes a differnce, but noce 
your oprocess is using 2,095,398,288 then it really is using that. We 
cannot determine if it needs that to process the data or it is not 
freeing something it should be. Only proper analysis tools can tell you 
that.

If you want to know more about all this stuff, try:

http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/sys_mem_alloc.htm

Jim

--~--~---------~--~----~------------~-------~--~----~
Please read the posting guidelines at: 
http://groups.google.com/group/jBASE/web/Posting%20Guidelines

IMPORTANT: Type T24: at the start of the subject line for questions specific to 
Globus/T24

To post, send email to [email protected]
To unsubscribe, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to