Why not kernel parameters at their highest level?

[Richard Perez]

I have been wondering why tuning a system involves setting tight kernel parameters instead of loosen ones.

Shouldn't be better to have, say, inodes at 64000 when just 10000 are being used? That way you never have to worry if the inode limit will sometime be reached.

How costly is in system resources to have maxusers at its maximum (or ninode, pty, and so on)?

[Raj D.]

Hi Richard,
Increasing kernel parameter to a high value can cause problem. As it needs to reserve swap and to occupy Physical memory.

Hence kernel parameters needs to understand as per current usuage and need to configure accordingly if required to increase. For system table usuage glance -t , can be use.

for maxusers : A good value for most systems to start with 200 , this is used to size many other tunables , so dont go overboard.

Hth,
Raj.

[James R. Ferguson]

Hi Richard:

Some kernel parameters are "fences" that provide boundries to prevent one user or process from monopolising or consuming too much of a resource, such as memory or procesor; or the number of open files; or the number of processes that can be spawned. As such, "fences make good neighbors".

Other kenrel parameters allocate table slots and as such, the more allocated, the more overhead (usually memory) needed to support the larger allocation. Thus, why waste a resource like memory to reserve slots that you aren't going to use.

The tunable kernel manpages do an excellent job, on a tunable by tunable basis, of describing the effects of inflating or deflating various values. Have a look on a per-tunable basis:

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

Regards!

...JRF...

[Geoff Wild]

That depends - do you have a server with oodles of ram and cpu? :)

Ontop of the above link, also peruse "HP-UX Kernel Tuning and Performance Guide":

http://docs.hp.com/en/1219/tuningwp.html

Main reason you have tight kernel parameters is to optimize performance.

Rgds...Geoff

[Marlou Everson]

If you are using vPars (Virtual Partitions) it is a requirement that "the sum of the sizes of the kernels running in memory within a hard partition must be less than 2 GB." Having all the kernel parameters at their highest value could limit how many vPars you could create.

Marlou

[Bill Hassell]

As mentioned, many parameters actually reserve table space and make the kernel significantly larger. Your example for ninode is a problem in that the default formula is obsolete and reserves an immense amount of kernel RAM space that is not necessary. ninode reserves space for HFS filesystems and needs only 500 to 2000 slots. Ignore what Glance and sar report as the kernel cannot report on reusable slots and thus always appears full.

A more reasonable parameter might be nfile. If 5000 is good, why not make it 50,000 or even 5,000,000? The reason is that a huge amount of kernel space will be needed, spac e that cannot be used for anything except open file descriptors. If your typical busy system uses 5000 open files, then setting nfile to 8000 or even 10,000 is reasonable, but 100,000 would be a big waste.

And for 32bit kernels like 10.20, the kernel cannot exceed about 12 megs in size or the kernel won't boot. So it makes sense to adjust the values as needed. The fence limits (like maxdsiz or maxuprc or maxfiles) can be set to very high values without problems as they do not allocate space. Fences are used primarily in development systems where programming errors might consume massive system resources.

[Richard Perez]

Thanks for your answers.

Do you know how many kernel Bytes/kBytes are used by each:
-inode
-file (from maxfiles)

Regards

[James R. Ferguson]

Hi Richard:

The paper entitled "Common Misconfigured HP-UX Resources" ( http://www.docs.hp.com/en/5580/Misconfigured_Resources.pdf
) addresses your questions about inode size, memory consumption for open inodes, and the 'ninode' table.

Your second question about the overhead of the 'nfile' table and its relationship to 'maxfiles' brings to light another lesson.

Increasing the 'nfile' table (for the number of open files on a system) is a common need with database and web servers. The "Tunable Kernel Parameters" guide ( http://www.docs.hp.com/en/TKP-90202/TKP-90202.pdf ) notes that on a per-slot basis the amount of memory needed for 'nfile' entries is small and one should be generous in assigning values to 'nfile'.

By default, 'nfile' is calculated based partly on 'maxusers'.

The 'maxusers' define (constant) is intended to represent the number of users you expect to have on your system at any one time. Yet, if you use its value to calculate an inflated value for 'nfile' you also increase the default value of 'ninode' (which represents the number of in-memory open inodes allowed).

Thus, perhaps without realizing it, using 'maxusers' to inflate 'nfile' which uses relatively small amounts of memory, can lead to using large amounts of memory for 'ninode'.

This is another reason why you don't capraciously want to set kernel parameters and constants to their maximum values without understanding the cascading effects.

Rather, in cases where larger values of 'nfile' are needed, dispose of the formula and hard-set 'nfile' to a value that satisties your requirements. Ditto for 'ninode'.

Regards!

...JRF...

[Sivakumar TS]

Hi,

Changing kernel parameters to improper or inappropriate values or combinations of values can cause data loss, system panics, and other (possibly very obscure and/or difficult to diagnose) operating anomalies.

Before altering the value of any configurable kernel parameter, be sure you know the implications of making the change.

Dont set any system parameter to a value outside the allowable range for the parameter. (SAM refuses to store values outside the allowable range.)

Many parameters interact, and their values must be selected in a balanced way.

With Regards,

Siva.

[Richard Perez]

many thanks