• Processes / Threads
• Files / Sockets
• Sys V IPC Semaphores
• Sys V IPC Shared memory
• Process memory / Address space

• Changes compared to Eloquence 7.xx

The following sections discuss HP-UX kernel parameters involved.

You may have to increase some of the HP-UX kernel parameters beyond the default values, depending on your number of eloqdb servers and their eloqdb.cfg settings like Threads or BufferCache, for example.

Note that the discussion below only explains the requirements for the eloqdb database server(s). When adjusting kernel parameters, you need to also take into account any requirements by other applications as well as the operating system itself. So you will typically add to existing settings, to be on the safe side.

Processes / Threads

• nproc - limits the number of processes allowed to exist simultaneously
• maxuprc - limits the maximum number of concurrent user processes per user
• nkthread - limits the number of threads allowed to run simultaneously
• max_thread_proc - defines the maximum number of concurrent threads allowed per process.

Each eloqdb server process creates a small number of internal OS threads, typically below 10, and one additional OS thread for every concurrent DB client connection (regardless of the number of DBOPENs by each client).

Use

nkthread        >= SUM of "10 + max number of clients (Threads)" per eloqdb
max_thread_proc >= MAX of "10 + max number of clients (Threads)" per eloqdb

For example:

eloqdb server A: Threads = 1000
eloqdb server B: Threads =  300
eloqdb server C: Threads =  200

nkthread        >= 1530  ( 3*10+1000+300+200 )
max_thread_proc >= 1010  ( 10+1000 )

• maxfiles_lim - hard maximum number of file descriptors per process

The default maxfiles_lim by HP-UX is typically sufficient, unless you have a server with a very large maximum number of concurrent clients.

Sys V IPC semaphores

• semmns - number of System V IPC system-wide semaphores
• semmni - number of System V IPC system-wide semaphore identifiers
• semmnu - maximum number of System V IPC undo structures for processes
• semume - maximum number of System V IPC undo entries per process

When using Sys V IPC semaphores, the eloqdb server allocates a semaphore identifier with 2 semaphores for each concurrent client connection and also makes use of SEM_UNDO operations for each of these client sessions.

Unless you have a large number of eloqdb servers, the HP-UX default for semmnu will typically be sufficient. However, you may need to increase the semmns, semmni and especially the semume setting in some cases.

Use

semmni >= SUM of "max number of clients (Threads)" per eloqdb
semmns >= SUM of 2 * "max number of clients (Threads)" per eloqdb
semmnu >= number of eloqdb servers
semume >= MAX of "max number of clients (Threads)" per eloqdb

For example:

eloqdb server A: Threads = 1000
eloqdb server B: Threads =  300
eloqdb server C: Threads =  200

semmni >= 1500  ( 1000+300+200 )
semmns >= 3000  ( 2*1000+2*300+2*200 )
semmnu >= 3
semume >= 1000

• shmmni - number of System V shared memory segment identifiers in the system
• shmmax - maximum size (in bytes) for a System V shared memory segment
• shmseg - maximum number of System V shared memory segments per process

For EnableIPC=2 (the default) the eloqdb server allocates a single shared memory segment for communicating with local database clients. The segment size depends on the configured max number of clients, ie [config] Threads. For EnableIPC=1 the eloqdb server allocates a separate 32 KB segment for each database client.

Unless you have a large number of eloqdb servers or use EnableIPC=1, the HP-UX defaults for shmmni and shmseg will typically be sufficient.

With EnableIPC=2 use

shmmni >= number of eloqdb servers

shmmni >= SUM of "max number of clients (Threads)" per eloqdb
          plus number of eloqdb servers

shmseg >= MAX of "max number of clients (Threads)" per eloqdb

Process memory / Address space

• maxdsiz, maxdsiz_64bit - maximum size (in bytes) of the data segment for any user process
• max_mem_window - maximum number of group-private 32-bit shared memory configurable by users

The data segment sizes of processes are limited by the maxdsiz or maxdsiz_64bit kernel parameters. For 32-bit processes there are also architecture-specific limitations on the address space available for global shared memory segments.

The 32-bit eloqdb servers allocate stack space for OS level threads handling concurrent client sessions from their data segment and memory for the dedicated BufferCache from the shared memory address space. Depending on your eloqdb server with the largest number of concurrent client sessions (limited by [Config] Threads), you may need to increase the maxdsiz parameter or switch to using the 64-bit eloqdb program.

Depending on your number of eloqdb server instances and their settings for [Config] BufferCache, you may also run into limits or fragmentation issues with the global shared memory address space. This may require to switch to using HP-UX memory windows or the 64-bit eloqdb program.

The 64-bit eloqdb servers do not only allocate stack space for OS level threads handling concurrent client sessions from their data segment, but also allocate memory for the dedicated BufferCache this way. They only use shared memory for the client communication (with EnableIPC >= 0).

Depending on your eloqdb server settings for [Config] Threads as well as [Config] BufferCache, you may need to increase the maxdsiz_64bit.

Note that the BufferCache memory is allocated during startup of the eloqdb server process whereas the stack space for OS level threads handling concurrent client sessions grows as these sessions connect.

Note that HP-UX on PA-RISC uses 64 KB stack size per thread, whereas HP-UX on Itanium uses 256 KB stack size per thread.

Changes compared to Eloquence 7.xx

• Eloquence B.08.00 database and newer require the HP-UX evp driver enabled in the kernel configuration. The following commands may be used to verify if the evp driver is configured:

  lsdev -C pseudo | grep evp
  ls /dev/poll
  

  If the evp driver is configured it is listed in the lsdev output and the /dev/poll device file is present. If not, the evp driver needs to be enabled in the kernel configuration or the database server will not start.

• As of Eloquence B.08.00 the database server now uses HP-UX OS level threads, configuration of some thread related kernel parameters is required. This affects the max_thread_proc and nkthread kernel parameters.

• When IPC communicaton is used with the database server (enabled by default) Eloquence B.08.00 and newer differ in SYSV semaphore use.

  Previous Eloquence releases used a separate semaphore set with a single semaphore for each active database connection.

  As of B.08.00 a separate semaphore set with two semaphores is used for each active connection. This may require updating the semmns kernel parameter.

• Eloquence B.08.00 database server and newer may use additional memory for the same configuration. Some of the internal data structures now include additional lock objects and existing lock objects have grown in size. Also, the stack size for internal threads has grown noticeably. This may require increasing the maxdsiz kernel parameter for the 32 bit database server.

  Please note that for B.07.10 the internal stack for each worker thread was allocated on database server startup. As of B.08.00 the thread stack is allocated upon establishing the connection.

• When using the 64 bit database server with B.08.00 or newer the maxdsiz_64bit kernel parameter may need to be configured. Please notice that the 64 bit database server has higher memory requirements than the 32 bit server (using the same configuration).

  Also, the configured buffer cache size must be considered in the maxdsiz_64bit kernel parameter. This is different from the 32 bit database server where the buffer cache is not allocated from the data size.

Find more details in the HP-UX kernel config section of the Eloquence 8.0 Release Notes.