データベースサーバにおけるメモリ管理の重要性
一般に、データベースサーバにおいて、ページキャッシュ（ファイルキャッシュ）を管理することは、性能上あるいはシステム安定稼動の観点から重要です。
今回は、DB2がオンライン処理を実行中に、大規模ファイルアクセス（読み取り、書き込み）を伴う処理が実行される場合のメモリ管理を取り上げま す。具体的には、Linuxページキャッシュ（ファイルキャッシュ）が大量に確保され、そのかわりにDB2のメモリがスワップされて、DB2がスローダウ ンしてしまうようなことを回避する方法について検討します。
DB2が利用するメモリは、そのパラメータ構成により上限のサイズを決めることができます。一方のLinux側におけるページキャッシュの最大利用 量は、指定する方法がありませんので（Linuxソースコードを自身で修正することを除き）、一般的な対応方法としては以下のようなものが考えられます。
- Linuxカーネルパラメータでの対応
-
- プロセス／メモリがスワップされづらくする
- ページキャッシュを再利用されやすくする
- DB2設定での対応
-
- DB2の処理でページキャッシュを使わないようにする
- DB2のメモリをスワップされないようにする
- DB2_PINNED_BP登録変数を利用して、データベース共用メモリをロックし、スワップされなくする
- Linuxラージページを利用して、スワップされなくする
Linuxカーネルパラメータでの対応
Linuxカーネルパラメータでの対応においては、本連載の「第5回：カーネルをチューニングする」の「メモリ」にあげたカーネルパラメータを調整します。
具体的には、プロセス／メモリがスワップされづらいようにするために、カーネルパラメータ（vm.swappiness）の値を小さくします。ま た、ページキャッシュ内の「更新されたダーティなデータ」をはやめにディスクに書き込んで、ページキャッシュのメモリを再利用されやすくするため、カーネ ルパラメータのvm.dirty_ratioおよびvm.dirty_background_ratioの値を小さくするなどの調整をします。
実際には、負荷テストを行いながらその効果を確認することになります。
Linuxにおけるメモリの開放
データベースサーバなどを運用していると、、ページキャッシュを開放して、フリーメモリを増やしたい場合があると思います。カーネル2.6.16以降ではvm.drop_cachesがサポートされ、以下の値が利用可能です。
- ページキャッシュを開放する
- dentryおよびinode情報を開放する
- ページキャッシュおよびdentry、inode情報を開放する
SUSE Linux Enterprise Server 10の環境にて、簡単に検証してみた結果が以下です。
sles10a:~ # free -m
total used free shared buffers cached
Mem: 2000 61 1939 0 0 9
-/+ buffers/cache: 51 1949
Swap: 2047 0 2047
sles10a:~ # dd if=test of=/dev/null bs=1024
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 34.5933 seconds, 31.0 MB/s
sles10a:/ # free -m
total used free shared buffers cached
Mem: 2000 1090 910 0 2 1034
-/+ buffers/cache: 53 1947
Swap: 2047 0 2047
sles10a:/ # sysctl -w vm.drop_caches=1
vm.drop_caches = 1
sles10a:/ # free -m
total used free shared buffers cached
Mem: 2000 60 1939 0 0 9
-/+ buffers/cache: 51 1949
Swap: 2047 0 2047
sles10a:/ # 約1GBのファイルの読み取りで、約1GBほどページキャッシュに蓄えられた後、vm.drop_cachesの設定により、メモリが開放されています。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
