sar displays "0" for cached inodes

[Dennis J Robinson]

This is on my Vclass servers running 11.0:

HP-UX hpguru B.11.00 U 9000/800 01/23/02

00:00:00 text-sz ov proc-sz ov inod-sz ov file-sz ov
00:10:00 N/A N/A 361/4000 0 0/20000 0 2194/40010 0
00:20:00 N/A N/A 356/4000 0 0/20000 0 2123/40010 0
00:30:00 N/A N/A 357/4000 0 0/20000 0 2082/40010 0
00:40:00 N/A N/A 348/4000 0 0/20000 0 2067/40010 0
00:50:00 N/A N/A 346/4000 0 0/20000 0 2063/40010 0

ninode in kernel is set to 20000, and nfile at 40000. What is up with this output, on N class boxes with same parameters I don't have this issue.

[Steve Steel]

Hi

This is why

While using sar -v 5 5 to periodically check the threshold of the
nfile and nproc parameters, it is not uncommon to see the inode-sz
column showing 100% utilization. When this occurs with the file-sz or
the proc-sz columns this indicates that the limits of nfile and
nproc have been reached. In those cases system problems are encountered.
This does not seem to be the case when inode-sz shows 100% utilization.
Is this measuring the threshold for ninode? If so, does seeing this
column "maxed out" indicate a problem with the system? Below is a sample output
from sar -v 5 5:

09:14:29 text-sz ov proc-sz ov inod-sz ov file-sz ov
09:14:34 N/A N/A 345/1500 0 10000/10000 0 4014/28010 0
09:14:39 N/A N/A 343/1500 0 10000/10000 0 4012/28010 0
09:14:44 N/A N/A 343/1500 0 10000/10000 0 4012/28010 0
09:14:49 N/A N/A 343/1500 0 10000/10000 0 4013/28010 0
09:14:54 N/A N/A 343/1500 0 10000/10000 0 4015/28010 0


RESOLUTION
It is not uncommon to see what appears to be a ???maxed out??? value for
inode-sz column. The number to the left of the / is the number of
inodes open in the inode table cache and the number on the right is the maximum
number of inodes that can be open in the inode table cache determined from the
value of ninode in the running kernel. The HP-UX OS actually tries to
keep this value at the maximum for performance reasons. As more inodes are
cached, the inode retrievals (on average) will be faster. Seeing this value in
inode-sz to be equal to your ninode value is not something to be overly
concerned about. The system will maintain the cache and add/delete inode
entries as needed. This is unlike the proc-sz and file-sz columns
from the sar output which show hard limits. When these limits are
reached, new processes cannot not be started or additional files cannot be
opened. The inode-sz column refers to a cached table, and it is expected
that having this value ???maxed out??? should not prevent users on the system from
extracting inode information from inodes not available in the cache. That
being said, tuning ninode to be a smaller or larger value to allow for a
smaller or larger inode cache table can have a neglibile effect on performance
in some environments.


Steve Steel

[Dennis J Robinson]

Look at the inode output again. It does not show "maxed" out inode table. It shows that there are "0" cached inodes. It only does this on my Vclass servers and not the N's.

Was there a problematic sar, or a patch that mucked with the kernel counters for inodes?

Here goes sar -v 5 5 output: (notice the "0" in number of cached inodes.

hpguru:/home/hpguru> sar -v 5 5

HP-UX hpguru B.11.00 U 9000/800 01/23/02

07:57:59 text-sz ov proc-sz ov inod-sz ov file-sz ov
07:58:04 N/A N/A 536/4000 0 0/20000 0 5779/40010 0
07:58:09 N/A N/A 534/4000 0 0/20000 0 5776/40010 0
07:58:14 N/A N/A 535/4000 0 0/20000 0 5778/40010 0
07:58:19 N/A N/A 535/4000 0 0/20000 0 5740/40010 0
07:58:24 N/A N/A 535/4000 0 0/20000 0 5690/40010 0

[Steve Steel · Accepted solution]

Hi


Sorry . My fault.

Problem: 11.0 sar -v and glance show ninode usage as 0 .

HP-UX lancelot B.11.00 C 9000/800 02/22/01

18:51:28 text-sz ov proc-sz ov inod-sz ov file-sz ov
N/A N/A 171/4116 0 0/9948 0 801/114558 0
N/A N/A 171/4116 0 0/9948 0 799/114558 0

Resolution: This will occur when jfs3.3 drivers are configured in the kernel.



The following version of the jfs3.3 patch should solve this.

Current version is

Patch Name: PHKL_21938

Patch Description: s700_800 11.00 JFS 3.3 perf, memory leak, corruption & hang

Creation Date: 00/07/05

Post Date: 00/07/13

Hardware Platforms - OS Releases:
s700: 11.00
s800: 11.00

There are some bad patches higher than this number.

Steve Steel

[oiram]

Hi,

This is a known problem with JFS 3.3. I think this patch can help you to solve the problem
PHKL_23773

Best regards.

[Steve Steel]

Hi

FYI

hp-ux_patches/s700_800/11.X/PHKL_23773 :JFS:3.3:performance:cumulative:VxFS:
Target: 11.00
1Liner: s700_800 11.00 JFS 3.3 perf, memory leak, corruption & hang

Status: General Bad
Rating: s700: 11.00: 2: 01/05/12:
s800: 11.00: 2: 01/05/12:

This patch has been withdrawn and there is not yet a replacement .As I indicated
Patch Name: PHKL_21938

Patch Description: s700_800 11.00 JFS 3.3 perf, memory leak, corruption & hang

Creation Date: 00/07/05

Post Date: 00/07/13

Is the current version and does not yet contain the fix.

Steve Steel

[oiram]

Hi again,

I think the latest JFS 3.3 cumulative patch contains the fix for this problem:
PHKL_25021
---------

sar -v and glance show ninode usage(count of active inodes
on the system) as 0.
---------------

Best regards.

[Steve Steel]

Hi


Guys I did check

hp-ux_patches/s700_800/11.X/PHKL_25021 :VxFS:JFS:3.3:
Target: 11.00
1Liner: s700_800 11.00 VxFS 3.3
Status: General Bad


Steve Steel

[Wodisch]

Hello Dennis,

some of sar's columns are zeroed out on HP-UX11i...

And second, the output of "sar -v" shows the kernel's table for HFS-inodes, but you are certainly using only very few of those (/stand being the only HFS file system, I guess), and the VxFS/JFS inodes are NOT kept in that table, anyway!
You are probably just wasting kernel space (=RAM) there...

Just my $0.02,
Wodisch