Operating System - HP-UX
1752782 Members
6781 Online
108789 Solutions
New Discussion юеВ

Re: Determine processes using nfile

 
SOLVED
Go to solution
yc_2
Regular Advisor

Determine processes using nfile

Hi,

1) How do I determine which processes are using the nfile ?

2) How can I be notified through email when the used nfile reach a value (e.g. 80% of the available value).



Thanks in advance,
YC
6 REPLIES 6
Bill Hassell
Honored Contributor
Solution

Re: Determine processes using nfile

nfile is the maximum number of files that can be opened at the same time. There is no simple HP-UX tool to list all the processes and their open files. However, a free program called lsof can do this. Get a copy from:

http://hpux.cae.wisc.edu/

However, every process will open a minimum of 3 files, more typically, 5 to 10 files. If 500 processes are running, from 2500 to 5000 file handles (nfile) will be needed. There isn't any problem unless some process is in a runaway state. Inn that case, check the maxfiles and maxfiles_lim kernel parameters.

As far as monitoring the value, you can use sar -v 1 and look at the file column. However, simply doubling the value of the kernel parameter nfile should work well for a while. nfile (and nproc) will always have to be adjusted upwards in a growing system. SAM can handle this task quite easily. Your system will have to be rebooted to take effect.


Bill Hassell, sysadmin
yc_2
Regular Advisor

Re: Determine processes using nfile

Hi Bill,

1) Thanks for your pointer about lsof. Had downloaded and will be using it.

2) My system has a copy of measureware, how can I define a notification in there for the utilisation of the nfile.


Thanks in advance again,
YC
James R. Ferguson
Acclaimed Contributor

Re: Determine processes using nfile

YC:

Glance will give you a global value. Select the 'system table' view with the option. While this does not give the value per process, I've found this to be quite useful.

...JRF...
Mike Stroyan
Honored Contributor

Re: Determine processes using nfile

You could code up your own program to monitor file descriptor usage with pstat_* calls. Here is an example that shows several kinds of reports for highest open file descriptor and details of open file descriptors.
Richard Hubbell
Advisor

Re: Determine processes using nfile

Bill was mostly right but missed some important details


Bill Hassell
July 15, 2000 01:15 AM GMT [ 10 pts ]


nfile is the maximum number of files that can be
opened at the same time. There is no simple HP-UX





nfile is the total number of file descriptors in use for the system
maxfiles and maxfiles_lim are per process and if you want to
go higher than 2048 you'll need to re-compile your program
with some special flags.





tool to list all the processes and their open files.
However, a free program called lsof can do this. Get a
copy from:

http://hpux.cae.wisc.edu/

However, every process will open a minimum of 3
files, more typically, 5 to 10 files. If 500 processes
are running, from 2500 to 5000 file handles (nfile) will
be needed. There isn't any problem unless some
process is in a runaway state. Inn that case, check
the maxfiles and maxfiles_lim kernel parameters.

As far as monitoring the value, you can use sar -v 1
and look at the file column. However, simply doubling
the value of the kernel parameter nfile should work
well for a while. nfile (and nproc) will always have to
be adjusted upwards in a growing system. SAM can
handle this task quite easily. Your system will have
to be rebooted to take effect.

sam will not allow you to go above some value for nfile I don't remember
the value but I know I have had to re-build the kernel by hand
because sam can't set high values for nfile. And nproc and nfile
don't always have to be chnaged together. Only if you need to.




Anthony deRito
Respected Contributor

Re: Determine processes using nfile

I'll have to agree with Bill. lsof is an excellent tool use with this sort of thing. In fact, I have used it on a number of occasions to get information that I cannot get with Glance/Plus. It helped me identify an Oracle database problem (actually it was a SQLNet problem) with identifying that we were using TCP/IP communication locally when talking to databases instead of the local UNIX domain protocol. It cut the time of some of our cycle jobs in half! Get it, understand how to use it, and be a hero!

Tony