topic Re: About increasing nfile parameter in Operating System - HP-UX

About increasing nfile parameter

Carles Viaplana — Wed, 03 Jan 2007 07:00:16 GMT

Hello,

I detected open files are close to limit:

HP-UX ra B.11.11 U 9000/800 01/03/07

12:47:03 text-sz ov proc-sz ov inod-sz ov file-sz ov
12:47:08 N/A N/A 370/5120 0 2020/32768 0 25980/32778 0
12:47:13 N/A N/A 378/5120 0 2030/32768 0 26008/32778 0
12:47:18 N/A N/A 393/5120 0 2030/32768 0 26018/32778 0
12:47:23 N/A N/A 368/5120 0 2029/32768 0 25973/32778 0
12:47:28 N/A N/A 361/5120 0 2013/32768 0 25913/32778 0

In order to solve this issue I should increase nfile parameter. But before to do this I have some questions:

- nfile parameter current value is 32768, but as you can see, max value for file-sz is 32778. Does file-sz limit increases if I increase nfile paramter? Note that file-sz is 10 units greater.

- Our system has 7 GB RAM and if I'm right for 1 GB I can increase 65000 (more or less), so can I set nfile value to 100000 without problems or is there any other limit like other kernel parameter value?

Thanks in advance for your help.
Regards,

Carles

Re: About increasing nfile parameter

Jaime Bolanos Rojas. — Wed, 03 Jan 2007 07:21:21 GMT

Carles,

This is what the man pages says about it:

"The value used for nfile must be sufficient to serve the number of users and processes allowed by the combination of nproc, maxusers, npty, and nstrpty"

http://docs.hp.com/en/TKP-90202/re56.html

Regards,

Jaime.

Re: About increasing nfile parameter

Steve Steel — Wed, 03 Jan 2007 07:22:08 GMT

Hi

If you look via the available tools

Parameter: nfile
Value: (32*(NPROC+16+MAXUSERS)/10+32+2*(NPTY+NSTRPTY+NSTRTEL))
Default: (16*(NPROC+16+MAXUSERS)/10+32+2*(NPTY+NSTRPTY+NSTRTEL))

This is all done via formulas

Increase nproc and a lot of other things increase in proportion

see
http://www.docs.hp.com/en/939/KCParms/KCparams.OverviewAll.html

Steve Steel

Re: About increasing nfile parameter

Steven E. Protter — Wed, 03 Jan 2007 07:26:11 GMT

Shalom,

file-sz related to the size of the file, has no relation to nfile. It is not a kernal parameter. file-sz is displayed by star when measureing performance. From your output you appear to have 25,590 files of a possible 32778 open. You are far from the limit and should get a file table overflow if you run out.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=186045

nfile is the total number of files open on a system.
maxuprc is the total number of files permitted open for one user.

I don't believe raising nfile will cause problems with other parameters. Increasing the kernel parameter itself will not significantly impact memory use or system performance.

When the files are actually open, then there will be an impact on system peformance.

SEP

Re: About increasing nfile parameter

Jaime Bolanos Rojas. — Wed, 03 Jan 2007 07:26:15 GMT

Carles,

Also there is this doc in the itrc site called What is the effect of incresing the parameter nfile?

DocID AK9010011200

Regards,

Jaime.

Re: About increasing nfile parameter

Carles Viaplana — Wed, 03 Jan 2007 07:49:37 GMT

Hello,

First to all, thanks a lot for your replies.

About nfile parameter value, it isn't a formula so I should set a value. But this is not really important as in any case I'm able to increase it to at least 100000.

But about file-sz, we already arrived to top value and for this reason we're planning to increase nfile parameter as it seems to set file-sz limit.

Is this last point correct or should I increase other value?

Re: About increasing nfile parameter

Carles Viaplana — Wed, 03 Jan 2007 07:57:47 GMT

Sorry, I submit message before ending...

Some days ago we arrived to file-sz limit (I supose)due SAP and Oracle are running there.

After an emergency system reboot file-sz decreases but it is growing.

First time oracle open a datafile it keeps file open to access quickly it next time, so in the worst case (all SAP sessions working at same time) I think I'll need 54.000 open files.

Now nfile value is 32768 and file-sz limit is 32778, so my question is:

- If I set nfile to 100000 can I grant I won't arrive to file-sz limit?

Thanks again for your help.
Regards,

Carles

Re: About increasing nfile parameter

Jaime Bolanos Rojas. — Wed, 03 Jan 2007 08:02:18 GMT

Carles,

In your output of sar -v we can see this values: 25980/32778

When the first value is too close to the other value you should get this error:
"File table overflow"

If you have not gotten that error yet you should be fine for the moment, but if you want the difference in numbers to be higher the only thing that you have to do is to increase the nfile parameter which does not impact anything else in the system if you got enough memory.

Regards,

Jaime.

Re: About increasing nfile parameter

James R. Ferguson — Wed, 03 Jan 2007 08:11:11 GMT

Hi Carles:

Disregard any formula for 'nfile' and hard set a value which fits your needs. Increasing your 'nfile' 3-fold would be fine. The value of 'nfile' ranges from 2048 to the size of a 32-bit integer, so you have a very large range.

The kernel uses very little memory for each increment in the value of 'nfile'. The parameter represents the number of slots in a kernel table --- one for each open file.

Regards!

...JRF...

Re: About increasing nfile parameter

Carles Viaplana — Thu, 04 Jan 2007 06:30:14 GMT

Hi all,

I made change in a test environment and system is working fine, even with just 4 GB RAM.

Tonight I'll make change in production environment due file-sz value is still increasing there and I'm sure it could increase at least until 52000.

BTW, I saw file-sz is always just 10 units greater than nfile. Do you know why?

Thanks to all and regards,

Carles

Re: About increasing nfile parameter

Hein van den Heuvel — Thu, 04 Jan 2007 07:30:47 GMT

man sar ...

file-sz = The current-size and maximum-size of the system file table;

It is not a control variable, but a display variable.

Hein.

Re: About increasing nfile parameter

Carles Viaplana — Fri, 05 Jan 2007 02:21:00 GMT

nfile parameter changed succesfully.

Thanks to all for your help.
Regards,

Carles