ninode help

[Steven Chen_1]

Hi,

I am in an urgent need of help to clear the mind of ninode configuration because of some db crash inspection.

I am looking at some overflow, and sar -v results in close matching up on inode-sz. I would like to know if this is significant and any need to adjust (I can adjust maxuser).

The followings are the sar result:
-----------------------------------------
#sar -v 5 5

HP-UX B.10.20 C 9000/879 08/14/01

10:08:50 text-sz ov proc-sz ov inod-sz ov file-sz ov
10:08:55 N/A N/A 197/3620 0 3894/4418 0 814/6779 0
10:09:00 N/A N/A 197/3620 0 3893/4418 0 814/6779 0
10:09:05 N/A N/A 197/3620 0 3895/4418 0 814/6779 0
10:09:10 N/A N/A 197/3620 0 3888/4418 0 814/6779 0
10:09:15 N/A N/A 198/3620 0 3894/4418 0 817/6779 0
------------------------------------

I don't find much about it. Please help.

Steven

[James R. Ferguson · Accepted solution]

Hi Steven:

The kernel parameter 'ninode' defines the maxiumum number of file inodes that can be open in memory. The number you have collected do not show an extreme shortage. If you are concerned, monitor (with 'sar') for a longer period (perhaps over 24-hours).

For more information on this parameter, see:

http://docs.hp.com/hpux/onlinedocs/os/KCparam.Ninode.html

...JRF...

[A. Clay Stephenson]

Hi Steven,

The ninode value limits the number of unique files open at one time. Your situation does not look too bad and you've had no overflows. I typically don't change NUSERS when I need to change this value, I simply clobber the formula and plug in a value. Remember, most of the formulae are simply good 'rules of thumb' but each box is unique. In any event, you need to monitor over longer periods of time but I don't think this is your boy.

Clay

[Steven Chen_1]

James,

Appreciate for the quick response. My point is idode-sz would be upto 4418, the max number, easily. If that so, do I have to adjust it?

Steven

[Carsten Krege]

ninode defines the size of the inode cache. So this value is really a performance parameter and it is NOT a problem if there is 100% usage of ninode.

Secondly, ninode is only relevant for HFS filesystems and is not that important on machines that mainly use VxFS. Nowadays on most systems only the /stand filesystem is HFS.

If you are using mainly HFS, you shouldn't increase it to values that are too big. Usually a size of 4000-10000 is sufficient, but as usual with performance issues -- it depends.

Carsten

[Steven Chen_1]

Carsten,

Thank you for the help.

I would like to know the maxssiz setting: the default size is 8,388,608. Is there any reason that we need to increase it, say the db process is about 10 - 12M vs this 8M of size?

Thanks,

Steven

[Anna Fong]

from experience, using sar to read your inodes will only tell you cached inodes. to find out number of inodes being used, get HP utility dnlcount. having the actual in-use number of inodes will help you to tune your system more accurately.

[Bill Hassell]

As mentioned, ninode is only a cache of unique files that are open or recently opened. If you have not removed the (outdated) formula for ninode, it is way too large. On 10.20 and higher, the only HFS filesystem is /stand and it typically has less than 50 files in it. This, ninode does not have to be any larger than 500 to 1000.

maxssiz is a fence to prevent runaway programs from using too much RAM. Setting it higher allows a program that is currently crashing due to stack limits to grow larger. maxssiz has nothing to with general data (ie, system calls like malloc), that is maxdsiz. And like maxdsiz, it is a protective fence, nothing more. maxdsiz defaults to about 67 megs, probably way too small, especially for large database programs like Oracle and Sybase.

[Steven Chen_1]

Bill,

Appreciate your help.

My parameters:
mazdsiz: 1,073,741,824
maxtsiz: same
maxssiz: 8,388,608 (default)

I see Oracle8 using maxssiz 83,886,080 (I am using V7 yet, and had some db crash lately).

Therefore I am trying to pin down what caused it.

Can you tell if maxssiz to be 10 time higher is good without harm?

Steven

[Trevor van Bremen]

I know that this is a *WAY TOO LATE* response, but...
I've found an interesting 'quirk' in HP-UX 10.20
When a file is *CLOSED*, the O/S does *NOT* 'free up' the used inode immediately.
Thus, the value reported by sar -v is artificially high due to all of the closed-but-still-cached inodes.
I found this out the 'HARD-WAY' after doubling, re-doubling and then again the value of NINODE only to find it was always 'growing' to the new limit.
The only way I've found to get a *TRUE* reading of the actual number of ACTIVELY USED inodes is to unmount each and every filesystem. (If you make CERTAIN that at least ONE file is 'open' on each filesystem, the umount command will FAIL, but only AFTER it has 'flushed' all the cached inodes.)
And before you ask, this umount *DOES* even seem to correctly flush the cached inodes used on the root filesystem.
Having said all that, it'd be *NICE* for sar to report ACTIVE used inodes independantly of CACHED inodes

Anthology of Microsoft:
CE, ME, NT
Hmmmm, "CEMENT"... Ironic?