[omniORB] High heap memory consumption due to omni layer memory management [OMNI ORB version 4.1.4]

Sahoo, Dibendu Kumar dibendu.kumar-sahoo at hp.com
Wed Oct 29 10:49:14 GMT 2014


Hi Duncan,

     Unfortunately we are heading to a situation, where the expected behavior mentioned by you ("system memory allocators" allocates large blocks of memory from the OS, and then keep hold of it without giving it back to the OS ) is certainly ending up consuming huge heap memory. Then it does not get released un less we re-start the application. 

Between, I have done more analysis/search and  explored more about "system memory allocator".

The mechanism of memory allocation and de-allocation (so called " system memory allocator") is improvised version ( in order to avoid the overhead of  traditional malloc() , free() being used every now and then) . Instead it allocates memory in chunks and pools (say 256KB as chunk size and 4KB each as pool size). The reuse of memory is based on some defined algorithm (of course different for different memory allocator mechanism). However when it comes to release of memory back to Operating System, many memory allocator do not have real optimized algorithm resulting into the stated problem ( keep hold of huge memory unless application re-starts). You can find following link as reference where the current memory allocator functionality , problematic behavior ( and design change suggestions to address it) is exactly described. Here the reference is "Python" which is using exactly the same memory allocator we are discussing about. 


http://www.evanjones.ca/memoryallocator/


This leads to the finding that OMNI as well is using this specific type of memory allocator mechanism. Can you please let us know as  how to get rid of this problem ? Can we de-couple our self from this specific type of "memory allocator" ? This specific type of memory allocator becomes an overhead when it is used for applications which requires/uses memory un-evenly. Like today's usage is 10 bytes and tomorrow's usage is  10GB.  

The standard expectation form any application is : take memory while in use but return back /release to OS as soon as you finish the work.

Please share your thoughts on this. We have to really address the problem ,since the current behavior is not accepted.

Thanks a lot for your co-operation , understanding and valuable inputs.

Thanks & Regards
Dibendu


-----Original Message-----
From: Sahoo, Dibendu Kumar 
Sent: Tuesday, August 05, 2014 4:03 PM
To: Duncan Grisby; Agarwal, Shelendra
Cc: omniorb-list at omniorb-support.com; Vijayan, Pratheesh T (Enterprise Services - CMS); Thondapu, Chennarao; Rani, Chandrika M; Bhatia, Neeraj; Sahoo, Dibendu Kumar
Subject: RE: [omniORB] High heap memory consumption due to omni layer memory management [OMNI ORB version 4.1.4]

Hi Duncan/All,

    Could you please let us know on " platform configuration parameters options for memory allocator" . It would really help us. If we can bring back the memory acquired by OS by means of some configuration change , then it would be really great. We are seeing that memory is acquired/consumed ( same way as explained by you ) but it is never going down/released. 

Thanks in advance.

Regards
Dibendu

-----Original Message-----
From: Sahoo, Dibendu Kumar
Sent: Friday, July 25, 2014 9:50 AM
To: 'Duncan Grisby'; Agarwal, Shelendra
Cc: omniorb-list at omniorb-support.com; Vijayan, Pratheesh T (Enterprise Services - CMS); Thondapu, Chennarao; Rani, Chandrika M; Sahoo, Dibendu Kumar; Bhatia, Neeraj
Subject: RE: [omniORB] High heap memory consumption due to omni layer memory management [OMNI ORB version 4.1.4]

Hi Duncan ,

 Thanks a lot for your response. 

You mentioned :

>>They allocate large blocks of memory from the OS, and then keep hold of it without giving it back to the OS .

We are in HP-UX Itanium platform. What we are seeing is : memory is being acquired by the thread during the business action. But it does not get released even if the operation is finished. Or in other words, for filling say around 10000 records, memory from heap has been acquired by omni ORB ,but once those records are rendered/dispatched to UI, that memory already acquired during this operation is not coming down. This behavior is little surprising. We were thinking that memory usage will be more during the operation and will come down after it and again go up for the subsequent iterations/operations. 


You have mentioned about some platform configuration parameters options for memory allocator. Could you please let us know what are they. It would be really helpful for us.


Thanks & regards
Dibendu

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org]
Sent: Friday, July 18, 2014 8:09 PM
To: Agarwal, Shelendra
Cc: omniorb-list at omniorb-support.com; Vijayan, Pratheesh T (Enterprise Services - CMS); Thondapu, Chennarao; Sahoo, Dibendu Kumar; Rani, Chandrika M
Subject: Re: [omniORB] High heap memory consumption due to omni layer memory management [OMNI ORB version 4.1.4]

On Thu, 2014-07-17 at 11:29 +0000, Agarwal, Shelendra wrote:

[...]
> The leak detector tools are clearly telling that, there are no leaks 
> in our application or in omni. With this we are getting an impression 
> that it’s a different kind of memory management technique. But then 
> the concern is, for each serving thread if it allocates good amount of 
> heap memory and keep with it as working area/memory then we are 
> running out of resources.

omniORB does not do anything special with memory management. It just uses new and delete.

What you describe is actually a common way for system memory allocators to behave. They allocate large blocks of memory from the OS, and then keep hold of it without giving it back to the OS. You don't say what platform your server is using, but you may find there are some platform configuration options that affect the bahaviour of the memory allocator.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --




More information about the omniORB-list mailing list