2013年12月5日木曜日

続・HugePages_3

前回の「続・HugePages_2」の続きです。
前回はvm.nr_hugepagesはsga_targetの値を検討するところまででした。
今回は設定していきます。


1.vm.nr_hugepagesを設定します。
/etc/sysctl.confにvm.nr_hugepages=算出した値を記述します。
私の環境ではSGAを5GBと見積り、2560(5120MB/2)とします。
sysctl -p で反映します。


自動メモリ管理(AMM)環境とHugepagesの理解を深めるため、
寄り道をすると、
自動メモリ管理(AMM)環境で/dev/shmを使用している場合と、
Hugepagesを使用する場合には空きメモリの見え方が異なります。

■自動メモリ管理(AMM)環境(DB起動前)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020        558       9461          0         85        185
-/+ buffers/cache:        288       9732
Swap:        16383          0      16383


■自動メモリ管理(AMM)環境(DB起動後)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6078       3941          0         85       5400
-/+ buffers/cache:        592       9428
Swap:        16383          0      16383

DB起動後にはmemory_targetが6GBのためMemのfreeが6GB近く減少し、
usedが増えていますが、buffers/cacheのfreeに変化はありません。
/dev/shmにmemory_targetのファイルを作ったのでMemのusedが増えた。
というのがイメージできます。


▲Hugepages環境(DB起動前)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       5927       4093          0         85        425
-/+ buffers/cache:       5415       4604
Swap:        16383          0      16383

[root@s112040 /]# grep Huge /proc/meminfo
AnonHugePages:      6144 kB
HugePages_Total:    2560
HugePages_Free:     2560
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

▲Hugepages環境(DB起動後)
[root@s112040 /]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6001       4019          0         85        436
-/+ buffers/cache:       5479       4541
Swap:        16383          0      16383

[root@s112040 /]# grep Huge /proc/meminfo
AnonHugePages:     12288 kB
HugePages_Total:    2560
HugePages_Free:        5
HugePages_Rsvd:        5
HugePages_Surp:        0
Hugepagesize:       2048 kB

Hugepagesを獲得(sysctl -p)したタイミングでMemもbuffers/cacheも
freeが減少していますが、DBの起動による変化ありません。
Hugepagesとして獲得した領域をSGAが使いにいった感じがわかりますね。


では、寄り道を終えて、

2)DBの初期化パラメータを変更、反映します。

SQL> alter system set memory_target=0 scope=spfile;
システムが変更されました。

SQL> alter system set sga_target=5120 M scope=spfile;
システムが変更されました。

SQL> alter system set pga_aggregate_target=1024 M  scope=spfile;
システムが変更されました。

DBを再起動します。


これで完了!!!



・・・・と思いきや!


alert.logを確認すると

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5120 MB

Total Shared Global Region in Large Pages = 5120 MB (99%)

Large Pages used by this instance: 2560 (5120 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2560 (5120 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 5122 MB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
 at least 1 (page size 2048 KB, total size 2048 KB) system wide to
  get 100% of the System Global Area allocated with large pages
  2. Large pages are automatically locked into physical memory.
 Increase the per process memlock (soft) limit to at least 5130 MB to lock
 100% System Global Area's large pages into physical memory
********************************************************************


5122MB!?Hugepagesは5120MBしか用意していないので、
1ページ 2MB分をデフォルトのページ管理領域から取得しています。
SGAのサイズに合わせたのに。。
そもそも、memlockに5130MB設定しろって。。

試しに、hugepages_settings.shを実行して
hugepages構成の推奨値を確認してみると。。
[oracle@s112040 ~]$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 2565

2565ページ、5130 MB!?


[oracle@s112040 ~]$ ipcs -m

------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x00000000 327685     oracle     640        33554432   24
0x00000000 360454     oracle     640        5335154688 24
0x5bb52b60 393223     oracle     640        2097152    24

33554432/(2048*1024) =16
5335154688/(2048*1024) =2544
2097152/(2048*1024) =1

NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`

(1+16+1)+(2544+1)+(1+1)=2565

2565ページとなり、メモリに直すと530MBですね。

ちなみに、私の11.2.0.2環境では
------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x031e4588 688143     oracle     660        5370806272 21

5370806272/(2048*1024) =2561
(1+2561+1)=2563
Recommended setting: vm.nr_hugepages = 2563でした。

よくよくシェルを読むと、
# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1
むぐぐ・・・

このNUM_PGがないと、11.2.0.4.0では2564で11.2.0.2.0は2562。
そもも謎の+1ってなんだよ。。
謎の+1も省くと2561で両バージョンとも同じ値になります。

じゃ、その+1ページなんなんだよ!?

というのは今回追いきれませんでした。。。orz

vm.nr_hugepagesを2561に設定して起動すると、正常起動を確認出来ました。

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5122 MB

Total Shared Global Region in Large Pages = 5122 MB (100%)

Large Pages used by this instance: 2561 (5122 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 2561 (5122 MB)
Large Page size = 2048 KB
********************************************************************

今回SGA_TARGETを5GBから1GBまで1GBずつ減らして検証しましたが、
常にSGA_TARGET+2MB(1ページ)足りませんでした。
ipcs -mは計算してなかったのです、多分同じ傾向なのでしょうか。。



ということで、結論としては、

自動メモリ管理(AMM)を使用している環境から
Hugepagesを使用した環境に変更するには、

 2)hugepagesのページ数検討&設定
  2-1)sga_targetやpga_aggregate_targetの検討
  2-2)sga_targetやpga_aggregate_targetを設定
     memory_targetを0にしてDB再起動
     ※memory_max_targetが明示的に設定されている場合には、
       自動メモリ管理(AMM)が無効になったと判定されません。
       memory_max_targetを削除して下さい。
    
  2-3)hugepages_settings.shの実行
    または、ipcs -mのバイトを(2048*1024)で割った値の合計にて算出
  2-4)hugepagesのページの決定
 
 もしくは、2-2)、2-3)を省きた場合は、SGA_TARGET/2+1ページの値を設定


11.2.0.2.0の環境で、ざっくりSGA_TARGETを2で割った値で
vm.nr_hugepagesやmemlockを設定した環境では、
ひょっとしたらHugepageを全く使えてないかもしれません!?

まずはgrep Huge /proc/meminfoやalert.logを確認しみてはどうでしょうか?


次回は、気になるこいつ「AnonHugePages」に迫ります。


0 件のコメント:

コメントを投稿