What exactly is a File Table in HP-UX.
I have a notion it is to do with open files (or directories) but references to "File Table" are very sparse and I cannot find a description for it.
In what context are you encountering this term?
There is a file system table in /etc/fstab which lists all the file systems that the system knows about. There is also a file table in the kernel which keeps track of open files. There are various kernel parameters you can adjust which affect the internal file table.
Thanks for the reply.
To expand further:
A have a process which daemonises and monitors predefined directories for certain files. The files are described via a regular expression and when a file name happens to match it will call another process to deal with that file.
This process is designed to run for long periods of time, but will be re-cycled once per day (24 hr cycle) in the current configuration.
Normally there is no problem, but 2 days ago it failed with an error number 23 when trying to scan or open a directory.
The error number comes from errno.h and the description for it is: "File table overflow"
Not I might add 24 which is: "Too many open files".
Prior to posting this message I have conferred with some of my colleagues and the conclusion was more or less as you suggest; something to do with open files. This discussion has prompted me to review the program logic but it would help if I had a better idea of what the "File Table" is so I know where to look.
MBB
If you get open up 'sam' you can go into the "Kernel Parameters" section and look for the entries that have to do with the file table. Values you might be interested in chaning/examining:
nfile
maxfiles
maxfiles_lim
ninode
nflocks
Be careful if you modify these as it is possible to hose your system if you make a mistake. Usually if an application requires you to modify kernel parameters, the vendor will provide specific instructions on what to change.
The file table you are referring to is a kernel memory structure. The size of the these 'tables' can be adjusted by above parameters but keep in mind that excessively big file and inode tables can have a severe performance impact as these kernel tables need to be scanned *very* often. The bigger the table , the longer the scan takes...
You can use sar to get a picture of your current kernel specs regarding files/inodes:
sar -v:
00:30:00 text-sz ov proc-sz ov inod-sz ov file-sz ov
00:31:00 N/A N/A 206/2500 0 948/22048 0 1151/39558 0
00:32:00 N/A N/A 206/2500 0 948/22048 0 1151/39558 0
00:33:00 N/A N/A 206/2500 0 974/22048 0 1152/39558 0
00:34:00 N/A N/A 206/2500 0 945/22048 0 1152/39558 0
01:30:00 N/A N/A 198/2500 0 1004/22048 0 958/39558 0
Thanks for your replies.
I figured it out just as you all posted back your replies. I asked another colleague about the problem and he instantly said: "You have run out of inodes".
So then I got to thinking and got it. The system has only 2048 inodes permissible. In one part of the directory structure there are a lot of empty directories - so much so - that I think the system has run out of inodes.
This problem has been manifesting itself in different ways on the system.
So, the empty directories will be cleared out and I will see how the system behaves tomorrow.
(And yes leaving lots of empty directories around is not a very good idea! Another job on my to do list to make sure these directories are cleared automatically).
Yep that did the trick!
Once again thanks all.