Kernel parameter tuning

[sivashankar]

Hi

In HP-UX 10.20 these was a Kernel template called "General OLTP/Database Monolithic System
"

what would be the similar Kernel template on HP-UX 11i?

Thanks
Shanakr

[Rajeev Shukla]

You have a similar template in 11i
called "General OLTP/Database Monolithic System"

Cheers
Rajeev

[Jeff Schussele]

Be wary of ANY DB template that calls for timeslice=1
timeslice should always be around 10.

My $0.02,
Jeff

[Rajeev Shukla]

I am sorry for misleading, when i practically did i too didn't find and this is what HP Doc. says
At HP-UX 11i, the support of some kernel parameter templates were
discontinued. Contact the application/database vendor for their
recommendations. For reference, included below is a list of the
11i supported templates along with the list of 11.0 templates.

The template is like..
CAE/ME/EE Engineering Workstation (Previous Version)
EE Engineering Workstation 32-bit Kernel (New 10/99)
EE Engineering Workstation 64-bit Kernel (New 10/99)
CAE/ME/General Eng. Workstation 32-bit Kernel (New 10/99)
CAE/ME/General Eng. Workstation 64-bit Kernel (New 10/99)
V-class Technical Server

Cheers
Rajeev

[Jeff Schussele]

Don't be concerned Rajeev.
There is no proper template.
Every install is different. You have to tune, to get the instrument to sound sweet.

Shanakr - search the forum for "Oracle tuning". You'll get tons of hits. You'll find a starting point - just log your mods & you'll find the sweet-spot. Rule One: One change at a time. Rule Two: Track results.

Rgds,
Jeff

[Jakes Louw_1]

OK, clever guys....
I need details on the negative impact of tuning certain kernel params too LARGE, especially the impact on syscalls that need to scan all these frigging kernel tables. The params I'm specifically looking at reducing are:
NPROC
NFILE
SHMMNI
MSGMNI
SEMMNI
NFLOCKS
NPTY/NSTRPTY
NINODE
MSGMAP
SEMMAP

The current settings were "thumb-sucked" by a local HP SE that might have been a little intimidated by the SuperDome. My theory is that certain syscalls like READ, WRITE, OPEN, etc, are spending cumulative time racking through these tables. At several gazillion I/Os per day, this all adds up....