Database Support Blog

Database Support Blog>性能劣化を引き起こすチェックポイント多発の確認・対処方法

  • PostgreSQL
2016.10.04

性能劣化を引き起こすチェックポイント多発の確認・対処方法

性能劣化を引き起こすチェックポイント多発の確認・対処方法

チェックポイントはディスクI/Oを伴う処理ですので、短い間隔で繰り返し実行されると性能劣化を引き起こす可能性があります。本記事では、PostgreSQL(9.5以降)でチェックポイントが多発しているかの確認と、多発していた場合の対処方法について説明します。

また、参考記事として、「【PostgreSQL9.5】max_wal_sizeとmin_wal_sizeの概要について 」もご覧いただけると理解が深まります。PostgreSQL9.5でチェックポイントの間隔を調整する際に使用するパラメータであるmax_wal_sizeとmin_wal_sizeの概要について解説しています。

なぜチェックポイントが多発すると性能が劣化するのか?

チェックポイントは、以下の理由からI/O負荷の高い処理です。チェックポイントが多発することでPostgreSQLが動作するサーバ全体の性能に影響を及ぼす可能性があります。

  • チェックポイント時点の全てのダーティバッファをデータページに書き出す必要があるため
  • チェックポイント直後のWALファイルへの書き込み量が増えるため
  • データページの一貫性を保証するために、各チェックポイント後の最初に変更されるデータページは、そのページ全体の内容がWALファイルに記録されます。

チェックポイントが多発しているかの確認方法

PostgreSQLのログファイルから、max_wal_sizeの値を増やすことを促すメッセージの有無を確認します。以下のメッセージが頻出している場合は、チェックポイントの間隔が短すぎます。

HINT: Consider increasing the configuration parameter "max_wal_size".


ログファイルからこのメッセージを確認できない場合、または、稀にしか確認できない場合は、max_wal_sizeのチューニングは不要です。

このメッセージは、前回チェックポイントからパラメータ checkpoint_warning (デフォルト30秒) に指定された秒数以内に再度チェックポイントが行われた場合に記録されます。checkpoint_warningにデフォルト値の30を設定している場合、以下の例では出力が頻発しているため、max_wal_sizeのチューニングが必要であると判断できます。

PostgreSQLのログファイルに当該メッセージが連続して出力されている例

[2016-08-09 10:54:25 JST] 19288[141]LOG: checkpoints are occurring too frequently (27 seconds apart)
[2016-08-09 10:54:25 JST] 19288[142]HINT: Consider increasing the configuration parameter "max_wal_size".
〜中略〜
[2016-08-09 10:54:53 JST] 19288[145]LOG: checkpoints are occurring too frequently (28 seconds apart)
[2016-08-09 10:54:53 JST] 19288[146]HINT: Consider increasing the configuration parameter "max_wal_size".
〜中略〜
[2016-08-09 10:55:21 JST] 19288[149]LOG: checkpoints are occurring too frequently (27 seconds apart)
[2016-08-09 10:55:21 JST] 19288[150]HINT: Consider increasing the configuration parameter "max_wal_size".


チェックポイントが多発していた場合の対処方法

チェックポイントが多発していた場合には、PostgreSQLのログファイルに当該メッセージが頻発しなくなるまで、以下の手順でwal_max_sizeの値を増やします。デフォルトは1GBに設定されています。max_wal_sizeはデータベースクラスタ単位で設定するパラメータのため、任意のデータベースに接続して作業を行うとすべてのデータベースに設定が反映されます。

1) PostgreSQLのスーパーユーザで任意のデータベースに接続

 (OSのプロンプトから実行)
  psql -U <PostgreSQLのスーパーユーザ> -d <任意のデータベース名>

Linux環境でtestuserスーパーユーザでtestdbデータベースに接続する例

 $ psql -U testuser -d testdb


2) max_wal_sizeの設定値変更

 (psqlのプロンプトから実行)
  ALTER SYSTEM SET max_wal_size='<設定値>';

max_wal_sizeを1.5GBに設定する例

 testdb=# ALTER SYSTEM SET max_wal_size='1536MB';


3) PostgreSQLのリロード

 (OSのプロンプトから実行)
  pg_ctl reload

Linux環境でPostgreSQLのリロードを実行する例

 $ pg_ctl reload


なお、min_wal_sizeの設定は、チェックポイントの間隔に影響しないため変更する必要はありません。

補足:PostgreSQL9.4以前のバージョンでチェックポイントが多発しているかを確認する方法

PostgreSQL9.4以前のバージョンでチェックポイントが多発しているかを確認するには、PostgreSQLのログファイルに以下のメッセージが頻発していないかを確認します。以下のメッセージが頻発して出力されている場合は、以下のメッセージが頻発しなくなるまでcheckpoint_segmentsの値を増やしてください。

HINT: Consider increasing the configuration parameter "checkpoint_segments".


まとめ

今回は、PostgreSQLのログファイルからチェックポイントが多発していないかを確認した上で、チェックポイント多発による性能劣化に対処する方法をご紹介しました。

皆さまの環境でも上述のHINTのメッセージが出力されていないかをぜひ確認してみてください。仮に、HINTのメッセージが頻発している場合には、今回紹介した方法でPostgreSQLの処理性能が大きく改善されるかもしれません。

執筆者情報

家島 拓也

サービス事業部 サポートセンター

2007年にアシストに入社して以来、ORACLE製品やPostgreSQL・EDB Postgres製品のサポートに従事してきました。このブログではサポート対応で得た知識を元に、お客様がお困りになることが多い問題や各製品の新機能に関する検証結果などを紹介します。

関連している記事

  • PostgreSQL
2016.12.01

【SR+HS環境の落とし穴】スタンバイが要求したWALが上書きされる障害の予防策

PostgreSQLのSR+HS環境でスタンバイが要求したWALが上書きされる障害の予防策を紹介します。

  • EDB Postgres
  • PostgreSQL
2016.11.11

【EDB Postgres/PostgreSQL】うるう秒(閏秒)の対応

EDB Postgres/PostgreSQLでのうるう秒(閏秒)の対応方法について解説します。2017年元旦にトラブルとならないよう、準備しましょう。

  • PostgreSQL
2016.06.03

【PostgreSQL 9.5】max_wal_sizeとmin_wal_sizeの概要

PostgreSQL 9.5で登場したmax_wal_sizeとmin_wal_sizeの概要と、checkpoint_segmentsがこれら2つのパラメータに置き替えられたことによるメリットご紹介します。

アシストサポートセンターのご紹介 Oracle Database研修

ページの先頭へ戻る