Kernal Parameters for Oracle/Java App

[Paul McCleary]

Hi,

Does anyone know the 'best' kenerl parameters to use for an Oracle 8i database that will have a Java App running on top using ODBC?

It is a 6-way N-Class with 8GB RAM.

Whatever other performance tips (swap size etc) you can suggest would be great, as this is a benchmark and to ensure they go HP it obviously needs to zip along nicely.

I've also heard there are Kernel Templates I could use. R these worthwhile? If so which one would I use and where can I get hold of them?

Thanks & Regards, Paul

[Steven Sim Kok Leong]

Hi,

SAM provides a "Tuned Parameter Set" for "General OLTP/Database Server System". Note that this set of kernel parameter values are general ie. general to any type of database. Thus it is not advisable to apply this set of kernel parameter values.

Instead, I would suggest that you refer instead closely to the Oracle 8i installation manual. There should be one section on "Recommended OS Kernel Parameters for HP-UX 11.00". Most of the information you need will be there. Once tuned to this set of "Recommended OS Kernel Parameters", you can proceed to finetune these kernel parameters to suit your customised environment.

Depending on the number of concurrent Oracle connections you are looking at, you may need up to twice your memory for swap space. If there is few concurrent Oracle connections, then you may not even need any device swap to supplement the 8 GB memory.

Also depending on the number of concurrent Oracle connections you are serving, the kernel parameters of nproc and nfiles need to be tuned accordingly. Rely on the built-in formulas in the kernel parameters to compute these values where possible ie. modifying maxusers instead to update the other kernel parameters that depend on it etc. In addition, remember that you are using the database buffer cache in the SGA, so you can keep the OS buffer cache allocation ie. dbc_min_pct and dbc_max_pct to a minimum. Shared memory (shmxxx) and semaphore kernel parameters (semxxx) values are critical to any databases. Make sure that they are tuned to the "recommended kernel parameters" as indicated in the Oracle 8i installation guide, especially maxdsiz or maxdsiz_64bit.

Another important set of parameters that you should NOT neglect are network parameters such as tcp_conn_request_max and tcp_keepalive_interval. These values are important to service Oracle user processes initiated remotely via SQLNET.

As for I/O performance, for your Oracle index and database filesystems, make sure that your Oracle block size is in multiples of the OS block size. Use vxfs where possible and specify mincache option for these filesystems so that double buffering does not happen (ie. Oracle buffer cache is used but not the OS buffer cache). Raw devices are usually not recommended because they are less manageable.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Bill Hassell]

There are a couple of bad choices in the parameters from templates. The first is timeslice=1. Never change timeslice from the standard value of 10. It will cause massive context switches in a busy system. The other is ninode which will always be calculated far too high. Change it to a maximum of 500-1000. It is only used for HFS inode caching which are seldom used in 10/11 systems.

Careful on the buffer cache percentage. A very large value (ie, 50% max) can create a lot of overhead delays. Keep the cache to under 1000 megs for heavy write activity, not much more than 1500 for 50:50 rd/wt, and perhaps 2000-3000 megs for heavy reads. These values must be adjusted for the speed of the processor (larger for faster CPUs).

However, the buffer cache is in front of Oracle's SGA so it should be disabled for the Oracle data mount points (only). The mount options would be:

rw,nosuid,mincache=direct,convosync=direct,nodatainlog

When bypassing the buffer cache like this, you can reduce the upper buffer cache value by 50% or more and give that RAM to Oracle's SGA.

Naturally, each instance of Oracle will require another bump to the parameters, specifically nfile and nproc. Note also that the default fence values for maxdsiz, maxfiles amd maxusers are probably quite low for Oracle servers.

[Philip J Parker]

Hello all,
Well it's a year since this message was posted, but I seem to be treading similar ground.
Does anyone have any advice for me please?
I have just moved DB versions and am now running Progress V9 DB (from V8) on HPUX 11.00 on a N4000 4 cpu with 6Gb RAM (9Gb swap). The new DB App's use Java 1.3 and I am getting serious memory problems and mega swapping.

This post has already been useful in highlighting kernel params I need to change and thankyou everyone. But can anyone share any more useful tips / experiences they have had on HPUX / Java / DB performance issues generally.

TIA, Phil.

[Dan Vowell]

Java is very dependent on kernel threads; make sure max_thread_proc and nkthread are set higher than default.

The HP-UX process scheduler has a swap reservation policy that allows you to manage 9GBs worth of virtual memory space for processes (based on your configured swap device)
PLUS an additional 4.5GBs of space (75% of 6GBs of RAM) IF
"swapmem_on=1". If this is set to zero, you're stuck with on 9GBs of VM space to manage.

Contrary to popular opinion, you are not giving away RAM as a pseudo-swap device or electronic disk when you set this parameter to 1. You're simply telling the OS that it is OK to manage more VM. We are basically inflating the kernel's "swap_avail" counter by this extra amount.

Your system is most likely thrashing because the counter has decremented all the way down to zero or close enough to cause massive pageouts and perhaps even deactivation of entire processes and all the pages associated with them in order to make room for other processes to run on this very busy system.