[omniORB] High virtual memory shown for omniNames
Duncan Grisby
duncan at grisby.org
Thu Jul 2 14:08:18 BST 2015
On Thu, 2015-07-02 at 04:51 +0000, Agarwal, Shelendra wrote:
> Enclosed is the dump of smaps file. Recent restart resulted in virtual memory around 7.4 GB.
What you are seeing is just an artefact of the way Linux manages virtual
address space and threads. If you look in the smaps file, you'll see 114
pairs of entries that look like this:
7ffa80000000-7ffa80021000 rw-p 00000000 00:00 0
Size: 132 kB
Rss: 24 kB
Pss: 24 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 24 kB
Referenced: 24 kB
Anonymous: 24 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
7ffa80021000-7ffa84000000 ---p 00000000 00:00 0
Size: 65404 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Each one of those is the virtual address space allocated for a thread
stack. Notice that the first small bit is read-write and only slightly
used, and the big 65404 kB bit is totally unused, and not readable or
writable. It's allocated address space that's ready for the stack to
grow into, but it's not allocated memory at all. If the stack was to
grow out of the small segment, it would reach the big segment and get a
page fault due to the lack of read/write permission, at which point the
OS would map some real memory at that location and modify the address
space map appropriately.
There must be 114 threads in omniNames, or at least there have been at
some point. That's quite reasonable if there are lots of concurrent
clients.
top and ps are showing you the virtual size of the defined address
space, and 65404 * 114 is 7456056, which accounts for almost all the
virtual size. It's not using any real RAM or swap, and it's not going
to, so it's nothing to worry about.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
More information about the omniORB-list
mailing list