Formula to calculate memory needed for a given nfile (more questions)

[thewho?]

Thanks to all of you for your quick response.
We currently have the nfile set at 160,000 which amounts to 5Mb of memory within the kernel. The value we estimate we need would be close to 500,000 (which will reserve 16Mb).
According to glance (option m) we're currently allocating 307 Mb for the kernel (Sys Mem field), this increase in nfiles would represent a 5% increase on the kernel, which, to me, shouldn't impact that much.
What would be the repercusions of such a value?
Am I reading this right?
TIA,
Luis

[A. Clay Stephenson · Accepted solution]

I think your original posting indicated that you had > 500 users needing > 200 file descriptors each. At 160000 you should already be covered. Before I went to 500K I would
check for actual overflows using sar -v.

In any event, your calculations are correct; I'm just a little leary of going so high before I know that overflows are occuring.
sar -v will tell you that.

[CHRIS ANORUO]

Extract from the kernel documentation on nfile (The value used for nfile must be sufficient to service the number of users and processes allowed by
the combination of nproc, maxusers, npty , and nstrpty.)
http://docs.hp.com/hpux/onlinedocs/os/KCparam.Nfile.html
Your value of 500K is rather high! NFILE value should be determined by the values and combinations of NPROC, MAXUSERS, NPTY, and NSTRPTY.
(Check with sar -v and "wc" commands for the processes opened by applications/user - ps -ef|grep ora|wc -lcw)

[thewho?]

I understand your concerns, we're using Progress databases, which means that each database is composed of n number of 'extents' (for data, redo logs, etc). When you connect to a database you need a file handle for each extent for as long as you stay connected.
In our case, we have several large databases and each user connects to all of them at the same time, this is why we need a high nfile.
I checked the sar -v (Thanks for the tip!)and on peak times we have 98000 file handles.
Do you know of any other problems/side effects ?

[A. Clay Stephenson]

Luis, given that you are on track but it looks like at 160K you are already there. I've never gone above 80K myself but your application is unusual. I'm guessing that you need a good bit of buffer cache for this application.