Database Support Blog

【PostgreSQL/EPAS】パフォーマンス遅延の初動調査に必要な情報と取得方法

PostgreSQL/EDB Postgres Advanced Server(EPAS)の運用中に発生するパフォーマンス遅延の原因調査には様々な情報が必要です。
 
調査に必要な情報の中にはデフォルトでは出力されないものもあるため、原因不明にしないためにはデータベース管理者が事前に取得の準備をしておくべき情報もあります。
 
本記事ではパフォーマンス遅延が発生した際の初動調査で一般的に必要な情報と、その取得方法を紹介します。

事象発生最中に取得するべき情報

セッションの待機やロックに関する情報

パフォーマンス遅延の場合、エラーとは異なりデフォルトで出力されるログファイルには調査に必要な情報が出力されないケースが多くを占めます。そのため、パフォーマンス遅延が発生している最中にインスタンス上のプロセス情報を取得することが重要です。
 
パフォーマンス遅延が発生している最中にpg_stat_activity/pg_locksの情報を取得することで、各プロセスのロック競合や実行されているSQL文を確認できます。
 
実際のパフォーマンス遅延発生中に情報取得用のSQLを手動で実行するのは容易ではないと思いますので、SELECTリストには、current_timestamp関数の追加で情報取得時刻を記録しつつ、定期取得することをお勧めします。

psql -c "select current_timestamp, * from pg_stat_activity"
psql -c "select current_timestamp, * from pg_locks"

また、PostgreSQL/EPAS9.6以上をご利用であれば、pg_blocking_pidsシステム情報関数と、pg_stat_activityビューを使用することでロック獲得中のプロセスと、ロック獲得待ちをしているプロセスを簡単に確認することが可能です。

   
 postgres=# \x
 Expanded display is on.
 
 postgres=# SELECT pid, pg_blocking_pids(pid), state, wait_event_type, wait_event,query
 postgres-# FROM pg_stat_activity;
 -[ RECORD 1
 ]----+----------------------------------------------------------------------------
 pid              | 19495 <-- ★ロック待ちしているプロセス
 pg_blocking_pids | {19724}
 state            | active
 wait_event_type  | Lock★
 wait_event       | transactionid
 query            | update test set col2 = 'AAAAA' where col2 = 'AAA';
 -[ RECORD 2
 ]----+----------------------------------------------------------------------------
 pid              | 19724 <-- ★ロック獲得中のプロセス
 pg_blocking_pids | {}
 state            | active
 wait_event_type  |
 wait_event       |
 query            | SELECT pid, pg_blocking_pids(pid), state,
 wait_event_type, wait_event,query+
                  | FROM pg_stat_activity;
   

OS側での負荷情報

PostgreSQL/EPASもOS上で動作するアプリケーションの1つですので、遅延の原因が他のアプリケーションやOS側の問題に起因する可能性もあります。
 
平常時と比較することが調査に有効なケースもあるため、パフォーマンス遅延発生中だけでなく、定常的にOS側のパフォーマンス情報を取得することをお勧めします。
 
下記にWindows環境、Linux/Unix環境それぞれの情報取得例を記載します。

Windows(パフォーマンスモニタ)のカウンタ追加の例

使用可能なカウンター インスタンス
+ LogicalDisk - % Free Space _Total
+ LogicalDisk - % Disk Time _Total
+ LogicalDisk - Avg. Disk Queue Length _Total
+ Memory - Available Bytes なし
+ Memory - Cache Bytes なし
+ Memory - Page/sec なし
+ PhysicalDisk - Avg. Disk sec/Write _Total
+ PhysicalDisk - Avg. Disk sec/Read _Total
+ PhysicalDisk - Avg. Disk Queue Length _Total
+ Process - %Processor Time postgres
+ Process - IO Data Bytes/sec postgres
+ Process - Page Faults/sec postgres
+ Process - Virtual Bytes postgres
+ Processor - % Processor Time _Total
+ System - Processor Queue Length なし

UNIX/Linuxの例

+ vmstat
+ top/topas
+ ps
+ iostat ...etc

事象発生後に取得できる情報

以下の情報は事象発生後でも取得/確認できる情報です。ただし、事象発生後にパラメータの設定が変更されたり、ログファイルのローテーションをされている環境ではログファイルが削除されたりする可能性があるため、事象発生後、できるだけ速やかに情報を採取ください。

postgresql.conf

DBクラスタに対して設定されているパラメータの内容を確認し、遅延の原因が適切でないパラメータ設定に起因していないかを確認する目的で取得します。
 
デフォルトでは、show data_directory;コマンドで表示されるディレクトリ配下に格納されています。

PostgreSQL/EPASのサーバログ

パフォーマンス遅延の発生タイミングに関連のあるエラーやメッセージの有無を確認する目的で取得します。
 
PostgreSQL(EPAS)のロガーを有効にしている場合のデフォルトは、data_directoryパラメータで指定されたディレクトリ/log 配下(PostgreSQL9.6以前の場合はpg_log配下)に格納されています。

発生事象の概要

サポートにお問い合わせをいただく場合は、ログファイルを見る起点の時刻の判断や発生事象について可能な限り正確に把握するために次のようなことを確認させていただくケースがございます。

・事象発生時刻
・特定の処理のみの遅延/全体的な処理遅延
・(特定の処理の場合)psqlから再現性は可能か
・現在も発生している問題か(解消している場合はその方法/時刻)

事象発生前にしておくべき準備

ログ関連パラメーターの設定

後述しますが、パフォーマンス遅延の調査には PostgreSQL/EPASのサーバログに問題視するべき情報がないか確認することとなります。
 
デフォルトの設定のままだと、PostgreSQL/EPASのサーバログから障害発生時の状況を詳細に把握することが難しくなりますので、過去の 弊社記事 を参考に設定をご検討ください。

定期的な情報取得

上述しましたように、パフォーマンス遅延の初動調査に必要な情報には、遅延発生最中に取得しなければならないものがあります。
そのため、定期的な情報取得が実現できるよう、上述の情報を含んだサンプルスクリプトをご用意しました。
Linux環境をご利用の方に限定されてしまいますが、上述で記載した pg_stat_activityや pg_locksの情報に加えて、psや top等の情報も 1分ごとに 5回取得できます。

調査のために、事象が発生している最中だけではなく、比較対象として事象が発生していない時(正常時)にも情報を採取してください。
下記スクリプト内の PGPORT/PGUSER/PGDATABASEといった環境変数の値にはお客様環境の情報を代入し、「chmod +x <サンプルスクリプト名>」コマンドにて実行権限を付与した上でご利用ください。

サンプルスクリプト

#!/bin/sh
export PGPORT=5432
export PGUSER=postgres
export PGDATABASE=postgres
echo "Please wait for five minutes."
dmesg | grep Memory > dmesg.txt
EXECNT=0
while (( ${EXECNT} < 5 ))
do
EXE_DATE=`date +'%Y/%m/%d %H:%M:%S'`
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> ps_ef.txt
ps -elf >> ps_ef.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> mpstat.txt
mpstat 1 3 >> mpstat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> meminfo.txt
cat /proc/meminfo>> meminfo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> slabinfo.txt
cat /proc/slabinfo >> slabinfo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> ps_eo.txt
ps -eo pid,%cpu,%mem,rss,vsz,stat,wchan=WIDE-WCHAN-COLUMN,args >> ps_eo.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> top.txt
top -b -n 1 | head -50 >> top.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> vmstat.txt
vmstat 1 3 >> vmstat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> iostat.txt
iostat -x 1 3 >> iostat.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> swapon.txt
/sbin/swapon -s >> swapon.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> netstat1.txt
netstat -a -i -n >> netstat1.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> netstat2.txt
netstat -s >> netstat2.txt
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> pg_stat_activity.txt
psql -c "select clock_timestamp(),* from pg_locks" -A -F , > pg_locks.csv
echo -e "¥n¥n------------- Exec Date " ${EXE_DATE} "--------------" >> pg_locks.txt
psql -c "select clock_timestamp(),* from pg_stat_activity" -A -F , > pg_stat_activity.csv
sleep 60
EXECNT=`expr ${EXECNT} + 1`
done
exit

まとめ

パフォーマンス障害はサポートセンターにいただくことの多いお問い合わせですが、事象発生タイミングの情報を取得していなかったために、原因追求や有効な対処方法の提示が難しいケースがあります。
 
今回は初動調査で必要になる情報を紹介しておりますので、状況によっては追加の情報取得が必要になるケースもありますが、パフォーマンス遅延に備え、ご準備をいただくことで何かしらの見解をお出しすることができる可能性は高まります。


■本記事の内容について
 本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

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

関連している記事

  • Oracle Database
  • Oracle Cloud
2025.12.25

Oracle Databaseユーザー必見!ZRCVで始めるランサムウェア対策

ランサムウェアの脅威からデータベースを守る!OCIのフルマネージドバックアップサービスZRCVは、3-2-1-1-0ルールに対応し、データ損失ゼロに近い復旧を実現します。本記事では堅牢な保護機能と、GUIで完結するわずか5ステップのシンプルな設定方法を解説します。

  • Oracle Database
2025.12.22

【Oracle Database】FAQを活用したDBエンジニア育成

本記事では、お客様の自己解決率向上のために注力したFAQ作成、および、そのFAQ作成をエンジニア育成に活用した当社ならではの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2025.12.12

Oracle AI World2025視察記

今年もオラクル社の年次イベント「Oracle AI World 2025」が開催され、アシストからも11名の社員がラスベガス現地で参加しました。 本記事では「Oracle AI World 2025 視察記」として「Oracle AI World 2025のハイライト」と「アシストの注目ポイント」を、Oracle AI World 2025全体の雰囲気とともにお伝えします。

ページの先頭へ戻る