Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "detailed introduction of oracle rac kernel parameters". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Add the following lines to the / etc/sysctl.conf file

Kernel.shmall = 2097152

Kernel.shmmax = 4294967295

Kernel.shmmni = 4096

# semaphores: semmsl, semmns, semopm, semmni

Kernel.sem = 250 32000 100 128

Fs.file-max = 101365

Net.core.rmem_default = 262144

Net.core.rmem_max = 4194304

Net.core.wmem_default = 262144

Net.core.wmem_max = 1048586

Net.ipv4.ip_local_port_range = 1024 65000

For 11gR2

Fs.aio-max-nr = 1048576

Fs.file-max = 6815744

Kernel.shmall = 2097152

Kernel.shmmax = 4294967295

Kernel.shmmni = 4096

Kernel.sem = 250 32000 100 128

Net.ipv4.ip_local_port_range = 9000 65500

Net.core.rmem_default = 262144

Net.core.rmem_max = 4194304

Net.core.wmem_default = 262144

Net.core.wmem_max = 1048586

Note: if the existing value is greater than this value, do not modify it!

Then run the following command to make the above settings take effect

# / sbin/sysctl-p

Parameter description:

Kernel.shmall is physical memory divided by pagesize

Kernel.shmmax is half of physical memory

Fs.file-max multiplied by processes (65536 for 128process)

The three parameter settings of net.ipv4.ip_local_port_range/net.core.rmem_default/net.core.rmem_max are different from the official documentation, which is changed according to the latest requirements of metalink 343431.1.

In general, the two parameters of net.ipv4.tcp_rmem/net.ipv4.tcp_wmem do not need to be set, except in cases such as Dataguard/Streams that require a lot of network transmission.

Other parameters can be set according to the official documentation.

# Controls the maximum shared segment size, in bytes-General of physical memory

Kernel.shmmax = 68719476736

# Controls the maximum number of shared memory segments, in pages

Kernel.shmall = 4294967296-physical memory divided by pagesize

-- the above two parameters already exist. You only need to adjust the size of the parameters.

Kernel.shmmni = 4096

Kernel.sem = 250 32000 100 128

Fs.file-max = 327679

Net.core.rmem_default = 1048576

Net.core.rmem_max = 4194304

Net.core.wmem_default = 262144

Net.core.wmem_max = 1048586

Net.ipv4.ip_local_port_range = 9000 65500-this port starts at 9000

For 11gR2

Fs.aio-max-nr = 1048576

Fs.file-max = 6815744

Kernel.shmall = 2097152

Kernel.shmmax = 536870912

Kernel.shmmni = 4096

Kernel.sem = 250 32000 100 128

Net.ipv4.ip_local_port_range = 9000 65500

Net.core.rmem_default = 262144

Net.core.rmem_max = 4194304

Net.core.wmem_default = 262144

Net.core.wmem_max = 1048586

Note: if the value that already exists is greater than the setting here, do not modify it.

2. Kernel.shmmax parameters

2.1 description

SHMMAX Available physical memory Defines the maximum allowable size of one shared memory segment. The SHMMAX setting should be large enough to hold the entire SGA in one shared memory segment. A low setting can cause creation of multiple shared memory segments which may lead to performance degradation.

Shmmax is one of the most important parameters in the core parameters, which is used to define the maximum value of a single shared memory segment. The shmmax setting should be large enough to accommodate the entire SGA under one shared memory segment. Setting too low may lead to the need to create multiple shared memory segments, which may lead to system performance degradation.

SHMMAX is only a number used to compare when a shared memory segment is created. When a shared memory segment is created by a process (Process), the operating system checks whether the required value of the shared memory segment is greater than the value of shmmax. If so, an error will be thrown. At this point, the system creates one or more additional shared memory segments to meet the needs of the process. In general, the number of shared memory segments is not directly related to system performance, nor does it have much impact on performance.

During instance startup and Server Process creation, multiple small shared memory segments may cause slight system performance degradation at that time (multiple virtual address segments need to be created at startup, and there will be some impact when the process is created to "identify" multiple segments), but it will not be affected at other times. This means that if your program is not often Create Processes (and Destroy Them), performance is not a concern.

Oralce recommends SHMMAX > SGA (SGA_MAX_SIZE) so that there is no even slight performance degradation at any time.

2.2 exampl

As mentioned in the previous section, if shmmax is small and SGA,Oracle will create multiple shared memory segments, we can use Ipcs-sa to see the number of shared memory segments.

(1) View

[root@rac01 ~] # cat / etc/sysctl.conf | grep kernel.shmmax

Kernel.shmmax = 20971520

[root@rac01 ~] # ipcs-sa

-Shared Memory Segments-

Key shmid owner perms bytes nattch status

0x00000000 65537 oracle 640 4194304 27

0x00000000 98306 oracle 640 20971520 27

0x00000000 131075 oracle 640 20971520 27

0x00000000 163844 oracle 640 20971520 27

0x00000000 196613 oracle 640 20971520 27

0x00000000 229382 oracle 640 20971520 27

0x00000000 262151 oracle 640 20971520 27

0x00000000 294920 oracle 640 20971520 27

0xd2776b04 327689 oracle 640 20971520 27

-Semaphore Arrays-

Key semid owner perms nsems

0xfafd7074 360449 oracle 640 104

-Message Queues-

Key msqid owner perms used-bytes messages

Multiple shared memory segments are allocated because the kernel.shmmax setting is too small.

The following is a little bigger:

[root@rac01 ~] # cat / etc/sysctl.conf | grep kernel.shmmax

Kernel.shmmax = 2147483648

[root@rac01] # sysctl-p

[root@rac01 ~] # su-oracle

[oracle@rac01 ~] $sqlplus'/ as sysdba'

SQL*Plus: Release 10.2.0.1.0-Production on Mon Nov 16 05:50:00 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-Production

With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP

And Data Mining Scoring Engine options

SQL > startup force

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1218316 bytes

Variable Size 104859892 bytes

Database Buffers 58720256 bytes

Redo Buffers 2973696 bytes

Database mounted.

Database opened.

SQL > quit

Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-Production

With the Partitioning, Real Application Clusters, Oracle Label Security, OLAP

And Data Mining Scoring Engine options

Take another look:

[root@rac01 ~] # ipcs-sa

-Shared Memory Segments-

Key shmid owner perms bytes nattch status

0xd2776b04 360449 oracle 640 171966464 27

-Semaphore Arrays-

Key semid owner perms nsems

0xfafd7074 491521 oracle 640 104

-Message Queues-

Key msqid owner perms used-bytes messages

Only one memory segment is allocated

3. Kernel.shmall

The kernel.shmall parameter controls the number of pages in shared memory. The parameter size is physical memory divided by pagesize

View the size of the os system page

# getconf PAGESIZE

4096

The pagesize shown here is 4k. Assuming that the maximum size of a shared memory segment is 16g, then the number of pages of shared memory needs to be 16GB/4KB=16777216KB/4KB=4194304 (pages), that is, 16GB physical memory under 64Bit system. Set kernel.shmall = 4194304 to meet the requirement, which is almost double the original setting of 2097152.

4. Kernel.shmmni parameters

The shmmni kernel parameter is the maximum number of shared memory segments (note that this parameter is not shmmin, but

Shmmni, where shmmin represents the minimum memory segment size. The default value of shmmni is 4096, which is generally sufficient.

5. Fs.file-max parameters

Fs.file-max is 512 times processes.

If there are 128process, then file-max=512*128=65536.

6. Parameters that need to be adjusted under Oracle

A very important parameter has been introduced in Oracle 10g: SGA_TARGET, which is also a new feature of Oracle 10g. Automatic shared memory Management (Automatic Shared Memory Management ASMM), which is controlled only by this parameter SGA_TARGE. After setting this parameter, you do not need to specify the size for each memory area. SGA_TARGET specifies the maximum amount of memory that SGA can use, while the size of each memory in SGA is controlled by Oracle itself and does not need to be artificially specified.

Oracle can adjust the size of each area at any time to achieve the most reasonable size of the best performance of the system, and control the sum of them within the value specified by SGA_TARGET. Once a value is assigned to SGA_TARGET (default is 0, that is, ASMM is not started), ASMM is started automatically

Properties.

After starting the ASSM feature after setting SGA_TARGET under 10g, only the memory size of the following areas is dynamically shared:

* Buffer cache (DB_CACHE_SIZE)

* Shared pool (SHARED_POOL_SIZE)

* Large pool (LARGE_POOL_SIZE)

* Java pool (JAVA_POOL_SIZE)

* Streams pool (STREAMS_POOL_SIZE)

The memory size of other areas in the SGA is still fixed and unshared. It has the same meaning as SGA_MAX_SIZE, and also represents the maximum size of SGA, so it has a limitation that its size cannot be larger than the size of SGA_MAX_SIZE.

Under Oracle10g, SGA_MAX_SIZE still represents the upper limit of the size of SGA, while SGA_TARGET is the sum of the maximum size of all components of SGA, that is, when SGA_TARGET < SGA_MAX_SIZE, oracle ignores the value of SGA_MAX_SIZE, and SGA_TARGET becomes the upper limit of SGA in this instance. It can change the size dynamically, but it cannot be greater than the value of SGA_MAX_SIZE.

When SGA_TARGET < SGA_MAX_SIZE, the SGA_MAX_SIZE becomes the size of SGA_TARGET after the instance is restarted.

In 11g, this SGA_TARGET can only be set to be equal to the size of SGA_MAX_SIZE, the setting is smaller than it, oracle will automatically adjust it for you, and the setting is larger than it, which is still a mistake. Now you can think for yourself that oracle's size handling of SGA_TARGET is moving in the right and simple direction.

An important benefit of SGA_TARGET is that it optimizes the utilization of SGA, thereby saving memory costs. Because after ASMM starts, Oracle will automatically adjust the size of each area as needed, which greatly reduces the shortage of memory in some areas and the contradiction that memory is idle in some areas.

Detailed description of each parameter:

Kernel.shmmax:

Is one of the most important core parameters that defines the maximum value of a single shared memory segment. The setting should be large enough to accommodate the entire SGA under one shared memory segment, and a low setting may result in the need to create multiple shared memory segments, which may lead to system performance degradation. The main reason for the system decline is that when the instance is started and the ServerProcess is created, multiple small shared memory segments may lead to a slight degradation of system performance at that time (multiple virtual address fields need to be created at startup, and there will be some impact when the process is created to let the process "identify" multiple segments), but it will not be affected at other times.

Official recommended values:

32-bit linux system: the maximum preferred value is 4GB (4294967296bytes)-1byte, which is 4294967295. The recommended value is more than half of the memory, so if 32 is the system, the value is generally 4294967295. 32-bit systems have limits on the size of the SGA, so the SGA can certainly be included in a single shared memory segment.

64-bit linux system: the maximum preferred value is physical memory value-1byte, and the recommended value is more than half of physical memory. Generally, the value is greater than SGA_MAX_SIZE, and you can take physical memory-1byte. For example, if it is 12GB physical memory, the preferred 12884901887 memory will definitely be included in a single shared memory segment.

Kernel.shmall:

This parameter controls the total number of pages of shared memory that can be used. The page size of Linux shared memory is 4KB, and the size of shared memory segments is an integral multiple of the size of shared memory pages. The maximum size of a shared memory segment is 16G, so the number of pages of shared memory needs to be 16GB/4KB=16777216KB / 4KB=4194304 (pages), that is, 16GB physical memory under 64Bit system. Set kernel.shmall = 4194304 to meet the requirement (almost double the original setting of 2097152). At this time, the shmmax parameter can be adjusted to 16G, and the SGA_MAX_SIZE and SGA_TARGET can be changed to 12G (the maximum size of SGA you want to set, of course, can also be 2G~14G, etc., and coordinate the use of PGA parameters and other memory such as OS. Do not set too full, for example, 16G).

Kernel.shmmni:

This parameter is the maximum number of shared memory segments. The default value of shmmni is 4096, which is generally sufficient.

Fs.file-max:

This parameter determines the maximum number of file handles allowed in the system, and the file handle setting represents the number of files that can be opened in the linux system.

Fs.aio-max-nr:

This parameter limits the concurrency of outstanding requests and should be set to avoid the failure of the Istroke O subsystem.

Kernel.sem:

Take kernel.sem = 250 32000 100128 as an example:

250 is the value of the parameter semmsl, indicating the maximum number of semaphores that can be contained in a semaphore set.

32000 is the value of the parameter semmns, indicating the maximum number of semaphores allowed in the system.

100 is the value of the parameter semopm, which represents the number of operations that a single semopm () call can perform on a semaphore set.

The value of the parameter semmni represents the total set of system semaphores.

Net.ipv4.ip_local_port_range:

Represents the range of IPv4 ports that the application can use.

Net.core.rmem_default:

The default value that represents the size of the socket receive buffer.

Net.core.rmem_max:

Represents the maximum size of the socket receive buffer.

Net.core.wmem_default:

The default value that represents the size of the socket send buffer.

Net.core.wmem_max:

Represents the maximum size of the socket send buffer.

This is the end of "detailed introduction to oracle rac kernel parameters". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.