 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| 今回のチューニング | ||||||||||
|
PostgreSQLの基本的なチューニングパラメータで、まだ取り上げていないものがあります。チェックポイントセグメント数です。今回はこれを取り上げます。 ところで、これまで紹介してきたチューニング例をご自身で試された方もいらっしゃると思いますが、テスト用サーバマシンのようには性能が向上できなかった方もいるのではないかと思います。 チューニングというのは1つの項目を調整すれば必ず性能が向上するというものではなく、複数の調整による相乗効果ではじめて良い結果を示す場合があります。ですから、前回までのチューニングで性能が向上しなったとしても残念に思うことはありません！恐らく今回のチューニングにより何らかの良い結果が得られると思います。 |
||||||||||
| チェックポイントとは | ||||||||||
|
チェックポイントについては本連載の第3回で解説しましたが、ここでもう一度簡単におさらいしておきます。 PostgreSQLでは、共有バッファ上のダーティページをすぐにはハードディスクに書き込みません。代わりにトランザクションログを随時ハードディスクに書き込むことにより、障害時のデータの信頼性を確保しています。 ただし放っておけばトランザクションログが溜まる一方ですから、どこかでトランザクションログを削除しないといけません。それが「チェックポイント」です。 チェックポイントでは、共有バッファ中のすべてのダーティページをハードディスクに書き出します。こうして未書き込みのデータがなくなったところで、不要になったトランザクションログを削除しています。 |
||||||||||
| チェックポイントの実行タイミング | ||||||||||
|
チェックポイントはpsqlなどのSQLインターフェースからCHECKPOINT文を実行することでも行えますが、ある条件に達するとPostgreSQL自身でも自動的にチェックポイントを実行します。 ではどのような条件で実行されるのでしょうか？ 1つはトランザクションログが一定量に達した場合です。これによりトランザクションログが永久に溜まることを防いでいます（図1）。実は今回取り上げる「チェックポイントセグメント数の調整」とは、この一定量を決める作業なのです。  図1：チェックポイントでトランザクションログが書き込まれるイメージ |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
