strange maxfiles problem

[likid0]

Hy,

There is a bug in oracle RAC, with a process that opens loads of files, in my case 61189, I increased the nfiles to 90000, because i was getting the Table is full, message in syslog

[root@sdp:/tmp]# lsof G 2344 | wc -l
61189

The thing is .. that I haven't increased the maxfiles and the database is working with no problem.

Does it make any sense?, shouldn't the system stop oracle from opening more than 2048 file descriptors?

[root@sdp:~]# kcusage
maxfiles_lim 61151 / 4096
nfile 65635 / 90000

[root@sdp:~]# kctune G maxfiles
maxfiles 2048 Default
maxfiles_lim 4096 Default Immed

sdp@oracle:>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 1048576
stack(kbytes) 131072
memory(kbytes) unlimited
coredump(blocks) 4194303
nofiles(descriptors) 2048

:?

[James R. Ferguson]

Hi:

The 'maxfiles' paramters is a *per-process* file descriptor limitation. It is 'nfile' that sets the overall, system fence.

Regards!

...JRF...

[likid0]

Yes but as you can see, its one process(2344), that has all the files open:

[root@sdp:/tmp]# lsof -p 2344 | wc -l
61189

the process is from oracle,and the maxfiles per process is 2048.

you can see maxfiles in kcusage is way over the top:

[root@sdp:~]# kcusage
maxfiles_lim 61151 / 4096

thnx

[James R. Ferguson]

Hi (again):

The "soft limit" for open files per process is governed by 'maxfiles'. Processes can increase this up to the "hard limit" set by 'maxfiles_lim'.

The 'maxfiles_lim' is a dynamic tunable as your data shows.

As an aside, counting open files with 'lsof' as you did, may suggest too large an open count. You undoubtedly have memory-mapped files represented and it is possible to mmap() a file after opening it and then close the descriptor.

Regards!

...JRF...

[likid0]

Ok, I get that, so then my question is.

if maxfiles_lim is the hard limit and its 4096.

why kcusage shows 61151 on maxfiles_limit ?

[root@sdp:~]# kcusage
maxfiles_lim 61151 / 4096

[Dennis Handly]

>why kcusage shows 61151 on maxfiles_limit?

Perhaps kcusage(1m) is making the same mistake as lsof?