もともとLinuxラージページは、大規模なシステムにおいて、大きなページサイズのメモリを利用することにより、TLB（Translation Look-aside Buffer：Linuxの仮想メモリと実メモリの変換結果のキャッシュメモリ）のキャッシュミスを減らして、性能を向上させることを目的としたものです。
ラージページはそれ専用に利用され、スワップの対象外となっていますので、ラージページを利用することにより、結果的にスワップされなくなります。ipcs --mコマンドで確認すると、DB2_PINNED_BPのケースと同様にLinux上でロックされていることが確認できます。
では実際に、DB2でラージページを利用するためのDB2登録変数を次に示します。
DB2 V8.2での指定（データベース共用メモリにラージページを利用可能）
db2set DB2_LGPAGE_BP=ON
DB2 9での指定（すべてのメモリをラージページとして利用可能）
Db2set DB2_LARGE_PAGE_MEM=*
表2：ラージページの設定
なお、ラージページを利用するためには、Linux側で利用可能になっている必要があります。/proc/meminfo内のHugePages_Total／HugePages_Free／Hugepagesizeの設定を確認してください。
次に、DB2_PINNED_BP=ONの効果を検証した結果を示します。DB2では特に処理を行っていない状況で、ddコマンドによって4GBのファイルを読み込む際に「DB2_PINNED_BP=」のONとOFFの違いで、共用メモリのスワップされたページ数を比較しました。
なお環境は、OSがRHEL4 U4、メモリは8GB、DB2 V8.2(FP14)でDB2バッファープールが6GBです。
ddコマンド実行前の状況
[db2inst1@db2v9svr ~]$ ipcs -u
------ シェアードメモリの状態 --------
確保されたセグメント 23
確保されたページ 2012403
固定されたページ 1643781
スワップされたページ 0
スワップの動作: 0 回試み 0 回成功
（後略）
ddコマンド実行後の状況（DB2_PINNED_BP=ON）
[db2inst1@db2v9svr ~]$ ipcs -u
------ シェアードメモリの状態 --------
確保されたセグメント 23
確保されたページ 2012403
固定されたページ 1642220
スワップされたページ 1561
スワップの動作: 0 回試み 0 回成功
（後略）
ddコマンド実行後の状況（DB2_PINNED_BP=OFF）
[db2inst1@db2v9svr ~]$ ipcs -u
------ シェアードメモリの状態 --------
確保されたセグメント 23
確保されたページ 2012403
固定されたページ 873312
スワップされたページ 770469
スワップの動作: 0 回試み 0 回成功
（後略）
「DB2_PINNED_BP=OFF」では約3GBスワップされたのに対して、「=ON」では6MBほどしかスワップされていません。
なお、DB2でオンライン処理を行っている場合には、共用メモリが高い頻度で利用されるので、筆者の経験的には上記のように大量にスワップされることはほとんどおきません。この点は、カーネル2.6で大きく改善された点の1つだとおもわれます（カーネル2.4では、かなりのスワップ発生した経験があります）。
|
