Folks -

I am seeing a Linux behavior that I noticed first back in 2007 or 2008
and thought it would be fixed. But apparently it's either not "wrong"
or in line for a fix since we're on 11.5.FC6.

50G box, 18 oninits, engine footprint is 26G. We noticed that
currently there is only 200MB free on the box, and the majority of the
takers are the oninits. I had talked with one of the dev team way back
when, and I believe he said that when an oninit touches the buffer
cache, the VP will grow by the size of either the cache or the pages
accessed from the cache. Is this normal? Doesn't sound good to me,
but...

Thoughts? Of course my concern is such little free memory available on
the box, and the impact it could have on overall box performance.

Thanks!
Mark Scranton
The Mark Scranton Group, LLC

Hello Mark,

Have you ever seen a Linux box with large quantity of "free" memory? I
haven't.
You should check for the "cached" value.

I don't know what you used, but check this:

Cpu(s): 1.2%us, 0.3%sy, 0.0%ni, 98.5%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 792536k total, 778496k used, 14040k free, 104716k buffers
Swap: 0k total, 0k used, 0k free, 481644k cached

About 14MB free. And 480MB "cached". This is the output of "top"
Linux "thinks" that "free" memory is a waste. So it consumes nearly all the
memory for the fs cache. But this memory has very low priority. Meaning that
it it's usefull for anything else it will be used.


For better checking you should use pmap -x(partial output):


12688: oninit
Address Kbytes RSS Dirty Mode Mapping
00122000 4 4 0 r-x-- libaio.so.1.0.1
00123000 4 4 4 rwx-- libaio.so.1.0.1
00126000 4 4 0 r-x-- [ anon ]
00127000 116 24 0 r-x-- libgcc_s-4.4.4-20100630.so.1
00144000 4 4 4 rwx-- libgcc_s-4.4.4-20100630.so.1
00145000 1556 580 0 r-x-- libc-2.12.so


08048000 13512 6000 0 r-x-- oninit
08d7a000 1128 428 312 rwx-- oninit
08e94000 628 600 600 rwx-- [ anon ]
0a0da000 132 44 44 rwx-- [ anon ]
44000000 32768 28784 27884 rwxs- [ shmid=0x150012 ]
46000000 32768 0 0 rwxs- [ shmid=0x158013 ]
48000000 32768 0 0 rwxs- [ shmid=0x160014 ]
4a000000 32768 0 0 rwxs- [ shmid=0x168015 ]
4c000000 32768 0 0 rwxs- [ shmid=0x170016 ]
4e000000 32768 0 0 rwxs- [ shmid=0x178019 ]
50000000 22980 4 4 rwxs- [ shmid=0x18001a ]
51671000 32768 28900 28860 rwxs- [ shmid=0x18801b ]
53671000 32768 32428 32368 rwxs- [ shmid=0x19001c ]
55671000 32768 19304 19084 rwxs- [ shmid=0x19801d ]
57671000 32768 0 0 rwxs- [ shmid=0x1a001e ]
59671000 18928 0 0 rwxs- [ shmid=0x1a801f ]
bff55000 280 84 84 rwx-- [ stack ]
-------- ------- ------- ------- -------
total kB 391628 - - -

The majority of the memory should be the shmid lines. And these should
appear in every oninit and naturally cannot be added together.

So, in short, I believe you're seeing the effects of two things:

1- The way Linux handles memory (I lost count of the times customers
complain that their machines don't have enough "free" memory)
2- The way shared memory segments are reported in some tools (ps aux, top
etc.) and this is not specific to Linux. pmap is a great help to check the
reality

HTH
Regards.



On Sat, Jan 22, 2011 at 9:43 PM, Mark Scranton <mark (AT) markscranton (DOT) com>wrote:



--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...