Setting a large memory page on Linux solves the problem that the kswapd0 process consumes cpusys in transition.

Setting a large memory page on Linux solves the problem that the kswapd0 process consumes cpusys in transition.

Environment: SLES11 SP4 + Oracle 11.2.0.4

After a new test database was set up and ran for about two days, it was found that a process named kswapd0 actually occupied 1 cpu resource (the host has only 2 CPUs in total ), and almost all of them are consumed on cpusys.
As shown in:
Figure 1




Online Search shows that kswapd0 is a kernel process used to process page switching. When the available memory of the OS is smaller than the threshold value, kswapd switches pages of some processes from the physical memory to swap, how to determine the threshold value is still fruitless, at least in SLES 11, I have dispelled the solution to stop the kswapd0 process from actively consuming cpusys by modifying the threshold value.


Starting from the database, first check whether the SGA is locked in the memory.
SQL> show parameter lock_sga


NAME TYPE VALUE
----------------------------------------------------------------------------------------
Lock_sga boolean TRUE
SQL>


On the OS layer, double check again. It is indeed locked.
Oracle @ cspdb1: ~> Ipcs-m


------ Shared Memory Segments --------
Key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 29 locked <-- it is indeed locked.
0x00000000 229380 oracle 640 1560281088 29 locked
0xf8e2566c 262149 oracle 640 2097152 29 locked


The OS-level physical memory check is still idle, but the real swap action does not occur many times, or the application will complain long ago.

Figure 4


Figure 5



From the above check results, we can preliminarily judge that the database's SGA is indeed locked in the physical memory. Although kswapd0 has worked hard (taking up one cpu resource) but few pages are generated (few pages are generated by swap)


This server has no other applications except oracle db, and there are only dozens of sessions on the db. Therefore, the maximum memory space is SGA, I think of the fact that I used to enable a large memory page on AIX. The biggest benefit is that it provides continuous page blocks with a larger size, which reduces the memory usage of the page table and accelerates the page table search speed, another benefit is that a large memory page will never be swap out.


To eliminate that SGA may be swapped out of the physical memory or at least avoid unnecessary scanning by the kswapd0 process on the SGA region to detect whether a page can be swap out, follow the steps below to enable the Large Memory Page


### 1. Set/etc/security/limits. conf and check after setting
* Soft memlock unlimited
* Hard memlock unlimited


--- Run the oracle logon host to check whether the above settings take effect
Oracle @ cspdb1: ~> Ulimit-Hl
Unlimited
Oracle @ cspdb1: ~> Ulimit-Sl
Unlimited


### 2. Check whether AMM is enabled because AMM and lock_sga are incompatible.
Set linesize 100
Col name format a30
Col value format a30
Select name, value from v $ system_parameter where name in ('memory _ target', 'memory _ max_target ', 'lock _ sga ');


NAME VALUE
------------------------------------------------------------
Lock_sga TRUE
Memory_target 0
Memory_max_target 0


--- If the AMM parameter or lock_sga settings do not meet the requirements, perform the following steps to reset
SQL> alter system reset memory_max_target;


SQL> alter system reset memory_target;


SQL> alter system set lock_sga = true scope = spfile;


### 3. Set a large Memory Page
--- Calculate the number of large memory pages. Make sure that the instance is at least started to nomount when performing this step.
Oracle @ cspdb1: ~> Ipcs-m


------ Shared Memory Segments --------
Key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 29 locked
0x00000000 229380 oracle 640 1560281088 29 locked
0xf8e2566c 262149 oracle 640 2097152 29 locked


Oracle @ cspdb1: ~> Cat/proc/meminfo | grep Hugepagesize
Hugepagesize: 2048 kB


Hugepages = (16777216/2048/1024 + 1) + (1560281088/2048/1024 + 1) + (2097152/2048/1024 + 1) = 756


--- Add in/etc/sysctl. conf
Vm. nr_hugepages = 756


### 4. Restart the database instance and host and check whether the large memory page settings take effect
Sqlplus '/as sysdba'
Shutdown immediate


Init 6


Cspdb1 :~ # Sysctl-n vm. nr_hugepages
756


Oracle @ cspdb1: ~> Grep HugePages/proc/meminfo
AnonHugePages: 45056 kB
HugePages_Total: 756
HugePages_Free: 756
HugePages_Rsvd: 0
HugePages_Surp: 0


Startup


Oracle @ cspdb1: ~> Ipcs-m


------ Shared Memory Segments --------
Key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 27 <--- the status changes from locked to null, which means that the huge page will not be swapout by nature, so do not care about the lock_sga settings :)
0x00000000 229380 oracle 640 1560281088 27
0xf8e2566c 262149 oracle 640 2097152 27


Cspdb1 :~ # Grep HugePages/proc/meminfo
AnonHugePages: 67584 kB
HugePages_Total: 756
HugePages_Free: 623 <--- Free <Total, indicating that a huge page has been used.
HugePages_Rsvd: 620
HugePages_Surp: 0




The kswapd0 process has not been bubbling in the past week. For details, see
Figure 6



Here is my guess about the cause: When SGA is in the memory as a normal page, although lock_sga = TRUE, however, the kswapd0 process is still unable to block the continuous scanning of the sga memory area. Of course, no page will be swap out Because lock_sga = TRUE. However, there are many kernel-level calls in this process, so the kswapd0 process will occupy a large amount of cpusys resources. Therefore, the thorough method is to enable the Large Memory Page.

This article permanently updates the link address: