ハクソク

世界を動かす技術を、日本語で。

Postgresを遅くする方法

302日前原文(byteofdev.com)

概要

  • Postgresを 意図的に遅くする ための設定例とその理由
  • postgresql.conf パラメータのみでの調整に限定
  • 実際のベンチマーク環境と 測定方法 の紹介
  • キャッシュ・自動バキューム・WAL（Write-Ahead Log）の 徹底的な非効率化
  • ログ出力 や副作用も考慮した詳細な設定例

Postgresを意図的に遅くする設定チャレンジ

  • 多くの人が Postgresの高速化 に注力する中、敢えて 遅くする方法 を模索
  • ハードウェアやインデックス削除などの極端な手法は禁止、 postgresql.conf 内のパラメータ調整のみ許可
  • 最低限1トランザクションは処理可能な状態を維持する制限
  • ベンチマーク条件
    • TPC-C（Benchbase 128 warehouses使用）
    • 100接続、各10,000 TPS目標
    • Postgres 19devel（2025年7月時点最新版）
    • Linux 6.15.6, Ryzen 7950x, 32GB RAM, 2TB SSD
    • 各テスト120秒、2回実行（ウォームアップ＋計測）

基準値測定

  • デフォルト設定（shared_buffers, work_mem, worker数のみ増加）で 7082 TPS 達成

キャッシュの徹底縮小

  • Postgresは shared_buffers でディスクから読み込んだデータをRAMにキャッシュ
  • キャッシュを極小化することで ディスクI/O依存度増大、レスポンス低下
    • 例：shared_buffers = 8MB → キャッシュヒット率70.52%、リードシステムコール約300倍増加、TPSは1/7に
    • shared_buffers = 2MB（最小値付近）→ 500 TPS以下

自動バキューム・ANALYZEの過剰化

  • autovacuum は通常、不要な領域解放や統計情報収集のため適切な頻度で実行
  • これを極端に高頻度化し、常時バックグラウンドで 無駄な処理 を走らせる
    • autovacuum_vacuum_insert_threshold = 1
    • autovacuum_vacuum_threshold = 0
    • autovacuum_vacuum_scale_factor = 0
    • autovacuum_vacuum_max_threshold = 1
    • autovacuum_naptime = 1（最小値）
    • vacuum_cost_limit = 10000（バキュームを止めない）
    • vacuum_cost_page_dirty/hit/miss = 0
    • maintenance_work_mem = 128kB（バキューム用メモリ最小化）
    • log_autovacuum_min_duration = 0、logging_collector = on、log_destination = stderr,jsonlog（全ログ出力）
    • ANALYZE関連も同様に最小閾値化
  • 副作用：バキューム・ANALYZEが 1秒ごとに連発、キャッシュヒット率低下と合わせ I/O負荷増大
  • この時点で 293 TPS まで低下

WAL（Write-Ahead Log）による書き込み負荷増大

  • Postgresはデータ変更を即座にWALへ書き込み、その後チェックポイントでディスク反映
  • WALの フラッシュ間隔・チェックポイント頻度 を限界まで短縮
    • wal_writer_flush_after = 0（書き込み都度フラッシュ）
    • wal_writer_delay = 1（最小遅延）
    • min_wal_size = 32MB, max_wal_size = 32MB（最小セグメント数）
    • checkpoint_timeout = 30（最小値）
    • checkpoint_flush_after = 1（8kBごとにフラッシュ）
    • wal_sync_method = open_datasync（最も遅い同期方式）
    • wal_level = logical（最大情報量出力）
    • wal_log_hints = on, summarize_wal = on, track_wal_io_timing = on（追加負荷）
    • checkpoint_completion_target = 0（I/O分散なし）
  • 結果： TPSは二桁台 （1/70以下）まで低下、WAL効率の悪化をログでも確認

まとめ

  • Postgresを遅くする には、キャッシュ縮小・自動バキューム頻発・WAL書き込み負荷増大の 三本柱
  • これらは 本来推奨されない設定 だが、パラメータの理解や逆説的なチューニング知識の深化に有用
  • 各設定は 副作用や運用リスク を伴うため、実運用環境では絶対に真似しないこと

Hackerたちの意見

これめっちゃいいね！物事を悪化させる方法についての続編やシリーズ本があったら最高だな。そうすることで、逆に物事を良くする方法を学べるかも。O'Reillyみたいに、表紙に下手くそなファンタジー動物が描かれてて、例えば、7歳の子供が描いたユニコーンが体の両側に頭があって、両方がAirPodsで話しながら詐欺師にお金を渡したり、パワーポイントのスライド作ったり、食べ過ぎたり、薬やったり、Facebookでライブ配信したり、遠くに列車が見える線路の上に立ってたりする感じ。

└

創作の授業を受けたことがあって、悪い文章を読んで分析する部分があったんだ。それから良い文章をわざと下手に書き直すっていうのをやったんだけど、それが今までやった中で一番役に立った練習だった。

└

この戦略は実際に第二次世界大戦中に使われてたんだ。パイロットが無事に帰れるようにするためにね。今みたいに天気予報が発達してなかったから、気象学者たちは最も多くの命が失われる条件を特定して、ミッションの指揮官たちと一緒にその条件を満たさないようにミッションを「設計」してたんだ。出典: https://medium.com/butwhatfor/suppose-i-wanted-to-kill-a-lot...

└

https://orlybooks.com/

B・サンダースンへの言及、いいね！

これ、絶対天才的だと思う。何かを最適化するなら、まずは逆のことをやってみるのもアリじゃない？実際にデータベース（や他のシステム）をちゃんと調整してることってどれくらいある？パフォーマンス向上って本当に科学に基づいてるのか、それともカゴ文化みたいな感じなのか、他の何かなのか。

└

新しいクラウドプロバイダーと仕事する時はいつもそうしてる。シリーズAをできるだけ早く使い切って、その後でクラウドの支出を最適化するんだ！

これ、すごく良かった。最後にデッドロックの話が出てきたから、トランザクションの隔離設定を調整する必要があるのかなって思った。

「Hyperbole and a Half」とdb管理のシナジーを感じた。読んでてめっちゃ楽しかったし、いくつかのことも学べたよ。

「ダファーズ・ドリフトの防衛」は、このジャンルの初期の例だね。本の最初の話では、部隊レベルの戦術を下手にやって（ほとんどの部下を失う）学ぶんだ。次の話では、いくつかの戦術パラメータが調整されて、結果が改善された形で再度語られる。新しい戦術書「マーズの音楽家2」でも同じアプローチが使われてるよ。「マーズの音楽家」の最初のチーム・バジャーの話は、「ダファーズ・ドリフト」の最初の話にすごく似てて、場所や装備、技術の変更が可能なんだ。警告：以下のPDFを見てね。ダファーズ・ドリフトの防衛 https://www.armyupress.army.mil/Portals/7/combat-studies-ins... マーズの音楽家2 https://api.army.mil/e2/c/downloads/2023/01/19/5a01ae1c/16-1... 「戦闘の埃と煙の中に混ざった火薬の硫黄臭が、チーム・バジャーの指揮官フレッド・モリス大尉の感覚を支配していた。彼は、かつて世界最高の戦闘機械だったM1A2エイブラムス戦車やM2A3ブラッドレー戦闘車の残骸の中に座っていた。今や彼の部隊の戦車やブラッドは、ただの煙を上げる残骸となり、燃える電子機器の独特な匂いが、目の前の悲惨な光景に新たな要素を加えていた。彼は静かに、自分の愛するチームの壊滅に至るまでの出来事を振り返っていた。敵の部隊が、彼が予想していた以上に手強く、彼が考慮していなかった資産や能力、戦術を使ってきたことを思い出し、心がざわついた。同時に、自分の広範な戦闘力を発揮できず、決定的な勝利を得られなかった理由を考えていた。彼はとても準備万端で、自信満々だったし、チームも一生懸命準備していたと思っていた。それでも、彼らはあっさりと敗北してしまった。どうしてそんなことが起こるんだ？任務部隊の指揮官ジョー・ミルナー大佐は、チーム・バジャーに任務部隊の主戦闘エリア（MBA）の中心を防衛し、攻撃してくる敵の機械化歩兵旅団を壊滅させるよう指示した。具体的には、モリス大尉とチーム・バジャーは、敵の主力機械化歩兵大隊に対して、敵が最も進軍しやすい通路にあるバトルポジション（BP）バジャーで防衛することになっていた。その機械化歩兵大隊は、まるでそこに存在しないかのようにチーム・バジャーを押しのけて進んでいった。」

└

映画「恋はデジャヴ」や（特に）「オール・ユー・ニード・イズ・キル」も参考にしてみて。あと、最近イギリスの軍事ブログに掲載されたこの現代的なオマージュもね：https://wavellroom.com/2025/07/25/defence-baltic-bridge-drea...

見える化ツールのための操作環境が遊び場みたいに用意されるといいな。使い方のシミュレーションができる、そこそこのサイズのSaaSみたいなやつと、普通のpostgres/rabbitのセットアップがあれば最高。デバッグツールや戦略がちゃんとしてるか確認できる場所が欲しい。

これ、素晴らしいね。

インデックスとか、複数のテーブル、トランザクション、エンティティ関係、参照整合性なんて忘れちゃえ。TRIRIGAの初期バージョンみたいに、すべてのデータを一つのテーブルでKVS NoSQL SQLとして使えばいいんだ。

どのダイヤルを回せるか見つけて、実際に回してみて、どれくらい余裕があるか、どれだけ壊れそうかを確認するアイデアがすごく好き。こういう人工的な制限が、システムのボトルネックを見つけたり、どの最適化をすべきかを見つけるのに役立つことがあるからね（例えば、N+1問題が見逃されることがあるけど、その時はパフォーマンスが十分良かったから、データが増えたら崩れちゃったりする）。