PostgreSQLの運用で、
「システムテストまでは問題なかったのに、本番で急に遅くなった」
という経験はありませんか？
実際の現場では、インデックス・VACUUM・fillfactorなど、
運用のちょっとした設計ミスが原因で性能問題が発生することがよくあります。
本記事では、私が実際にハマったポイントをまとめます。
→ 同じようなトラブルを防ぐためのヒントになれば幸いです。
①インデックス再構築
■結論
インデックスの断片化は性能劣化の原因になるが、
運用に組み込まれていないことが多い。
■その1：システムテストで発覚
システムテスト時に性能問題が発生し、
調査の結果、インデックスの断片化が原因でした。
インデックスを再構築することで性能が改善したため、以下の運用を追加しました。
・インデックスの状態確認
・インデックスの再構築
当時はインフラチームに所属しており、アプリチームからの依頼で対応しました。
このとき、「DBに詳しい人がいないと 断片化に気付けず、問題解決できない」
という課題を認識しました。
■その2：本稼働時に発覚
インデックス再構築は本来必要な運用ですが、
実際には多くのプロジェクトで実施されていません。
ある案件で確認したところ、インデックスが断片化していました。
しかし、
・予算が確保できない
・目に見える問題が出ていない
という理由で、対応は見送られました。
「問題が起きないと改善されない」という典型的な例でした。
→ 放置すると 更に性能劣化します。
②不要なインデックス
基本設計でインデックスを設計し、その後 見直していないため、ありがちです。
以下のケースは非常に多いです。
・スキャン回数が0回のインデックス
・Primary Keyと重複するインデックス
インデックスは、本の索引のように、順に並ぶようにデータを登録しています。
使われることがないインデックスのために、登録時の負荷が かかり続けます。
「とりあえず作る」は危険です！
③インデックス乱発
よくある誤解です。
・インデックスを作れば速くなる
・常にインデックススキャンが速い
この結果、「性能対策 = インデックス追加」となり、インデックスが乱発されます。
実際には、テーブルサイズやカーディナリティによっては
シーケンシャルスキャンの方が高速な場合があります。
→ 結果的に、全体のパフォーマンスが悪化します。
④インデックス断片化の閾値
インデックス再構築を運用に組み込む場合、
「どの程度 断片化したら実施するか」という基準（閾値）が必要になります。
しかし実際には、
・アプリチームでは判断できない
・DB知識が不足している
という理由で 決められないケースがほとんどです。
DBエンジニアの関与が重要だと感じました。
→ 結果として、再構築の判断が曖昧になり、放置されがちです。
⑤VACUUMによる高負荷
ディスクI/Oがボトルネックになるケースは多いです。
古いデータをジョブで削除する場合、注意が必要です。
複数のテーブルを削除すると、
複数のテーブルでVACUUMが起動することになります。
VACUUMは負荷が高いため、autovacuum_max_workers で制限され、
同時に実行できる数が決まっています。
その結果、長時間にわたりVACUUMが継続し、ディスクI/Oが高負荷状態になりました。
■対策
・テーブルごとに削除タイミングをずらす
・autovacuum関連の設定を見直す
・VACUUMをコマンドで実行する
運用設計が非常に重要です。
→ 特に夜間バッチと重なると影響が大きい。
⑥fillfactor
更新が多いテーブルでは、fillfactorの設定が重要です。
しかし、この値の決定は容易ではありません。
インフラを担当していた私が、「とりあえず90でどうか」
と提案したところ、全テーブルに適用されました。
その後、VACUUMが多発したため、
「70に変更して、統計情報を見ながら決める」と提案しましたが、
再び全テーブルに適用され、その後 変更されることは ありませんでした。
結果として、適切なチューニングは行われませんでした。
→ 一律設定は ほぼ確実に失敗します。
■ポイント
・小さすぎる → VACUUMが多発
・大きすぎる → 無駄な領域増加
統計情報を確認し、テーブルごとに調整する。
補足：Oracleでの事例
PostgreSQLではありませんが、印象的な事例です。
本稼働後に参画したプロジェクトで、インデックス再構築の運用が実施されていました。
ある日、システムが突然停止しました。
調査の結果、INDEX再構築時に通常使用するTEMP表領域ではなく、
SYSTEM表領域が使用されていたことが判明しました。
その結果、SYSTEM表領域が枯渇し、ORACLEが停止していました。
→ 運用の有無だけでなく、その中身が正しいかが重要です。
補足（より深く学びたい方へ）
今回のような「性能問題の原因分析」やチューニングの具体的な
手順について、講座で体系的に解説しています。
※現在Udemyセール中のため、通常より安く受講できます。
セールは残り3日です。
URL：https://www.udemy.com/course/postgresql-sql/?referralCode=64B372729B6BC0073ACB