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

まるごと PostgreSQL!
PostgreSQLチューニング実践テクニック

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

著者:石井達夫(ISHII, Tatsuo)   2005/5/25
前のページ  1  2
postgresql.confの設定を見直そう

   PostgreSQLの設定ファイルであるpostgresql.confには性能に関する項目がいくつかあります。まずはこれらについて見直しましょう。
shared_buffers

   shared_buffersには、PostgreSQLのデータベースエンジン(バックエンド)が使用する共有メモリ上のバッファ領域を指定します。shared_buffersは大きすぎても小さすぎても性能が低下します。初期状態ではinitdbの自動設定機能により、1000程度に設定されていると思いますが、できれば8000〜10000程度まで引き上げた方がよいでしょう。これ以上の値を指定すると、バッファ管理のオーバーヘッドにより逆に性能が低下します。

   shared_buffersを大きくするとpostmasterが立ち上がらないことがあります。その場合はOSの共有メモリ領域を拡張します。共有メモリの拡張方法の詳細は、PostgreSQLマニュアルの「16.5.1. 共有メモリとセマフォ」をご覧ください。

   ところで、「メモリが空いているようなのでそれをPostgreSQLで有効に使いたい」という質問に対して「shared_buffersをできるだけ多く取ってください」というような回答を目にすることがよくありますが、前述のようにそれは間違いです。PostgreSQLでは、むしろ余ったメモリをOSにバッファ領域として使ってもらった方がトータルでの性能が向上します。


deadlock_timeout

   PostgreSQLは自動的にデッドロックを検出する仕掛けを持っています。PostgreSQLで採用されているのは、トランザクションが直接/間接にロックを待っている状態をグラフにし、その中に閉ループが含まれているかどうかを調べる方式です。閉ループが含まれていれば、デッドロックが発生します。たとえば、トランザクションT1、T2がテーブルt1、t2に次のような順序でロックをかけると、図1のようなロック状態になり、デッドロック発生と判断されます。

デッドロック状態
図1:デッドロック状態


T1: LOCK TABLE t1;
T2: LOCK TABLE t2;
T1: LOCK TABLE t2;
T2: LOCK TABLE t1; ……… ここでデッドロック発生

   データベースシステムの中には、実際にロック取得を試みて、一定時間経過してもロックが取得できない場合にデッドロックと判断するシステムもあるようですが、これでは単に処理が遅いだけなのか、本当にデッドロックが発生しているのか区別がつかず、誤った判定をする可能性があります。それに比べてPostgreSQLではきちんとデッドロックを検出しているため、このような誤動作の心配がありません。

   ただ、デッドロック検出は比較的重い処理であるため、PostgreSQLではロック取得を試みてすぐではなく、一定時間経ってもロックが取得できない場合のみデッドロック検出処理を行います。この「一定時間」に相当するのが「deadlock_timeout」パラメータです。

   デッドロック検出処理はデータベースセッションごとに行われます。負荷が高い場合はdeadlock_timeoutで指定した時間が経過してもロックが取得できないことが多いので、同時セッション数が多いとより短い間隔でデッドロック検出処理が実行されるようになり(たとえば100セッション存在するときは、最悪、deadlock_timeout/100ごとに検出処理が発生する)、その結果、ますますシステム負荷が高くなるという悪循環に陥ってしまいます。

   この問題を回避するには、deadlock_timeoutを長めに設定します。デフォルトは1000ミリ秒(すなわち1秒)ですが、これに同時セッション数を乗じた値にするとよいでしょう。たとえば同時セッション数が100ならば100000にします。

   deadlock_timeoutを長くすると当然デッドロックの検出が遅れるようになりますが、そもそもデッドロックが発生すること自体が問題なのです。デッドロックが発生しなければ、deadlock_timeoutを長くしても実用上支障ありません。

前のページ  1  2


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


INDEX
第1回:postgresql.confによるチューニング(1)
 PostgreSQLのチューニングとは?
Postgresql.confの設定を見直そう
PostgreSQLチューニング実践テクニック
第1回postgresql.confによるチューニング(1)
第2回postgresql.confによるチューニング(2)
第3回VACUUMの活用によるチューニング
第4回インデックスの活用によるチューニング
第5回高度なインデックスの活用
第6回統計情報の最適化
第7回オプティマイザに関するチューニング
第8回GROUP BYを使用したチューニング

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30