topic Re: file descriptor not enough in Operating System - HP-UX

file descriptor not enough

Vincent Lam_1 — Thu, 23 Dec 2004 05:54:54 GMT

My Java application complains that there is not enough file descriptors. Before I try to increase the "max file" in sam, I'm looking for a way to know the number of files currently open by the application.

Is there any way that we can monitor this number with OS commands?

Re: file descriptor not enough

Fred Ruffet — Thu, 23 Dec 2004 05:58:25 GMT

There's a magical tool for those kind of situation called lsof. You can find it here :
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.73/

Regards,

Fred

Re: file descriptor not enough

RAC_1 — Thu, 23 Dec 2004 06:00:12 GMT

nfile kernel parameters define the system wide open files.
sar -v 5 5/glance -t
Will tell you that.

The no. of files opened by a process can be check with glance and with lsof tool.

If you are hitting the nfile limit, you will have to increase it. This is static value and you will have to reboot the box after kernel tuning.

Anil

Re: file descriptor not enough

Vincent Lam_1 — Fri, 31 Dec 2004 00:13:17 GMT

I'm now thinking of increasing the max file. But what would be its implication on the resource consumption (like memory usage)? If the cost is cheap, should I just increase it to the maximum (65535?)? Any advise?

Re: file descriptor not enough

Biswajit Tripathy — Fri, 31 Dec 2004 00:30:54 GMT

RAC wrote:

> If you are hitting the nfile limit, you will have to
> increase it. This is static value and you will have
> to reboot the box after kernel tuning

On HP-UX 11.23, nfiles tunable can be dynamically
set without rebooting the system (as long as you
set it to a value greater than # of currently open
files). Ofcourse, you need to reboot if you want to
set it to a # smaller than currently open files.

Vincent,
if your system has more than 1 GB of memory, the
nfiles is already set to 65536 by default (again I'm
assuming HP-UX 11.23).

- Biswajit

Re: file descriptor not enough

Bill Hassell — Fri, 31 Dec 2004 18:51:37 GMT

The number of open files per process has no kernel impact at all. Instead, it is a bad program safety fence. You can increase the number to thousands, but now any program is free to open a large number of files. The reason that this limit exists is that if a runaway script or program run in an infinite loop, opening 10's of thousands of files, the kernal maximum (nfile) will be exceeded and then, not even root can login.

So you have two choices. If you have programmers developing programs, I would leave the limit at slightly more than the Java apps require (although a program that opens thousands of files at the same time seems in need of a redesign). Or you can leave the limit at 60 (the default) and increase the limit in the Java environment with a call to setrlimit or use a shell script to start the Java apps and use the ulimit -n shell built-in to set a higher value for the Java environment.

Note also that the Java app will also complain about file handles if nfile is too small. nfile is the maximum number of files open at the same time. maxfiles is a per-process limit while nfile is for all files.