|
HP-UX kernel parameter configuration for Java™ support
Java™ programs can heavily use threads and sockets. Server applications commonly spawn 1-2 threads for each client connected to the server, e.g., one socket connection to read and another to write.
threads
The default values for HP-UX 11.0 are set too low for most Java™ applications. Two kernel parameters need to be set so that the limit of the maximum number of threads per process is not encountered. Usually you will see this problem as a Java™ Out of Memory error. You will want to set the value of the max_thread_proc higher than the expected maximum number of simultaneously active threads for your application. You can check the number of threads in your process by
using the -eprof option available as of JDK 1.1.8. Analyze the Java.eprof file using HPjmeter by selecting the threads metric.
max_thread_proc
The maximum number of threads allowed in each process. The minimum value (and default) is 64, often too low for most Java™ applications. The maximum value is the value of nkthread.
nkthread
The total number of kernel threads available in the system. This parameter is similar to the nproc tunable except that it defines the limit for the total number of kernel threads able to run simultaneously in the system. The value must be greater than nproc. The default is approximately twice that of nproc. The maximum is 30000.
The suggested value of nkthread is 2*max_thread_proc. If you have many Java™ processes running and each running process uses many threads, you will want to increase this value.
open files
Problems occur when the value of kernel parameters are set too low for the number of files allowed to be simultaneously open in a process.
Be certain that your kernel is configured so that you do not reach the limit for the number of open files for your process. Java™ opens many files in order to read in the classes required to run your application. A file descriptor is also used for each socket that is opened. Use Glance to analyze the total number of files open when running your application.
nfiles
Maximum number of open files
This value is usually determined by the formula:
((NPROC*2)+1000)
NPROC is usually: ((MAXUSERS*5)+64)
For a MAXUSERS of 400, this works out to 5128. You can usually set it
higher.
maxfiles
Soft file limit per process
maxfiles_lim
Hard file limit per process
2048 is the maximum value you can set through SAM for maxfiles and maxfiles_lim.
Note that you can set the parameters higher by configuring the kernel using the configuration file and then rebuilding the kernel (or by modifying stand/system and doing a mk kernel). Since setting these parameters too low results typically in application failure, you may want to calculate the number you need and then double it.
You might also consider ninode along with these parameters, that is as a member of the "set". If there's no space in the appropriate inode table then you cannot open a new file.
timeouts
If the number of pending timeouts on the system exceeds the maximum number of allowable pending timeouts on the system then the system will crash. This undesireable behavior can be avoided by increasing the following kernel parameter:
ncallout
Maximum number of pending timeouts
If you are opening many sockets, many of which are waiting on I/O, you will likely run into this limit.
Set ncallout to a value greater than the sum of:
nkthread + the number of I/O devices connected to the machine
A callout structure is used by each thread that sleeps waiting for a time-based
event. Traditionally the callout structure used by a thread is taken from a
pool the size of which is controlled by ncallout. Each thread has a set of
timers associated with it, e.g. for nanosleep or sleeping in select().
There are a set of BringYourOwnCallout functions that don't allocate from the
pool. The maximum number of callout structures needs to be approximately the
maximum number of threads.
interactively setting user limits
If you suspect that you are running out of file descriptors, you can check your limits by switching to the Bourne Shell and resetting the limits. Simply type in the following:
>sh
>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 200
>
Use the first character to reset any of the values. For example, to increase the number of file descriptors, simply type:
>ulimit -n 5000
>ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 65536
stack(kbytes) 8192
memory(kbytes) unlimited
coredump(blocks) 4290772993
nofiles(descriptors) 5000
>
Try re-running your application. (Do not exit the shell in which you've just reset your limits.)
|
