[omniORB] High virtual memory shown for omniNames

[Agarwal, Shelendra]

Hi Duncan,

We are using RHEL. 
Enclosed is the dump of smaps file. Recent restart resulted in virtual memory around 7.4 GB.


Thanks & Regards,

Shelendra Agarwal
Telco Big Data Analytics
Communications & Media Solutions 
HP-India
+91-9945056319

shelendra.agarwal at hp.com
Success is when you look back at your life and the memories make you smile.

-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Friday, June 26, 2015 9:34 PM
To: Agarwal, Shelendra
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] High virtual memory shown for omniNames

On Fri, 2015-06-26 at 15:19 +0000, Agarwal, Shelendra wrote:

> Total number of entries are less than 100.
> 
> Also memory is not increasing, the value of 9g is shown at the start 
> of the process itself, i.e. within few minutes of starting of omniNames.
> Non destroying of iterators by client would have resulted in gradual 
> memory increase, right?

Yes, unless you have an initial client that spectacularly leaks enormous numbers of iterators and then goes away for good, you would expect a leak to cause a gradual increase.

Can you look at the process memory map and see what's so big?  You didn't say what platform you're using, but for example on Linux you can look at /proc/<pid>/smaps to get details of all the mapped memory regions.

Cheers,

Duncan.

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


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: smaps.txt
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20150702/00a76ebb/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Proc_top.txt
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20150702/00a76ebb/attachment-0003.txt>