TOP書籍連動> commit_delay
まるごと PostgreSQL!
PostgreSQLチューニング実践テクニック

第2回:postgresql.confによるチューニング(2)

著者:石井達夫(ISHII, Tatsuo)   2005/5/25
前のページ  1  2
commit_delay

   同時に実行されるトランザクションがある場合、通常はそれぞれがコミットされたタイミングで同期書き込みが行われますが、commit_delayを0以外にすると、コミットしてから指定された時間だけ待って同期書き込みを行うようになります。同期書き込みを待っている間にほかのトランザクションがコミットすれば、同期書き込みがまとめて行えるため、書き込みの効率が向上します(図2)。

commit_delayの効果
図2:commit_delayの効果


effective_cache_size

   effective_cache_sizeに指定するのは、カーネルやPostgeSQLの共有バッファなど、PostgreSQLが使用するバッファ領域の大きさの推定値です。これはあくまでオプティマイザが参考にするための数字なので、正確な値は必要ありません。しかし、デフォルトの値は1000(単位は8Kバイトなので約8Mバイト)であり、昨今の1〜2Gバイト以上のメモリを搭載したPCに対しては不適当です。たとえば1Gバイトのメモリを実装するシステムであれば、その1/2〜1/4、すなわち65536から32768程度に設定するのが妥当です。

   effective_cache_sizeの値を大きくすると、オプティマイザがインデックスを使用した問い合わせプランを選択する傾向が強くなります。インデックスについては、後ほど詳しく説明します。


random_page_cost

   random_page_costには、テーブルの1ページ(8Kバイト固定長の領域)のアクセスにかかる時間を基準として、インデックスから目的の1ページをアクセスするのにかかる時間を設定します。デフォルトでは4、すなわちインデックスへのアクセスには4倍時間がかかるという設定になっています。メモリを1〜2Gバイト搭載したマシンでは、テーブルが1000万件以上あるようなケースを除くと、デフォルトの4という数字は大きすぎるようです。2または3程度にするのがよいでしょう(1以下にするのは不適切です)。

   random_page_costの値を小さく設定すると、オプティマイザがインデックスを使用した問い合わせプランを選択する傾向が強くなります。

前のページ  1  2


石井達夫
著者プロフィール
石井達夫(ISHII, Tatsuo)
PostgreSQLの開発者、エバンジェリスト。本業でもPostgreSQLによるビジネスに関わっている。著書に「PostgreSQL完全攻略ガイド」「PHPxPostgreSQLで作る最強Webシステム」(技術評論社)などがある。


INDEX
第2回:postgresql.confによるチューニング(2)
  postgresql.confの設定を見直そう
commit_delay