File table overflow.

[Jagadesh]

When i tried to change the value of Maxusers and nfile value in kernel configuration in SAM iam getting the following error.

Cannot build a kernel using /usr/sbin/config. The standard output of the command is shown below:
WARNING: No such device, tunable, or cdio autofsc
Ignoring the following line.
autofsc
(Bundled) cc: error 1404: Can't find the process "/usr/ccs/lbin/cpp".
stop.
config: make did an exit(1)
The command exitted with exitcode -71.

Kindly help me out. Thanks in advance.
Regards
Jagadesh

[Michael Tully]

You could have a value that is outside the threshold if you increase some parameters too large. Try to lower the values and see if the kernel will build. Alternatively let us know what is in the system file and values your attempting to add. The error message however points to a problem with the 'autofsc' driver which should not be a problem. Have you also added 'cachefsc' ?

[Jagadesh]

Hi Michael,

Pls have a look at my system file

* Drivers and Subsystems

DlkmDrv
GSCtoPCI
PCItoPCI
SCentIf
arp
asio0
asp
audio
autofsc
beep
btlan3
btlan6
c720
cb
cdfs
clone
core
diag1
diag2
dlkm
dlpi
dmem
echo
fc
fc_arp
fcgsc
fcgsc_lan
ffs
foreign
framebuf
graph3
hcd
hid
hpstreams
hub
inet
ip
ite
klog
lasi
lba
ldterm
lvmaclan
netdiag1
netqa
nfs_client
nfs_core
nfs_server
nfsm
nms
nuls
pa_generic_psm
pa_psm
pat_psm
pci
pckt
pipedev
pipemod
ptem
ptm
pts
rawip
rpcmod
sad
sapic
lvm
sba
sc
sctl
sdisk
side
stape
stcpmap
strlog
strpty_included
strtelnet_included
superio
tcp
telm
tels
timod
tirdwr
tlclts
tlcots
tlcotsod
token_arp
tun
udp
ufs
uipc
usbd
vxbase
wsio


* Kernel Device info

dump lvol


* Tunable parameters

STRMSGSZ 65535
create_fastlinks 1
default_disk_ir 1
fs_async 1
max_thread_proc 8000
maxdsiz 3221225472
maxdsiz_64bit 17179869184
maxfiles 2048
maxfiles_lim 2048
maxssiz 83570668
default_disk_ir 1
fs_async 1
max_thread_proc 8000
maxdsiz 3221225472
maxdsiz_64bit 17179869184
maxfiles 2048
maxfiles_lim 2048
maxssiz 83570668
maxssiz_64bit 268435456
maxswapchunks 4096
maxtsiz 0X40000000
maxtsiz_64bit 4294967296
maxuprc 256
maxusers 128
ncsize 5024
nfile 8000
ninode 8000
nkthread 15000
nproc 7500
npty 200
nstrpty 200
shmmax 750741824
dbc_max_pct 20

I have tried to change the value of maxusers and nfile
maxusers from 32 to 64
nfile from 910 to 1981
but it is not allowing me to do the same. How can i overcome this file table overflow. Some times it is not allowing me to open the SAM itshelf. Iam getting
# /usr/sbin/sam
crt0: ERROR couldn't open /usr/lib/dld.sl errno:000000023
/usr/sbin/sam[196]: /var/sam: bad directory
/usr/sbin/sam[222]: rsam: not found

Kindly help me out

[Bill Hassell]

There are many things wrong with the system file you posted:

maxdsiz is 3Gb which SAM may not like at all. Typically, SAM allows maxdsiz to be just about 2Gb. There are special requirements to allow a 32bit program just to get to 1.7Gb, and many others to go beyond 2Gb (including special patches). Change this to 2Gb for now.

fs_async = 1 is a high rik parameter. Any unexpected power fail or a crash can leave busy filesystems corrupted so badly that fsck cannot fix them. fs_async=1 can improve write speed a bit, but the risk is too high for production systems. Also, fs_async=1 appears multiple times in the system file. Normally, SAM won't ever create a duplicate parameter entry and the extras may cause SAM to have difficulties.

nfile and nproc don't make much sense. nproc is 7500 and since all processes need a minimum of 3 files (average is more like 5-6), then nfile should be 22500 to about 45000. Do you really have more than 5000 processes running at the same time? The rule of thumb is nfile = nproc * 5

ninode = 8000 looks way too high. Change it to a fixed value, no more than 4096.

maxusers = 128 yet you said you tried to change it maxusers from 32 to 64, yet the system file says 128. Has the system file been edited by hand? The inconsistencies seem unusual for SAM to allow. To see the parameters your currently running kernel is using, use kmtune.

max_thread_proc = 8000 which seems very high. DO you really have a process that will start more than a few hundred threads? A process that tries to run 7000+ threads needs a big design review.
-------
Compare the output of kmtune with SAM's list of parameters. They should be the same. Then shutdown all applications and lockout users until you can generate a new kernel. The file table overflow is caused by having too many users and processes on the system. Once a new kernel has been put into place with stable values, things should be a lot better.

And most important, keep up to date on patches.