postgresql.confの設定を見直そう
前回に引き続き、postgresql.confの設定によるチューニングテクニックを紹介していきます。
wal_sync_method
データをディスク装置に確実に書き込むために、PostgreSQLでは同期書 き込みという方法を使っていますが、同期書き込みにはかなり時間がかかります。同期書き込みの方法はプラットフォームによっていくつか選択肢があり、一概 にどれが最適とはいえないため、実際にベンチマークを計測して最適なものを選ぶとよいでしょう。ベンチマークの計測方法としては、 contrib／pgbenchを使用するのが手頃です。
次に、これらを使ったベンチマーク計測方法を示します。ベンチマーク用のデータベースは新たに作成することをお勧めします。ここでは「bench」という名前のデータベースを使用しています。
- ベンチマークデータベースの作成（createdb bench）
- ベンチマークデータベースの初期化（pgbench -i bench）
- wal_sync_methodを設定
- postmasterの再起動、出力されるTPS値を記録
- ベンチマークを実行（pgbench -c 10 -t 1000 bench）
- まだ試していないwal_sync_methodがあれば2.へ戻る
これを繰り返し、一番TPS値が大きい書き込み方法を採用してください。なお、 プラットフォームによってはサポートされていないwal_sync_methodがあるかもしれません。この場合、postmasterが起動しないの で、それについてはあきらめて次のwal_sync_methodに進みます。
checkpoint_segments
PostgreSQLでは、データベースへの更新記録は、WALログという特別 なファイルに同期書き込みを使って行われます。その代わり、テーブルやインデックス本体への書き込みは、同期書き込みではなく、通常のバッファリングを 使ったより効率的な方法を使います。コンピュータがクラッシュすると、テーブルやインデックスへの書き込みデータが失われる可能性がありますが、WALロ グの更新記録を使えばリカバリできるので問題ありません。
しかし、WALログは放っておくと無制限に大きくなってしまうので、ときどき「チェックポイント（checkpoint）」処理を実行し、テーブル やインデックスへの更新を同期書き込みによって確定しておく必要があります。こうしておけば、コンピュータが異常停止しても、ディスクが破壊されない限り データを失う心配がなくなります。同期書き込みによってデータを確定するとこれまでのWALログのデータが不要になるので、このタイミングでWALログを 消去します。
WALログは1個16Mバイトの「セグメントファイル」に分かれています。デフォルトでは、5分に一度、あるいはセグメントファイル数が3個を超え たときにチェックポイント処理が実行されます。通常は、このデフォルトの設定で問題ないのですが、大量の更新処理を実行すると、次のようなメッセージが表 示されることがあります。
LOG: checkpoints are occurring too frequently (11 seconds apart)
HINT: Consider increasing the configuration parameter "checkpoint_segments".
チェックポイントが頻発する（この例では、11秒間隔）ことについての警告が出 されています。チェックポイントは同期書き込みを伴う比較的負荷の高い処理であり、あまりチェックポイントが頻発するとパフォーマンスが低下します。ディ スク容量に十分余裕がある場合は、checkpoint_segmentsの値を増やしてチェックポイント頻度を低減するとよいでしょう。上記のメッセー ジが表示されるときは、checkpoint_segmentsの値を増やしてください。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
