前回はこちら:Hugepagesとその設定_6
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
今回で纏めの予定だったのですが、
ちょっと書き漏らしたので、諸々補足回とします。
1.USE LARGE_PAGES初期化パラメータ
上記マニュアルからはkernel 2.6以上がうんぬんと書いてありますが、
設定サイズ確認用スクリプト等諸々見ると2.4においても使用できるようです。
というのはおいといて、11.2.0.2.0以上では初期化パラメータによって
HugePagesの使用可否を設定できます。
11.2.0.2.0以上のリリースに存在するパラメータになります。
TRUE(デフォルト)：Hugepagesが使用可能であれば使用する。
使用不可の場合は、通常のsmall Pageを使用して起動
FALSE：Hugepagesを使用しない
ONLY：Hugepagesを使用して起動する。
使用不可の場合は、エラーを出力してインスタンスは起動しない。
11.2.0.2.0未満はどうか？という話ですが、
9.2.0.1.0以上でHugePagesが使用可能な状態であれば使用するようです。
出典:HugePages on Oracle Linux 64-bit [ID 361468.1]
2.HugePagesを使用状態の確認方法？
検証内では、HugePagesのFreeやRsvdが減ったから使ってるっぽいぜ？
と結構いい加減にやりましたが、以下の方法で確認できます。
■alertログを見る！
とてもシンプル・・・(＞＿＜；)
A.HugePagesを使用してインスタンスが起動した場合の出力例
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 5123 free: 5123)
DFLT Huge Pages allocation successful (allocated: 5121)
***********************************************************
やっぱり、Rsvdと同じ値5121ページしか獲得していないようですね。
B.HugePagesの獲得に失敗してインスタンスが起動した場合の出力例
※出力例はmemlockを設定していなかった場合の例
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 5123 free: 5123)
Memlock limit too small: 32768 to accommodate segment size: 10739515392
Huge Pages allocation failed (free: 5123 required: 5121)
Allocation will continue with default/smaller page size
**********************************************************
とても分かりやすくて、優しさを感じる英語文ですね(笑)
ということで、次回こそ最終回。
2011年11月13日日曜日
2011年11月11日金曜日
HugePagesとその設定_6
前回はこちら:Hugepagesとその設定_5
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
前回は
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
HugePages_Total－HugePages_Free＝5123-4679=444ページ=使用済みHugePage？
使用済みhugepaeメモリ=444*2MB=888MB
SGA_MAX_SIZEは10GBなのに？？？
というところで終わりました。
まぁ、DB起動したばっかりだし、
色々トランザクションをかけてみます。
・・・・
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 4407
HugePages_Rsvd: 4405
Hugepagesize: 2048 kB
増えてる！
HugePages_Free前回との差分=4679-4407=272ページ
HugePages_Rsvdの差分=4677-4405=272ページ
おっ！ぴったり！！
HugePages_Total-HugePages_Free：使用済みHupage数
HugePages_Total－HugePages_Free＝5123-4407=716ページ=716*2MB=1432MB
というところか。。。
HugePages_Rsvd:獲得済みHugepeだが使用されていないHugepage?
HugePages_FreeとHugePages_Rsvdの差分(2ページ8MB)はなんだろう・・・
という謎を残したまま、次回はまとめと補足(笑)
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
前回は
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
HugePages_Total－HugePages_Free＝5123-4679=444ページ=使用済みHugePage？
使用済みhugepaeメモリ=444*2MB=888MB
SGA_MAX_SIZEは10GBなのに？？？
というところで終わりました。
まぁ、DB起動したばっかりだし、
色々トランザクションをかけてみます。
・・・・
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 4407
HugePages_Rsvd: 4405
Hugepagesize: 2048 kB
増えてる！
HugePages_Free前回との差分=4679-4407=272ページ
HugePages_Rsvdの差分=4677-4405=272ページ
おっ！ぴったり！！
HugePages_Total-HugePages_Free：使用済みHupage数
HugePages_Total－HugePages_Free＝5123-4407=716ページ=716*2MB=1432MB
というところか。。。
HugePages_Rsvd:獲得済みHugepeだが使用されていないHugepage?
HugePages_FreeとHugePages_Rsvdの差分(2ページ8MB)はなんだろう・・・
という謎を残したまま、次回はまとめと補足(笑)
HugePagesとその設定_5
前回はこちら:HugePagesとその設定_4
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
前回はHugePagesを設定できたはずなのに、なんかオカシイ気がする・・・
ということろで終わりました。
今回は原因を調べてみます。
といっても、彼のOracle社が誤った情報を流したり、
手順が抜けてたりする筈がないんです!!
きっと小生が悪いに違いないんです!!
マニュアルを読み直します。(本当に昔に比べて質が高くなった。)
・・・・
あれ？関係ないと思って読み飛ばした上の方を呼んでみると・・・
G.1.4 Oracle DatabaseのVery Large Memoryの構成
/etc/security/limits.confファイルを編集し、次のエントリを追加して、メモリー・ロックの上限値を大きくします。
soft memlock 3145728
hard memlock 3145728
メモリ・ロック。。。なんか関係ありそう。。
5.メモリー・ロックの上限値を大きくする。
memlockの値は物理メモリ以下でSGAやHugePagesのサイズより大きいサイズがいいよな。
/etc/security/limits.confファイルを編集し、次のエントリを追加して、
メモリー・ロックの上限値を設定または編集します。(単位はKB)
今回は15GBを設定。
oracle soft memlock 15728640
oracle hard memlock 15728640
もちろん、設定したら一度sudoし直します。
$ exit
# su - oracle
$ ulimit -l
15728640
よし！！
6.インスタンスの起動
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1.0689E+10 bytes
Fixed Size 2235904 bytes
Variable Size 2650800640 bytes
Database Buffers 8019509248 bytes
Redo Buffers 16928768 bytes
データベースがマウントされました。
データベースがオープンされました。
7.HugePagesの使用状況を確認します。
cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
Hugepagesize: 2048 kB
YES!!きたきたきたきた！！！
# free -m
(DB起動前)
total used free shared buffers cached
Mem:24109 12048 12061 0 294 1079
(DB起動後)
total used free shared buffers cached
Mem:24109 12127 11982 0 294 1079
数十MBしか変化なし！
HugePagesを使うのはSGAだけだったはず。
正常な動作っぽいぞ。
・・・・でも、この値は何を意味しているのだろう。。
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
HugePages_Total－HugePages_Free＝5123-4679=444ページ=使用済みHugePage？
使用済みhugepaeメモリ=444*2MB=888MB
SGA_MAX_SIZEは10GBなのに？？？
HugePages_Rsvd: 4677 は何？？？？
HugePagesとその設定_6に続く。。。
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
前回はHugePagesを設定できたはずなのに、なんかオカシイ気がする・・・
ということろで終わりました。
今回は原因を調べてみます。
といっても、彼のOracle社が誤った情報を流したり、
手順が抜けてたりする筈がないんです!!
きっと小生が悪いに違いないんです!!
マニュアルを読み直します。(本当に昔に比べて質が高くなった。)
・・・・
あれ？関係ないと思って読み飛ばした上の方を呼んでみると・・・
G.1.4 Oracle DatabaseのVery Large Memoryの構成
/etc/security/limits.confファイルを編集し、次のエントリを追加して、メモリー・ロックの上限値を大きくします。
soft memlock 3145728
hard memlock 3145728
メモリ・ロック。。。なんか関係ありそう。。
5.メモリー・ロックの上限値を大きくする。
memlockの値は物理メモリ以下でSGAやHugePagesのサイズより大きいサイズがいいよな。
/etc/security/limits.confファイルを編集し、次のエントリを追加して、
メモリー・ロックの上限値を設定または編集します。(単位はKB)
今回は15GBを設定。
oracle soft memlock 15728640
oracle hard memlock 15728640
もちろん、設定したら一度sudoし直します。
$ exit
# su - oracle
$ ulimit -l
15728640
よし！！
6.インスタンスの起動
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1.0689E+10 bytes
Fixed Size 2235904 bytes
Variable Size 2650800640 bytes
Database Buffers 8019509248 bytes
Redo Buffers 16928768 bytes
データベースがマウントされました。
データベースがオープンされました。
7.HugePagesの使用状況を確認します。
cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
Hugepagesize: 2048 kB
YES!!きたきたきたきた！！！
# free -m
(DB起動前)
total used free shared buffers cached
Mem:24109 12048 12061 0 294 1079
(DB起動後)
total used free shared buffers cached
Mem:24109 12127 11982 0 294 1079
数十MBしか変化なし！
HugePagesを使うのはSGAだけだったはず。
正常な動作っぽいぞ。
・・・・でも、この値は何を意味しているのだろう。。
HugePages_Total: 5123
HugePages_Free: 4673
HugePages_Rsvd: 4671
HugePages_Total－HugePages_Free＝5123-4679=444ページ=使用済みHugePage？
使用済みhugepaeメモリ=444*2MB=888MB
SGA_MAX_SIZEは10GBなのに？？？
HugePages_Rsvd: 4677 は何？？？？
HugePagesとその設定_6に続く。。。
HugePagesとその設定_4
前回はこちら:HugePagesとその設定_3
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
ちょっと寄り道して、データベースを停止します。
SQL> shutdown immediate
# free -m
total used free shared buffers cached
Mem:24109 1795 22314 0 294 1071
22GB前後空いてます。
さてカーネルパラメータvm.nr_hugepagesの設定をしていきます。
3.カーネルパラメータ vm.nr_hugepagesの設定
コマンド）
# sysctl -w vm.nr_hugepages=5123
または
コンピュータの再起動時に常にこのパラメータ値が使用されるようにするには、
/etc/sysctl.confファイルを編集して、次のエントリを追加します。
vm.nr_hugepages=5123
4.変更後の使用可能なHugePagesを確認します。
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 5123
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
HugePagesページは2MBで、5123ページ空いてます。
5123ページ×2MB=10246MB≒10.005859375GB≒SGA_MAX_SIZEの値！！
おぉーーー
ちゃんとHugePagesとして獲得できているかのかしら？
total used free shared buffers cached
Mem:24109 12048 12061 0 294 1079
おぉー！！DBは起動していないのに、10GB位なんか使ってるっぽい。
よしっ！いける！！
5.インスタンスの起動
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1.0689E+10 bytes
Fixed Size 2235904 bytes
Variable Size 2650800640 bytes
Database Buffers 8019509248 bytes
Redo Buffers 16928768 bytes
データベースがマウントされました。
データベースがオープンされました。
6.hugepagesの使用状況を確認します。
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 5123
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
変化なし？？？こんなもんなの？
# free -m
total used free shared buffers cached
Mem:24109 12771 11338 0 294 1724
ありりり？？？
DB起動しただけなのに700MBも使ってる。。。
HugePagesが取得したメモリ領域にSGA取ってくれるんじゃなかったの？？？？
HugePagesとその設定_5に続く。。。。
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
ちょっと寄り道して、データベースを停止します。
SQL> shutdown immediate
# free -m
total used free shared buffers cached
Mem:24109 1795 22314 0 294 1071
22GB前後空いてます。
さてカーネルパラメータvm.nr_hugepagesの設定をしていきます。
3.カーネルパラメータ vm.nr_hugepagesの設定
コマンド）
# sysctl -w vm.nr_hugepages=5123
または
コンピュータの再起動時に常にこのパラメータ値が使用されるようにするには、
/etc/sysctl.confファイルを編集して、次のエントリを追加します。
vm.nr_hugepages=5123
4.変更後の使用可能なHugePagesを確認します。
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 5123
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
HugePagesページは2MBで、5123ページ空いてます。
5123ページ×2MB=10246MB≒10.005859375GB≒SGA_MAX_SIZEの値！！
おぉーーー
ちゃんとHugePagesとして獲得できているかのかしら？
total used free shared buffers cached
Mem:24109 12048 12061 0 294 1079
おぉー！！DBは起動していないのに、10GB位なんか使ってるっぽい。
よしっ！いける！！
5.インスタンスの起動
SQL> startup
ORACLEインスタンスが起動しました。
Total System Global Area 1.0689E+10 bytes
Fixed Size 2235904 bytes
Variable Size 2650800640 bytes
Database Buffers 8019509248 bytes
Redo Buffers 16928768 bytes
データベースがマウントされました。
データベースがオープンされました。
6.hugepagesの使用状況を確認します。
# cat /proc/meminfo |grep Huge
HugePages_Total: 5123
HugePages_Free: 5123
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
変化なし？？？こんなもんなの？
# free -m
total used free shared buffers cached
Mem:24109 12771 11338 0 294 1724
ありりり？？？
DB起動しただけなのに700MBも使ってる。。。
HugePagesが取得したメモリ領域にSGA取ってくれるんじゃなかったの？？？？
HugePagesとその設定_5に続く。。。。
2011年11月10日木曜日
HugePagesとその設定_3
前回はこちら：Hugepagesとその設定_2
前回は手順通りやったはずなのに見事に失敗。。。なぜ！？
よくよくマニュアル読むと。。。
G.2.3 HugePages構成の制限
HugePagesを使用した場合の制限は次のとおりです。
自動メモリー管理(AMM)とHugePagesは、互換性がありません。
AMMを使用すると、SGAメモリー全体は/dev/shmの下にファイルを
作成することによって割り当てられます。
Oracle Databaseがこの方法でSGAを割り当てると、HugePagesは予約されません。
HugePagesを使用するには、Oracle Database 11gでAMMを無効にする必要があります。
AMM(memory_target)は/dev/shm配下にファイルを作って割り当てるのか。。
# ls -l /dev/shm
-rw-r----- 1 oracle oinstall 32M 11月 10 22:35 ora_orcl_2293761_0
-rw-r----- 1 oracle oinstall 32M 11月 10 22:35 ora_orcl_2293761_1
・・・・ずっと続く
うわぁ・・・めちゃくちゃある。
AMM(memory_target)は/dev/shm配下にファイルを作って割り当てるってあるから、
共有メモリの獲得方法とはちょっと違うのかな・・・
memory_targetやめてみるか。
SQL> create pfile='/home/oracle/pfile.ora' from spfile;
$ vi pfile.ora
memory_targetとmemory_max_targetの行を削除
SQL> create spfile from pfile='/home/oracle/pfile.ora'
SQL> startup
環境
=========================================================
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
Bit:64
# df -h |grep shm
shmfs 15G 766M 15G 5% /dev/shm
#free -m
total used free shared buffers cached
Mem:24109 12838 11271 0 293 1819
=========================================================
Oracle:11.2.0.2
Bit:64
MEMORY_MAX_TRAGET:14GB ====> 0
SGA_TARGET:10GB
PGA_AGGREGATE_TARGET:3GB
=========================================================
2.hugepages_settings.shスクリプトを実行して、hugepages構成の値を計算します。
$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 5123
ふぅ・・・5123ね。OKOK。
#ls -l /dev/shm
もう使わないし、
#umount /dev/shm
HugePagesとその設定_4からvm.nr_hugepagesを設定していきます。
前回は手順通りやったはずなのに見事に失敗。。。なぜ！？
よくよくマニュアル読むと。。。
G.2.3 HugePages構成の制限
HugePagesを使用した場合の制限は次のとおりです。
自動メモリー管理(AMM)とHugePagesは、互換性がありません。
AMMを使用すると、SGAメモリー全体は/dev/shmの下にファイルを
作成することによって割り当てられます。
Oracle Databaseがこの方法でSGAを割り当てると、HugePagesは予約されません。
HugePagesを使用するには、Oracle Database 11gでAMMを無効にする必要があります。
AMM(memory_target)は/dev/shm配下にファイルを作って割り当てるのか。。
# ls -l /dev/shm
-rw-r----- 1 oracle oinstall 32M 11月 10 22:35 ora_orcl_2293761_0
-rw-r----- 1 oracle oinstall 32M 11月 10 22:35 ora_orcl_2293761_1
・・・・ずっと続く
うわぁ・・・めちゃくちゃある。
AMM(memory_target)は/dev/shm配下にファイルを作って割り当てるってあるから、
共有メモリの獲得方法とはちょっと違うのかな・・・
memory_targetやめてみるか。
SQL> create pfile='/home/oracle/pfile.ora' from spfile;
$ vi pfile.ora
memory_targetとmemory_max_targetの行を削除
SQL> create spfile from pfile='/home/oracle/pfile.ora'
SQL> startup
環境
=========================================================
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
Bit:64
# df -h |grep shm
shmfs 15G 766M 15G 5% /dev/shm
#free -m
total used free shared buffers cached
Mem:24109 12838 11271 0 293 1819
=========================================================
Oracle:11.2.0.2
Bit:64
MEMORY_MAX_TRAGET:14GB ====> 0
SGA_TARGET:10GB
PGA_AGGREGATE_TARGET:3GB
=========================================================
2.hugepages_settings.shスクリプトを実行して、hugepages構成の値を計算します。
$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 5123
ふぅ・・・5123ね。OKOK。
#ls -l /dev/shm
もう使わないし、
#umount /dev/shm
HugePagesとその設定_4からvm.nr_hugepagesを設定していきます。
HugePagesとその設定_2
前回はこちら：HugePagesとその設定_1
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
では設定していきます。
環境
=========================================================
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
Bit:64
# df -h |grep shm
shmfs 15G 766M 15G 5% /dev/shm
#free -m
total used free shared buffers cached
Mem:24109 12838 11271 0 293 1819
=========================================================
Oracle:11.2.0.2
Bit:64
MEMORY_MAX_TRAGET:14GB
SGA_TARGET:10GB
PGA_AGGREGATE_TARGET:3GB
=========================================================
0.現状の確認(未設定)
# cat /proc/meminfo |grep Huge
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
HugePages_Total: < 確保されているHugepageの数 >
HugePages_Free: < 空きHugepageの数 >
HugePages_Rsvd: < 予約済みHugepageの数 >
Hugepagesize: < 1 Hugepageのサイズ >
1.現行の共有メモリー・セグメントのhugepages構成の推奨値を計算する
スクリプトを作成します。
OracleR Database管理者リファレンス
11g リリース2(11.2) for Linux and UNIX-Based Operating Systems
G.2.2 RHEL/ Oracle LinuxでのHugePagesの構成からコピって作ります。
割愛します。
2.hugepages_settings.shスクリプトを実行して、hugepages構成の値を計算します。
$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 1
あれれれれれ？？？？
1って。。
HugePagesとその設定_3につづく
ベースはOracle® Database管理者リファレンス
11g リリース2(11.2)for Linux and UNIX-Based Operating Systemsの手順に沿っています。
では設定していきます。
環境
=========================================================
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
Bit:64
# df -h |grep shm
shmfs 15G 766M 15G 5% /dev/shm
#free -m
total used free shared buffers cached
Mem:24109 12838 11271 0 293 1819
=========================================================
Oracle:11.2.0.2
Bit:64
MEMORY_MAX_TRAGET:14GB
SGA_TARGET:10GB
PGA_AGGREGATE_TARGET:3GB
=========================================================
0.現状の確認(未設定)
# cat /proc/meminfo |grep Huge
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
HugePages_Total: < 確保されているHugepageの数 >
HugePages_Free: < 空きHugepageの数 >
HugePages_Rsvd: < 予約済みHugepageの数 >
Hugepagesize: < 1 Hugepageのサイズ >
1.現行の共有メモリー・セグメントのhugepages構成の推奨値を計算する
スクリプトを作成します。
OracleR Database管理者リファレンス
11g リリース2(11.2) for Linux and UNIX-Based Operating Systems
G.2.2 RHEL/ Oracle LinuxでのHugePagesの構成からコピって作ります。
割愛します。
2.hugepages_settings.shスクリプトを実行して、hugepages構成の値を計算します。
$ ./hugepages_settings.sh
Recommended setting: vm.nr_hugepages = 1
あれれれれれ？？？？
1って。。
HugePagesとその設定_3につづく
HugePagesとその設定_1
2011/11/09のOracle DBA & Developer Days 2011のE-5セッション
シバタツ流!チューニングの極意「パフォーマンス・チューニングの勘どころ」でも
シバタツさんが説明されていたので、ちょうど前日検証していたところもあり、
書いておきたいと思います。
■HugePages
Linuxカーネル2.6に統合された機能です。これは大きいページを使用する方法で、
大規模メモリーで作業する際に便利です。
32ビットおよび64ビット構成の両方で使用できます。HugePageサイズは、
カーネル・バージョンおよびハードウェア・アーキテクチャに応じて、
2MBから256MBと異なります。
Oracle Databaseの場合、HugePagesを使用すると、
ページ状態のオペレーティング・システム・メンテナンスが軽減され、
Translation Lookaside Buffer(TLB)ヒット率が向上します。
■なぜ大規模メモリにHugePagesなのか？
HugePagesを使用しない場合、1ページ当たり4KBのメモリーがオペレーティング・システムに
保持され、SGAに割り当てられる際に、
ページのライフサイクル(ダーティ、空き、プロセスにマップ済など)が
オペレーティング・システム・カーネルによって最新に保たれます。
HugePagesを使用する場合、各ページ表エントリが2MBから256MBのページを指すため、
オペレーティング・システム・ページ表(仮想メモリーから物理メモリーへのマッピング)は
小さくなります。
また、カーネルでは、ライフサイクルを監視する必要があるページが少なくなります。
⇒Oracleが何を言いたいかと言うと、大きな物理メモリを積んでいるようなマシンで、
Oracleに割り当てるでっかいメモリ領域(SGA)を4KB単位とのページを
OSが管理するのは負荷(CPU負荷)が高いんです。
なので、1ページが大きいHugePagesを使用した方がOSの管理負荷(CPU負荷)が
低減されてよいんです。と言っているんだと思う。
また、HugePagesを使うと以下のメリットがあります。
1.TLBヒットが増加することによってパフォーマンスが向上します。
2.ページがメモリー内でロックされ、スワップ・アウトされないため、
SGAのような共有メモリーがRAMに残ります。
3.連続するページを事前に割り当てるため、
System V共有メモリー(SGAなど)以外に使用できなくなります。
4.より大きなページ・サイズによる仮想メモリーの部分のため、カーネル用の記録操作が
削減されます。
⇒2.がポイントかしら。要は、SGAをメモリ上にロックできるんですね。
それにより、スワップ・イン/スワップ・アウトを食らわなくてすむ。
SGAの情報は常にRAM上にキャッシュできる。
(そもそも、キャッシュ上のデータ管理はSGAのLRUがあるし。)
⇒OSのページ管理による負荷(CPU負荷)を軽減できる。
なお、大規模メモリ環境におけるOSのページ管理による負荷(CPU負荷)は
MOSでも障害として取り上げられています。
[ID 361670.1]Slow Performance with High CPU Usage on 64-bit Linux with Large SGA
大規模メモリ＆大規模SGAを積んでる環境で、なんかSYSTEM CPU負荷が高いんだけど。。。
という環境は確認&検討してみるといいかもですね。
※大規模メモリ:シバタツさんのセミナーでは32GBが目安とご説明されていました。
ちなみに、HugePagesはmemory_targetでは使えないので注意が必要。
でも、それは次回のHugepagesとその設定_2で。。。
出典：Oracle® Database管理者リファレンス 11g リリース2(11.2)
for Linux and UNIX-Based Operating Systems
シバタツ流!チューニングの極意「パフォーマンス・チューニングの勘どころ」でも
シバタツさんが説明されていたので、ちょうど前日検証していたところもあり、
書いておきたいと思います。
■HugePages
Linuxカーネル2.6に統合された機能です。これは大きいページを使用する方法で、
大規模メモリーで作業する際に便利です。
32ビットおよび64ビット構成の両方で使用できます。HugePageサイズは、
カーネル・バージョンおよびハードウェア・アーキテクチャに応じて、
2MBから256MBと異なります。
Oracle Databaseの場合、HugePagesを使用すると、
ページ状態のオペレーティング・システム・メンテナンスが軽減され、
Translation Lookaside Buffer(TLB)ヒット率が向上します。
■なぜ大規模メモリにHugePagesなのか？
HugePagesを使用しない場合、1ページ当たり4KBのメモリーがオペレーティング・システムに
保持され、SGAに割り当てられる際に、
ページのライフサイクル(ダーティ、空き、プロセスにマップ済など)が
オペレーティング・システム・カーネルによって最新に保たれます。
HugePagesを使用する場合、各ページ表エントリが2MBから256MBのページを指すため、
オペレーティング・システム・ページ表(仮想メモリーから物理メモリーへのマッピング)は
小さくなります。
また、カーネルでは、ライフサイクルを監視する必要があるページが少なくなります。
⇒Oracleが何を言いたいかと言うと、大きな物理メモリを積んでいるようなマシンで、
Oracleに割り当てるでっかいメモリ領域(SGA)を4KB単位とのページを
OSが管理するのは負荷(CPU負荷)が高いんです。
なので、1ページが大きいHugePagesを使用した方がOSの管理負荷(CPU負荷)が
低減されてよいんです。と言っているんだと思う。
また、HugePagesを使うと以下のメリットがあります。
1.TLBヒットが増加することによってパフォーマンスが向上します。
2.ページがメモリー内でロックされ、スワップ・アウトされないため、
SGAのような共有メモリーがRAMに残ります。
3.連続するページを事前に割り当てるため、
System V共有メモリー(SGAなど)以外に使用できなくなります。
4.より大きなページ・サイズによる仮想メモリーの部分のため、カーネル用の記録操作が
削減されます。
⇒2.がポイントかしら。要は、SGAをメモリ上にロックできるんですね。
それにより、スワップ・イン/スワップ・アウトを食らわなくてすむ。
SGAの情報は常にRAM上にキャッシュできる。
(そもそも、キャッシュ上のデータ管理はSGAのLRUがあるし。)
⇒OSのページ管理による負荷(CPU負荷)を軽減できる。
なお、大規模メモリ環境におけるOSのページ管理による負荷(CPU負荷)は
MOSでも障害として取り上げられています。
[ID 361670.1]Slow Performance with High CPU Usage on 64-bit Linux with Large SGA
大規模メモリ＆大規模SGAを積んでる環境で、なんかSYSTEM CPU負荷が高いんだけど。。。
という環境は確認&検討してみるといいかもですね。
※大規模メモリ:シバタツさんのセミナーでは32GBが目安とご説明されていました。
ちなみに、HugePagesはmemory_targetでは使えないので注意が必要。
でも、それは次回のHugepagesとその設定_2で。。。
出典：Oracle® Database管理者リファレンス 11g リリース2(11.2)
for Linux and UNIX-Based Operating Systems
登録:
投稿 (Atom)