system memory and inode utilisation

[bhavin asokan]

hi,

i have following doubts.
1)is there any problem if the inode is showing full .when giving sar -v 2 5 the systems shows the following results

1st system
hpux 11.0

13:35:47 text-sz ov proc-sz ov inod-sz ov file-sz ov
13:35:49 N/A N/A 142/4116 0 4796/4796 0 767/20010 0
13:35:51 N/A N/A 142/4116 0 4796/4796 0 767/20010 0
13:35:53 N/A N/A 142/4116 0 4796/4796 0 767/20010 0
13:35:55 N/A N/A 142/4116 0 4796/4796 0 767/20010 0
13:35:57 N/A N/A 142/4116 0 4796/4796 0 767/20010 0

cpu 2% disk 8% memory 86% totalmem=2.5GB

2nd system
hpux11.0

14:02:39 text-sz ov proc-sz ov inod-sz ov file-sz ov
14:02:41 N/A N/A 148/2000 0 2368/2368 0 865/4010 0
14:02:43 N/A N/A 148/2000 0 2368/2368 0 865/4010 0
14:02:45 N/A N/A 148/2000 0 2368/2368 0 865/4010 0
14:02:47 N/A N/A 148/2000 0 2368/2368 0 865/4010 0
14:02:49 N/A N/A 148/2000 0 2368/2368 0 865/4010 0


cpu 10% memory 96% disk 52%
total phy.memory 1.5GB
how can i check which process is using this inodes







2) other system shows the system memory is nearly 25% of total memory.
hpux11iv1,L2000 server

total=3GB system=815MB buffer=860MB

i know that if i will reduce the dbc_max_pct from current 30% to 10% the buffer will decrease.my question is why system is taking this much physical memory.is there any relation between buffer memory or total memory with system memory.
how i will find that which process is using this much memory.

on the same system the sar -v 2 5 shows 0 inode used even though somany java and oracle processes are running and users are working .


13:40:54 text-sz ov proc-sz ov inod-sz ov file-sz ov
13:40:56 N/A N/A 125/1620 0 0/2268 0 578/4179 0
13:40:58 N/A N/A 125/1620 0 0/2268 0 578/4179 0
13:41:00 N/A N/A 125/1620 0 0/2268 0 578/4179 0
13:41:02 N/A N/A 125/1620 0 0/2268 0 578/4179 0
13:41:04 N/A N/A 125/1620 0 0/2268 0 578/4179 0


regds,

[Stephen Keane]

Your first example (inod-sz full) is not unusal.

The number to the left of the / is the number of inodes open in the inode cache and the number on the right is the max number of inodes that can be open in the inode table cache (ninode in the kernel). HP-UX tries to keep this value at the maximum for performance reasons. Unless you actually have a performance problem, I wouldn't worry about it.

[Stephen Keane]

How much swap do you have on the system?

[Fred Ruffet]

1. If inode table is full, system will need to free space in it, in order to load the ones needed. If none can be deleted from table, then you may have trouble. It would be better to increase this value. Note that it doesn't take a lot of space, so you can increase its size without any big consequence.

2. About buffer cache, space is never released. So, buffer will grow. Depending on your IO rates, it will grow faster or slower, but it will grow, and will finally reach its max value (dbc_max_pct). If you have 30%, it will grow to 30% your 3GB RAM.
Note that having a big cache may be a good thing. It depends on what your server do. For a file server it's an extremly good thing. Even for oracle, if you don't use it for oracle datafiles, and if your buffer max size added to your SGA and PGA will never exceed RAM size. Problems will start if your buffer or your SGA goes to swap.

Regards,

Fred

[Hoang Minh Tuan]

Hi ,

You can use top command then refer to RES column to find which process take the highest memory or use GlancePlus by type #glance.

The dbc_max_pct is the the max percentage physical memory used for IO buffer. If it don't use all max buffer, the remainder will use for application process.

Your system are in memory shortage, indicated by utilization reach 98%. I agree with you that you should decrease dbc_max_pct and nproc kernel parameter.

HMT

[Bill Hassell · Accepted solution]

The ninode table calculation in sar (and Glance) has always been VERY misleading. You could set ninode to 50000 and it will eventually be full. The reason is that the kernel's method to report inode usage includes old (reusable) entries, that is, files that were open in the past but not open now. The inode table is for HFS filesystems and indirectly by NFS and is used to 'remember' files that are currently open or have recently been open. It saves having to find the same file on disk for repoens.

For most versions of 11i, the table is still shown with all occupied slots. However, there is a patch (PHKL_23241:) that fixes inode=0 in sar and Glance. The current version of the patch is PHKL_30833. Whether sar reports inode=0 or inode=100% full, the metric is not useful in sizing the table. In general, ninode only needs to be 2000-4000. If ninode is still a formula for building your kernel, it can become outrageously high (ten's of thousands) when maxusers is adjusted. Make sure ninode stays low...2000 to 4000 max. If ninode is too low (less than 100), you'llsee the message:

inode: table is full

on the console and kernel building will fail (/stand is usually the only HFS filesystem)