[20191202]關於oracle例項是否使用hugepages問題.txt

[20191202]關於oracle例項是否使用hugepages問題.txt

--//前幾天論壇的討論,別人問我為什麼什麼依據判斷是否使用hugepages問題,實際上我也不知道.
--//我自己也在想如何判斷oracle例項是否使用hugepages的問題.自己也做一點總結:

1.檢查/proc/meminfo的輸出:
# grep -i page /proc/meminfo
AnonPages:         90672 kB
PageTables:         5956 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

--//這是最直觀的方式,但是如果你伺服器啟動多了例項,那些例項使用,那些沒有透過這個就很難判斷.
--//而且還有一個問題,oracle現在可以設定use_large_pages=true,false,auto,only.

--//你查詢引數use_large_pages,描述上說明Use large pages if available (TRUE/FALSE/ONLY),預設就是true,如果設定false,實際上
--//就不用.
如果引數為True，那麼當系統的HugePage被使用盡，只有small pages的情況下，SGA也會繼續執行。此時，Oracle例項就執行在記憶體使用
混合模式(Mixed Mode)下。

如果引數為是Only，從含義上，表示Oracle例項只會使用HugePage作為記憶體使用。如果系統在AMM模式或者HugePage用盡的時候，資料庫
就不能啟動或者報錯。

如果引數為是false,就不使用HugePage.

2.使用smem觀察:
--//僅僅觀察例項對應的後臺程式的透過smem查詢發現.USS佔用很大,基本可以確定沒有使用.
# smem -tk  -U oracle -P "ora_.*_xxxxx1"
  PID User     Command                         Swap      USS      PSS      RSS
.....
21557 oracle   ora_mman_xxxxx1                    0   348.1M   687.7M     2.5G
21561 oracle   ora_dbw1_xxxxx1                    0   120.5M     1.0G     4.9G
21559 oracle   ora_dbw0_xxxxx1                    0   117.0M     1.1G     5.2G
21563 oracle   ora_dbw2_xxxxx1                    0   119.7M     1.1G     5.2G
21565 oracle   ora_dbw3_xxxxx1                    0   135.5M     1.1G     5.2G
21545 oracle   ora_lms1_xxxxx1                    0   755.5M     2.0G     6.9G
21541 oracle   ora_lms0_xxxxx1                    0   764.7M     2.1G     7.0G
21549 oracle   ora_lms2_xxxxx1                    0   791.2M     2.2G     7.4G
-------------------------------------------------------------------------------
   54 1                                           0     3.6G    12.6G    54.4G
--//而使用hugepages根本看不到這樣的情況.當然僅僅時經驗之談,只要執行有一段時間,都可以看到這樣的情況.

3.檢視alert*.log檔案:
--//資料庫啟動時檢視alert日誌,可以發現如下資訊:
Fri Nov 29 10:10:47 2019
Adjusting the default value of parameter parallel_max_servers
from 480 to 170 due to the value of parameter processes (200)
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Parameter use_large_pages = ONLY
Per process system memlock (soft) limit = 51 GB
Total Shared Global Region in Large Pages = 618 MB (100%)
Large Pages used by this instance: 309 (618 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 309 (618 MB)
Large Page size = 2048 KB
********************************************************************

4.檢視/proc/<spid>/numa_maps相關資訊:
$ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'huge dirty=' /proc/Q/numa_maps
60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=25 N0=1
60c00000 default file=/SYSV00000000\040(deleted) huge dirty=35 mapmax=25 N0=28 N1=7
86800000 interleave:0-1 file=/SYSVe8a8ec10\040(deleted) huge dirty=1 mapmax=25 N0=1
--//也就是查詢共享記憶體段時候包含huge dirty
--//補充執行以下命令更為準確.
$ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep "SYSV" /proc/Q/numa_maps

5.檢查oracle引數:
SYS@book> show parameter memory_
NAME                     TYPE        VALUE
------------------------ ----------- -------
hi_shared_memory_address integer     0
memory_max_target        big integer 0
memory_target            big integer 0
shared_memory_address    integer     0
--//檢查memory_*引數是否是0,不過這個並不能確定是否使用hugepages,僅僅能確定有可能.

6.問題:
--//問題在於如果是混合模式,以上判斷可能就不是很準.僅僅能判斷是否使用hugepages.
--//修改/etc/sysctl.conf如下:
vm.nr_hugepages = 104
vm.nr_overcommit_hugepages = 0

--//修改引數*.use_large_pages='TRUE'.
--//重啟啟動資料庫,alert提示如下:
Mon Dec 02 08:50:18 2019
Adjusting the default value of parameter parallel_max_servers
from 480 to 170 due to the value of parameter processes (200)
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 51 GB
Total Shared Global Region in Large Pages = 208 MB (33%)
Large Pages used by this instance: 104 (208 MB)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 104 (208 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 618 MB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
 at least 205 (page size 2048 KB, total size 410 MB) system wide to
  get 100% of the System Global Area allocated with large pages
********************************************************************
--//僅僅從alter看到相關資訊使用hugepages,而且是混合模式.

$ grep -i page /proc/meminfo
AnonPages:        149212 kB
PageTables:        14540 kB
AnonHugePages:         0 kB
HugePages_Total:     104
HugePages_Free:       51
HugePages_Rsvd:       51
HugePages_Surp:        0
Hugepagesize:       2048 kB

$ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'huge.*dirty=' /proc/Q/numa_maps
60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=20 N0=1

$ ps -ef | grep "[o]ra_pmon_.*" | awk '{print $2}' | xargs -IQ grep 'SYSV' /proc/Q/numa_maps
60000000 default file=/SYSV00000000\040(deleted) huge dirty=1 mapmax=20 N0=1
60c00000 default file=/SYSV00000000\040(deleted) huge
6a400000 default file=/SYSV00000000\040(deleted) huge
6c400000 default file=/SYSV00000000\040(deleted) huge
6cc00000 default file=/SYSV00000000\040(deleted) huge
6d000000 interleave:0-1 file=/SYSV00000000\040(deleted) dirty=737 mapmax=20 active=128 N0=372 N1=365
86800000 interleave:0-1 file=/SYSVe8a8ec10\040(deleted) dirty=1 mapmax=20 N1=1
--//這樣查詢更為準確.

$ ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 411860993  oracle    640        12582912   20
0x00000000 411893762  oracle    640        159383552  20
0x00000000 411926531  oracle    640        33554432   20
0x00000000 411959301  oracle    640        8388608    20
0x00000000 411992070  oracle    640        4194304    20
0x00000000 412024839  oracle    640        427819008  20
0xe8a8ec10 412057608  oracle    640        2097152    20

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x6aa88594 334462976  oracle    640        204

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

--//這樣可以發現hugepages的共享記憶體段被分割好幾段,實際上我這裡是5段.

$ sysresv
IPC Resources for ORACLE_SID "book" :
Shared Memory:
ID              KEY
411860993       0x00000000
411893762       0x00000000
411926531       0x00000000
411959301       0x00000000
411992070       0x00000000
412024839       0x00000000
412057608       0xe8a8ec10
Semaphores:
ID              KEY
334462976       0x6aa88594
Oracle Instance alive for sid "book"

$ ps -ef | grep pmo[n]
oracle   54880     1  0 08:50 ?        00:00:00 ora_pmon_book

$ pmap -x 54880  | grep "SYSV\|shm\|^Address"
Address           Kbytes     RSS   Dirty Mode   Mapping
0000000060000000   12288       0       0 rw-s-  SYSV00000000 (deleted)
0000000060c00000  155648       0       0 rw-s-  SYSV00000000 (deleted)
000000006a400000   32768       0       0 rw-s-  SYSV00000000 (deleted)
000000006c400000    8192       0       0 rw-s-  SYSV00000000 (deleted)
000000006cc00000    4096       0       0 rw-s-  SYSV00000000 (deleted)
000000006d000000  417792    2948    2948 rw-s-    [ shmid=0x188f0007 ]
0000000086800000    2048       4       4 rw-s-    [ shmid=0x188f8008 ]

--//這樣看來如果處於混合模式,使用smem檢視的經驗也未必準確,最佳的方式是檢視alert啟動日誌以及查詢
--///proc/<spid>/numa_maps包含相關SYSV相關行資訊.