Database Support Blog

  • PostgreSQL
  • EDB
2019.04.16

【PostgreSQL/EPAS11 新機能】autoprewarmでPostgreSQL再起動後の性能劣化を予防しよう

PostgreSQL/EDB Postgres Advanced Server(以降、EPAS)11にて、PostgreSQL/EPAS停止前の共有バッファ(shared buffers)の内容を復元する autoprewarm機能が実装されました。今回は、そのautoprewarm機能についてご紹介します。


autoprewarmとは

autoprewarmは、PostgreSQL/EPAS11でpg_prewarmに追加された再起動前の共有バッファを自動的に復元する機能です。
 
pg_prewarmでは、ユーザが手動でテーブルやインデックスを指定することで共有バッファにキャッシュさせることができますので、初回アクセス時のI/Oによるパフォーマンスダウンを防げます。だだし、再起動後には共有バッファの内容がクリアされてしまいます。
 
autoprewarmでは、停止前の共有バッファの内容が起動時に自動で復元されるため、PostgreSQL再起動後の性能劣化を予防できます。autoprewarmの機能を有効にするには、postgresql.confのpg_prewarm.autoprewarmパラメータをon(デフォルトはon)にした上でshared_preload_libraries = 'pg_prewarm'を設定し、pg_ctl restartコマンドで設定内容を反映させる必要があります。


動作確認

共有バッファの内容は、autoprewarm.blocksファイルにて保持し、PostgreSQL/EPAS起動時にこのファイルを読み、共有バッファを復元します。このファイルにはデータベースのoidやオブジェクトのfilenode、テーブルスペースのoid等が記録されており、バックグラウンドワーカプロセス:autoprewarm masterによって定期的に更新されます。
また、検証結果からautoprewarm機能によりDB再起動前後の共有バッファ上のオブジェクトが同一であることが確認できます。

 
 --postgresql.confの shared_preload_librariesに pg_prewarmを追加
 $ cat postgresql.conf | grep shared_preload_libraries
 shared_preload_libraries = 'pg_prewarm'
 
 --PostgreSQLを再起動して、設定内容を反映
 $ pg_ctl restart
 
 --shared_preload_librariesが適切に設定されていることを確認
 postgres=# show shared_preload_libraries;
  shared_preload_libraries
 --------------------------
  pg_prewarm
 (1 行)
 
 
 --pg_buffercacheを使用してtest表のデータがキャッシュされていないことを確認
 postgres=# SELECT c.relname, count(*) AS buffers
 postgres-# FROM pg_buffercache b INNER JOIN pg_class c
 postgres-# ON b.relfilenode = pg_relation_filenode(c.oid) AND
 postgres-#    b.reldatabase IN (0, (SELECT oid FROM pg_database
 postgres(#                          WHERE datname = current_database()))
 postgres-# GROUP BY c.relname
 postgres-# having c.relname = 'test'
 postgres-# ORDER BY 2 DESC;
  relname | buffers
 ---------+---------
 (0 行)
 
 --test表を参照後は、test表のデータがキャッシュされていることを確認
 postgres=# select * from test;
  col
 -----
  AAA
 (1 行)
 
 postgres=# SELECT c.relname, count(*) AS buffers
 postgres-# FROM pg_buffercache b INNER JOIN pg_class c
 postgres-# ON b.relfilenode = pg_relation_filenode(c.oid) AND
 postgres-#    b.reldatabase IN (0, (SELECT oid FROM pg_database
 postgres(#                          WHERE datname = current_database()))
 postgres-# GROUP BY c.relname
 postgres-# having c.relname = 'test'
 postgres-# ORDER BY 2 DESC;
  relname | buffers
 ---------+---------
  test    |       1
 (1 行)
 
 --PostgreSQLを再起動
 $ pg_ctl restart
 
 --停止前のバッファの状態を復元できるか確認
 
 postgres=# SELECT c.relname, count(*) AS buffers
 postgres-# FROM pg_buffercache b INNER JOIN pg_class c
 postgres-# ON b.relfilenode = pg_relation_filenode(c.oid) AND
 postgres-#    b.reldatabase IN (0, (SELECT oid FROM pg_database
 postgres(#                          WHERE datname = current_database()))
 postgres-# GROUP BY c.relname
 postgres-# having c.relname = 'test'
 postgres-# ORDER BY 2 DESC;
  relname | buffers
 ---------+---------
  test    |       1
 (1 行)
 
 --explain analyzeを実行して、キャッシュヒットするか確認
 
 postgres=#  explain (analyze,buffers) select * from test;
                                           QUERY PLAN
 -----------------------------------------------------------------------------------------------
  Seq Scan on test  (cost=0.00..1.01 rows=1 width=32) (actual time=0.031..0.033 rows=1 loops=1)
    Buffers: shared hit=1
  Planning Time: 0.120 ms
  Execution Time: 0.060 ms
 (4 行)
 

autoprewarmの注意点

autoprewarm機能を有効にしたとしても、VACUUM FULLが実行された場合はバッファのデータがクリアされてしまうので、該当データに再度アクセスする等してキャッシュし直す必要があります。


まとめ

今回は、PostgreSQL11から追加された autoprewarm機能をご紹介しました。autoprewarmを有効にすることで、例えば夜間に定期的にバックアップやメンテナンスのために 再起動を行っても、翌朝のパフォーマンス低下防止に効果が期待できます。 PostgreSQLの再起動後のパフォーマンスに不安がある方は、 PostgreSQL/EPAS11にバージョンアップ することをご検討ください。



■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • EDB
  • PostgreSQL
2025.04.16

PostgreSQLの拡張機能「system_stats」のご紹介

EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。

  • EDB
  • PostgreSQL
2025.03.10

意外な落とし穴!アプリケーション⇒DBデータ型によるパフォーマンス影響

PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます

  • EDB
  • PostgreSQL
2024.09.12

新ツール Postgres Workload Report によるパフォーマンス診断~データベース管理の未来を共に創る!~

EDB Postgres Workload Reportsは、Postgresデータベースのパフォーマンス診断とトラブルシューティングを強化する新しいツールです。OracleのAWRに似た詳細なレポートを提供し、データベースの問題を迅速に特定・解決できるようサポートします。本記事では概要と利用手順をご紹介します。

ページの先頭へ戻る