HTTP/2 200 date: Mon, 14 Jul 2025 20:50:51 GMT server: Apache x-content-type-options: nosniff last-modified: Fri, 26 Dec 2014 04:17:35 GMT etag: "375f-50b16cde3d5c0" accept-ranges: bytes content-length: 14175 cache-control: max-age=1209600 expires: Mon, 28 Jul 2025 20:50:51 GMT content-type: text/html; charset=UTF-8

TOP＞設計・移行・活用＞ 今回のチューニング 今すぐできるPostgreSQLチューニング 第３回：性能か安定か？ライタープロセスのチューニング 著者：日本PostgreSQLユーザ会  片岡 裕生   2005/8/3 1   2  3  次のページ 今回のチューニング    これまでの2回のチューニングでは、共有バッファとトランザクションログバッファの調整を取り上げました。この2つのチューニング項目はPostgreSQLのディスクI/Oを減らすために重要な役割を果たしています。そのため、これらの設定を適切に調整してあげることで性能を大きく改善（16クライアント時で48tpsから90tps）できました。    さて今回は、PostgreSQL 8.0から導入された「ライタープロセス」を取り上げたいと思います。 ダーティページとは    PostgreSQLでは共有バッファをディスクキャッシュとして使っています。このためデータの更新は共有バッファ上で行われるのみで、すぐにはハードディスクに書き込まれません。ですがこれは後で必ず書き込まなければならないデータです。共有バッファは「ページ」という8Kバイトの単位で管理されており、後でハードディスクに書き込まなければならないページのことを特に「ダーティページ」と呼びます。 ダーティページの扱われ方    ダーティページは更新が行われるデータベースサーバであれば常に存在し、徐々に増えていくものです。ですがダーディページはいつか必ずハードディスクに書き込まれます。では、いったいいつ書き込まれるのでしょうか？    書き込みのタイミングは2つあります。    1つは共有バッファが足りなくなった場合です。PostgreSQLエンジンがハードディスク上のデータベースのある部分へアクセスを必要としたとします。するとPostgreSQLエンジンはその部分を共有バッファに読み込もうとします。    ですがここで共有バッファのすべてが他のデータで埋まっていて空きがなかったとします。もちろんこのままでは読み込む場所がありませんので、PostgreSQLエンジンは読み込みに先立って、共有バッファ中で再びアクセスされる可能性が最も少ないと思われるページを1つ選び出し、そのページが持っているデータを捨てることで空きを作るのです。ただし選び出したページがダーティページだったなら、捨てる前にハードディスクに書き出します。これが1つ目の書き込みのタイミングです。    もう1つの書き込みのタイミングはチェックポイントの時です。チェックポイントとは、共有バッファ上の全ダーティページをハードディスクに書き込む処理のことです。    PostgreSQLでは共有バッファ上のダーティページをすぐにハードディスクに書き込むことはせず、代わりにトランザクションログを随時ハードディスクに書き込んで障害時のデータの信頼性を確保していることは前回説明しました。    ですがこのままだとトランザクションログが貯まる一方ですから、どこかでトランザクションログを削除できるタイミングを作らないといけません。それがチェックポイントなのです。    トランザクションログは未書き込みのデータを復元するためにリカバリで用いられますが、チェックポイントによってダーティページをすべてハードディスクに書き出せば未書き込みのデータもなくなり、それ以前のトランザクションログが不要になり削除できるようになります。    このようにチェックポイントでは、ダーティページの書き出しと同時に不要なトランザクションログの削除も行っているのです。ちなみにチェックポイントは、特に指示しなくてもPostgreSQLエンジンによって定期的に実行されています。 ダーティページにまつわる性能の問題    ダーティページの存在には2つの問題があります。    1つはトランザクションのレスポンスタイムの低下です。共有バッファが足りなくなると、共有バッファ中で最も不要と思われるページを捨てて空きを作るわけですが、このときもしも捨てるページがダーティページだった場合には先にハードディスクへ書き出す必要があります。これによりレスポンスタイムが低下します。これを避けるには、共有バッファ中の最も不要と思われるページを常にダーティでない状態に保つ必要があります。    もう1つの問題は、チェックポイント処理時間の増大です。更新の多いデータベースでありがちなことですが、共有バッファ中のダーティページが増えてくると、それらすべてをハードディスクに書き出すチェックポイント処理の所要時間が長くなってしまいます。    チェックポイント処理中はハードディスクへのアクセスが集中するためトランザクション処理能力は大きく落ち込みますが、そのような性能の悪い期間がより長引いてしまうのです。これを避けるには、共有バッファ中のダーティページの数を減らすようにしなければなりません。 1   2  3  次のページ 著者プロフィール 日本PostgreSQLユーザ会  片岡 裕生 1995年よりインターウィズという屋号で個人事業を営む。普段はPostgreSQLを用いたウェブアプリケーション開発などを行う。各コンピュータ情報誌にてPostgreSQL関連記事や連載を執筆。日本PostgreSQLユーザ会の創立メンバーの1人で、同会の技術担当理事、PostgreSQLのしくみ分科会座長を経て、2004年度からは理事長を勤める。 INDEX 第3回：性能か安定か？ライタープロセスのチューニング 今回のチューニング   ダーティページを減らすライタープロセス   チェックポイント時の性能劣化を防ぐなら