1. Planning system users
Modify the user name and rename the user name "gaussdba" to "gauss".
usermod -l gauss gaussdba
Lock the "gauss" user so that it cannot log in.
usermod -L gauss
Unlock the "gauss" user account so that it can log in.
usermod -U gauss
Check if the account has expired
chage -l gauss
Set the account to never expire
chage -M 99999 gauss
delete users
userdel -r gauss
Description:
- The userdel command can delete user accounts and related files. If no parameter is added, only the user account will be deleted, and the related files will not be deleted.
- Before deleting a user account, make sure that GaussDB has been uninstalled.
2. Set up shared memory and semaphores
Background Information
- GaussDB uses a semaphore max_connections for each allowed connection . It has a set of 16, and each set also contains the 17th semaphore, which stores a "magic number" to detect whether it conflicts with other semaphore sets.
- If this mechanism is missing, an Illegal system call error will occur when the server starts, and the kernel can only be reconfigured at this time.
- GaussDB will refuse to start if it exceeds one of the hard limits of IPC resources and will leave an error message telling you what problems it encountered and what needs to be done for it.
- Need to restart the machine or recompile the kernel to modify these settings.
| Parameter name | Parameter Description | Reasonable value |
| SHMMAX | Maximum shared memory segment size (bytes) | Please refer to the parameter description in this article. |
| SHMMIN | Minimum shared memory segment size (bytes) | 1 |
| SHMALL | The total amount of available shared memory (bytes or pages) | If it is a byte, the value is the same as SHMMAX, if it is a page, the value is ceil (SHMMAX/PAGESIZE). Description: You can use the getconf PAGESIZE command to view the number of bytes in a page. |
| SHMSEG | Maximum number of shared memory segments per process | Only 1 segment is required. |
| SHMMNI | Maximum number of shared memory segments system-wide | Similar to SHMSEG plus space for other applications. |
| SIGNS | Maximum number of signal sets | ceil(max_connections/16)。 |
| SEMMNS | Maximum number of semaphores system-wide | ceil(max_connections/16)*17 plus space for other applications. |
| SEMMSL | Maximum number of signal lights per set of signal lights | 17。 |
| SEMMAP | Number of records in the semaphore map | Please refer to the parameter description in this article. |
| SEMVMX | Maximum value of semaphore | The default is 32767. |
Parameter description :
-
SHMMAX
is the size of the maximum shared memory segment recorded in bytes. If you receive an error message such as Invalid argument from shmget, it is likely to exceed the limit of this parameter. -
SHMALL
This value is equal to the combination of GaussDB plus other applications that use shared memory segments. -
Note:
SHMALL uses the number of pages on many systems, not the number of bytes. -
The parameter SHMMIN is about 500KB for GaussDB. -
The parameter SEMMNS sets the maximum number of semaphores in the system. This value should be at least as large as the max_connections setting, and one should be added for every 16 connections (see Table System V IPC parameters). -
The parameter SEMMNI determines the number of semaphore sets that can exist in the system at one time. It should be at least ceil(max_connections / 16). -
The SEMMA
parameter determines the size of the space for storing the semaphore mapping. Each semaphore has a mapping in this space. If this space is filled with fragments, the available semaphore will be less than it should be. -
The parameter SEMMSL determines how many signal lights can be in a set of signal lights, and it is 17 in GaussDB.
Problem : The default settings are only suitable for small installations (default maximum shared memory is 1024MB). The maximum shared memory segment can be set in two ways. For example, to set the maximum shared memory segment to 4G or 1048576 pages, there are two methods as follows.
Method 1: Use sysctl interface to set, the operation steps are as follows.
Log in to the Linux operating system as the root user. Use the sysctl interface to modify.
sysctl -w kernel.shmmax=4294967296
sysctl -w kernel.shmall=1048576
Method 2: Modify the sysctl.conf file, the operation steps are as follows.
Log in to the Linux operating system as the root user. Open sysctl.conf with vi editor, and add the following kernel parameters.
vi /etc/sysctl.conf
kernel.shmmax = 4294967296
kernel.shmall = 1048576
Execute the following command to automatically read the kernel parameters when Linux starts.
/sbin/chkconfig boot.sysctl on
Execute the following commands to make the kernel parameters take effect.
/sbin/sysctl -p
3. Set resource limits
The Linux kernel usually has some system-wide resource restrictions, which can interfere with the operation of the GaussDB server.
Background Information
- Some systems allow independent processes to open many files. If many processes open many files at the same time, the upper limit specified by the system will soon be reached. At this time, you can set the max_files_per_process configuration parameter of GaussDB to limit the maximum number of open files per process.
- The maximum number of files that the system can open is fixed during the compilation of the Linux kernel. Each connection to the GaussDB server uses one process, so the maximum number of files that can be opened should be equal to the number of processes plus the number required by other parts of the system.
Problem : There are two ways to set the maximum number of files that the system can open.
Method 1: Modify the file-max file, the operation steps are as follows.
Log in to the Linux operating system as the root user. Modify the file-max file.
vi /proc/sys/fs/file-max
Method 2: Add the fs.file-max parameter in /etc/sysctl.conf, the operation steps are as follows.
Log in to the Linux operating system as the root user. Add this parameter in the kernel configuration file "/etc/sysctl.conf".
vi /etc/sysctl.conf
fs.file-max = 4866970
Execute the following command to automatically read the kernel parameters when Linux starts.
/sbin/chkconfig boot.sysctl on
Execute the following commands to make the kernel parameters take effect.
/sbin/sysctl -p
4. Set Overcommit for Linux memory
To avoid running out of virtual memory and causing the termination of the GaussDB server process, you need to set the Linux memory overcommit.
Background information
If the kernel terminates the GaussDB server process due to memory pressure, you will see kernel information like the following:Out of Memory: Killed process 12345 (gaussdb)At this time, the existing data connection will operate normally, but the new connection cannot be established. Restarting GaussDB can solve the problem. However, to avoid this problem, you need to run GaussDB on a machine with sufficient memory, or to modify the memory behavior to solve it.
Problem : There are two ways to modify the behavior of memory.
Method 1: Use sysctl to select a strict overcommit mode, the operation steps are as follows.
Log in to the Linux operating system as the root user. Set the submission mode, the command is as follows.
/sbin/sysctl -w vm.overcommit_memory=2
Method 2: Set the vm.overcommit_memory parameter in /etc/sysctl.conf, the operation steps are as follows.
Log in to the Linux operating system as the root user. Use the vi editor to write the vm.overcommit_memory configuration parameter to sysctl.conf, the command is as follows:
vi /etc/sysctl.conf
vm.overcommit_memory = 2
Execute the following command to automatically read the kernel parameters when Linux starts.
/sbin/chkconfig boot.sysctl on
Execute the following commands to make the kernel parameters take effect.
/sbin/sysctl -p
5. Examples
The database cannot be started, the error is as follows
**FATAL**: could not create semaphores: 设备上没有空间（pg_sema.c:123）
**DETAIL**: Failed system call was semget (5432129.17.03600)
**HINT**: This error does "not" mean that you have run out of disk...(SEMMNS)...(SEMMIN)...
Solution
vim /etc/sysctl.conf
# 追加或修改
kernel.sem = 250 256000 32 1024
# 加载生效
sysctl -p