Solaris Setup Guide for Altibase
This document provides guides for setting appropriate values of kernel parameters and various user environment settings for installing and operating Altibase in the Solaris Operating System. In this document, the guide is presented only for operating system related items to be set before Altibase is installed. For the Altibase property configuration file (altibase.properties) for Altibase self-configuration, refer to the separate document "Altibase Configuration File guide".
The test environment of this document is as follows:
ALTIBASE : Altibase 6 or later
OS : Sun OS 5.8 ~ 5.10
This section describes the types of kernel parameters that need to be changed when operating Altibase on the Solaris OS, and explains why the settings need to be changed.
The last part introduces how to change kernel parameters in Solaris.
When developing an application, two or more processes need to exchange information. The operating system provides a resource called IPC (Inter Process Communication). The memory area used by two or more processes to exchange information among various IPC resources is called shared memory.
The shared memory can be set by dividing it into one or more areas by designating a unit. One shared memory area is called a segment.
For example, a user may set a shared memory having one segment at 10 megabytes, or a 100 megabyte shared memory by configuring a 10-megabyte area as 10 segments.
Altibase loads memory DB in the heap area of the process by default, but it can be loaded and used in shared memory depending on the user's settings. (Refer to the "Altibase Property Setting Guide" document for the setting method related to this.) Alternatively, the communication buffer of the client accessing the DBMS can be set to be exchanged through the shared memory. Therefore, it is necessary to change the kernel parameter settings for the maximum size of the part that uses memory or the number of segments.
The kernel parameters related to shared memory in a typical Unix system are as follows.
|Kernel Parameter||Description||Recommended Value|
|shmmax||The maximum size of one shared memory segment||2G + 1|
|shmmni||The maximum number of shared memory segments in the system||500 or more|
|shmseg||The maximum number of processes that can access one shared memory||200 or more|
Considerations When Loading Memory DB into Shared Memory
When loading a memory DB into shared memory, the following items should be additionally considered:
In case of shmmax, one segment is created as much as the size of the STARTUP_SHM_CHUNK_SIZE item in the Altibase configuration file during the operation phase, so set it to a value larger than STARTUP_SHM_CHUNK_SIZE.
When memory DB usage increases, Altibase automatically increases the memory area. In this case, a set meant is also newly created. The size of this segment is set in the Altibase configuration file in EXPAND_CHUNK_PAGE_COUNT * 32K, so shmmni should be set as much as possible.
This is a kind of IPC resource like shared memory. The difference is that shared memory is provided as a way to share data between processes, while semaphores are resources provided by the operating system as a way to implement synchronization between processes. Synchronization means that only one process can access and change a specific resource or object at a time. (Unlike mutex, an inquiry is possible at the same time.)
Altibase uses shared memory as a communication buffer between the two ends when an Altibase server and a client exist in the local server as described above. At this time, it is necessary to control the concurrency of the memory. (Because it should not write at the same time.)
In this case, a semaphore operation occurs to control access to read/write access to memory.
Depending on the semaphore operation, the process can go into a waiting state or a progress state. Since these semaphore operations occur simultaneously, it is necessary to set the appropriate number of semaphores and kernel parameters for the operation.
The kernel parameters related to semaphore in the Unix system are as follows.
|Kernel Parameter||Description||Recommended Value|
|semmns||The maximum number semaphores in the system, and 16 bytes of kernel memory are allocated||8192|
|semmni||The maximum number of semaphore sets can be set within 65535, and 84 bytes of kernel memory is allocated per set.||5092|
|semmsl||The maximum number of semaphores in a set of semaphores and must be logically equal to or less than semmns. If set too large, several semaphore IDs can monopolize the entire system semaphore.||2000|
|semmap||Semaphore space obtained by semget call||5024|
|semmnu||The maximum number of undo structures in the system||1024|
|semopm||The maximum number of operations processed by semi system call||512|
|semume||The maximum number of undo entries per process||512|
|semvmx||Limits the maximum value of one semaphore and does not specify a value greater than 32767||32767|
How to Change
In Solaris, kernel parameters are set through the /etc/system file. Starting from 5.10, kernel parameters can be applied to each user account by introducing a project concept in addition to the existing method.
Here is an example of setting in both ways. Basically, access to the root account is required, and in order to apply properly, the system must be restarted after the change.
5.10 or later
In Solaris 5.10, some of the existing kernel parameter items have disappeared, so the user can run the configuration items related to shared memory and semaphores at the shell prompt using the Solaris utilities projadd and projmod.
Note that max-shm-memory should be set the maximum value of physical memory.
The user can check the setting change with the following command.