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」に迫ります。


続・HugePages_2

折角HugePagesネタを久しぶりに書いたので、
Oracle社のマニュアルよりもグーグルの上位に立つため、
前回の「続・HugePages_1」に書ききれなかった、
Hugepagesネタに関する雑多な内容を書こうと思います。


Oracle® Database管理者リファレンス11.2では、
以下の様な設定手順が書かれていますが、
実際にはそんなに思い通りにはいかないこともあります。

1)memlockの設定変更
2)hugepagesのページ数検討&設定
3)DB再起動により獲得

しかしながら、自動メモリ管理(AMM)を使用している環境を考えた場合、
現実的には2)の部分をもう少し考える必要があります。

共有メモリー・セグメントのhugepages構成の推奨値を計算するスクリプトですが、
自動メモリ管理(AMM)環境では以下の様な出力になります。

[oracle@s112040 ~]$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 1
ん?1ページなの?となります。

hugepages_settings.shスクリプトの内容を確認すれば分かりますが、
ipcs -mの結果を元にvm.nr_hugepagesを算出しています。

[oracle@s112040 ~]$ ipcs -m
------ 共有メモリセグメント --------
キー     shmid      所有者  権限     バイト  nattch     状態
0x00000000 1114117    oracle     640        4096       0
0x00000000 1146886    oracle     640        4096       0
0x5bb52b60 1179655    oracle     640        4096       0
※SEG_BYTESは4096となる。

この結果から、SEG_BYTESは4096となり、HPG_SZは2048のため、
echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -qの結果は0となり、
if文を抜けて、初期値の1が出力されたことが分かります。

SEG_BYTESが4096となっているのは、自動メモリ管理(AMM)環境では、
/dev/shmにマウントされた共有メモリー・ファイルシステム(ramfs/tmpfs/shmfs)に
グラニュルサイズでファイルを作成して使用しているため、
共有メモリセグメントを使用していないことに起因しています。

このことから、自動メモリ管理(AMM)環境からHugepagesを使用した環境に変更するには、
現時的には以下の手順の実施を検討する必要があります。

2)hugepagesのページ数検討&設定
 2-1)sga_targetやpga_aggregate_targetの検討
 2-2)hugepagesのページ数検討



2-1)についてですが、まずは現状の確認が必要ですね。
Hugepasesに関係する初期化パラメータを確認します。
memory_targetのみが設定されている場合には、
以下の様な状態になっているかもしれません。

SQL> col name_col_plus_show_param for a20
SQL> col value_col_plus_show_param for a10
SQL> col type for a15

SQL> show parameter memory_max_target memory_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
memory_max_target    big integer     6G

SQL> show parameter memory_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
memory_target        big integer     6G

SQL> show parameter sga_max
NAME            TYPE            VALUE
--------------- --------------- ----------
sga_max_size    big integer     6G
※設定されていない場合には、memory_targetの値になります。

SQL> show parameter sga_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
sga_target           big integer     0

SQL> show parameter pga_aggregate_target
NAME                 TYPE            VALUE
-------------------- --------------- ----------
pga_aggregate_target big integer     0G

SQL> show parameter use_large_pages
NAME                 TYPE            VALUE
-------------------- --------------- ----------
use_large_pages      string          TRUE


sga_targetやpga_aggregate_targetを決定するには、
以下のSQLで現状や変動を確認し、設定値を検討します。

SQL>select COMPONENT,CURRENT_SIZE,MIN_SIZE,MAX_SIZE
      from V$MEMORY_DYNAMIC_COMPONENTS
      where COMPONENT IN ('SGA Target','PGA Target');

SQL> select COMPONENT,PARAMETER,INITIAL_SIZE,TARGET_SIZE,
      FINAL_SIZE,START_TIME from V$MEMORY_RESIZE_OPS
      where COMPONENT IN ('SGA Target','PGA Target')

以下のアドバイスを参考にするのもありですね。
V$SGA_TARGET_ADVICE
V$PGA_TARGET_ADVICE

hugepagesを使用できるのはSGAだけなので、
vm.nr_hugepagesはsga_targetの値をHPG_SZである2048で
割った値となります。


長くなってきたので、一旦切ります。
実際の設定作業については次のエントリに記載します。

続・HugePages_1


今日は、JPOUG Advent Calendar 2013の5日目のエントリです。
1nmくらい役に立つプレゼントになればと思ってエントリします。


以前書いたHugepagesに関するエントリが検索すると上位に来るようで、
その地位を盤石なものにするべく、今回追加でHugepagesネタを書こうと思います。


前回のエントリ日付は2011年11月10日で以下の環境でした。
前回から二年。皆さんが導入するOracleバージョンも変わってきていると思うので、
今回はそのバージョンの違いについて調べてみます。


============
前回の環境
CPU: Intel(R) Xeon(R) CPU E5630 @ 2.53GHz×4
メモリ:24GB
OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga)
カーネル:2.6.18-164.el5 x86_64
Oracle:11.2.0.2.0
============

今回の検証環境は以下となります。
カーネルとDBのバージョンが異なります。
============
今回の環境
CPU: Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz×2
メモリ:10GB
Oracle Linux Server release 6.4 x86_64
カーネル:2.6.39-400.17.1.el6uek.x86_64 #1
Oracle:11.2.0.4.0
SGA_TARGET:5GB
============

一言で言うと、Oracle Release 11.2.0.3.0から、
alert.logへの出力メッセージと初期化パラメータ「USE_LARGE_PAGES」の
設定値の動作と種類が少なからず変更になりました。

1.デフォルト値である「TRUE」の動作変更

動作の変更として、デフォルト値である「TRUE」の動きが変更になっています。
Oracle Database 11gリリース2 (11.2.0.2)では、
Hugepageに関する設定に失敗するとHugepage用領域が一切使用されず、
残りの物理メモリからSGAが割り当てられます。
これにより意図しない物理メモリ不足が発生し、エラーの発生やSWAPによる
パフォーマンス低下が発生する場合があります。

Oracle Database 11gリリース2 (11.2.0.3)では、
Oracleによって可能なかぎり多くのSGAがHugepage用領域に割り当てられ、
不足した場合は不足分を物理メモリの残りである通常サイズのページを使用して
割り当てられます。


★11.2.0.2のalert.log出力メッセージ★

■Hugpagesの設定がされていない場合
特にメッセージなし

■正常に取得できた場合
(vm.nr_hugepages=2561,memlock=5244928)

Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2561 free: 2561)
DFLT Huge Pages allocation successful (allocated: 2561)
***********************************************************

■SGAに対してHugpages用領域が不足している場合
(vm.nr_hugepages=2560,memlock=5244928)

****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2560 free: 2560)
Huge Pages allocation failed (free: 2560 required: 2561)
Allocation will continue with default/smaller page size
**********************************************************

■Hugpages用領域に対してmemlockの設定が小さい場合
(vm.nr_hugepages=2561,memlock=5242880)

Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 2561 free: 2561)
Memlock limit too small: 5368709120 to accommodate segment size: 5370806272
Huge Pages allocation failed (free: 2561 required: 2561)
Allocation will continue with default/smaller page size
**********************************************************


★11.2.0.3以降のalert.log出力メッセージ★

■Hugpagesの設定がされていない場合
(vm.nr_hugepages= ,memlock=5244928)

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

Total Shared Global Region in Large Pages = 0 KB (0%)

Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
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 2561 (page size 2048 KB, total size 5122 MB) 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
********************************************************************

■正常に取得できた場合
(vm.nr_hugepages=2561,memlock=5244928)

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に対してHugpages用領域が不足している場合
(vm.nr_hugepages=2560,memlock=5244928)

Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 5122 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
********************************************************************


■Hugpages用領域に対してmemlockの設定が小さい場合
(vm.nr_hugepages=2561,memloc=5242880)

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 = 1 (2048 KB)
Large Pages configured system wide = 2561 (5122 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. 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
********************************************************************


2.設定値「AUTO」動作変更(有効)
種類の変更としては「AUTO」の場合の動きが変更(有効)になっています。
AUTOが設定されている場合、Hugepages用領域にSGAが取得できる場合には
同領域を使用します。
SGAに対してHugepages用領域が不足している場合には、
oradismプロセスを起動しHugepages用領域を動的に拡張(追加割り当て)します。※1.2
※1.memlockの設定値が低い場合にはTRUEの場合と同様の動きとなります。
※2.Hugepages用領域割り当てられた領域は、インスタンスを停止しても、
 物理メモリ上の通常ページには戻されません。(Hugepage用として獲得されっぱなし)


■vm.nr_hugepages未設定(または0)、DB起動前
[root@s112040 ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         10020        955       9065          0        104        515
-/+ buffers/cache:        335       9685
Swap:        16383          0      16383
 →物理メモリは10GB弱空いています。

[root@s112040 ~]# grep Huge /proc/meminfo
AnonHugePages:      2048 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
 →HugePages用領域は0ページ。


■SGA_TRAGETを5GB、「AUTO」を設定してDBを起動した場合
(vm.nr_hugepages=0,memloc=5244928)

(alert.log)
Starting ORACLE instance (normal)
DISM started, OS id=4294 ←←←←←←oradismプロセスの起動
************************ Large Pages Information *******************
Parameter use_large_pages = AUTO
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
Time taken to allocate Large Pages = 0.100901 sec
********************************************************************

[oracle@s112040 ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:         10020       6157       3862          0        104        526
-/+ buffers/cache:       5527       4493
Swap:        16383          0      16383
 →物理メモリが5GB程度使用されています。


[oracle@s112040 ~]$ grep Huge /proc/meminfo
AnonHugePages:      38912 kB
HugePages_Total:    2561
HugePages_Free:        5
HugePages_Rsvd:        5
HugePages_Surp:        0
Hugepagesize:       2048 kB
 →HugePages用領域は2561ページ獲得されている


[oracle@s112040 trace]$ ps -edf|grep dism
root      4294     1  0 02:51 ?        00:00:00 ora_dism_s11204
 →プロセスがrootで起動されている。


~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~

というところで長くなってきたのでココらへんで終わりますが、
どちらの変更も使う側が意識しないで使用するとトラブルの元になりますね。
動作状況について、OSコマンドやログからしっかり把握しておくことが大事ですね。

そういえば、AnonHugePagesって前のエントリにいましたっけ?
要注意なヤツなのですが、それはまた別のお話・・


JPOUG Advent Calendar 2013、
明日の扉は tyuma さんです。よろしくお願いします。



o<(o'∀')ノ☆*:;;;:*☆Merry Christmas☆*:;;;:*☆ヽ('∀'o)>o



続・HugePages_2につづく