2022」の15日目の記事です。こんにちは!NTTテクノクロスの中村です。情報収集ツール「pg_statsinfo」を使用している人向けに作成しました。ツールを導入したものの「レポートは見たことがない」ってこと、結構ありますよね。そんなときの調査の取っ掛かりになればよいなぁ、と思いながらこの記事を書きました。毎年2月ごろに、最新のPostgreSQL対応版がリリースされています)解析の準備をしようまず、簡易レポートをもらったら、解析のために以下の情報ソースを準備しましょう。簡易レポートの項目が示す内容は、このドキュメントとEXCELファイルがリファレンスになります。WEBドキュメントを開くhttps://github.com/ossc-db/pg_statsinfo/blob/main/doc/pg_statsinfo-ja.md・レポート項目が記載されているEXCELファイルを開くhttps://github.com/ossc-db/pg_statsinfo/blob/14.0/doc/files/pg_statsinfo_v14_report_infomation.xls(上記WEBドキュメント内からリンクされています)pg_statsinfo簡易レポートとは?pg_statsinfoは、データベース内のシステムビューやマシンリソースの情報を定期的に蓄積しています。ある時点の情報をまるごと写し取っているため、「スナップショット」と呼んでいます。2つのスナップショットを指定して、その差分情報を整理したものをテキストで出力してくれる。これが簡易レポートです。簡易というのはテキストベースだからですね。レポートされる情報は、レポート作成時に指定した、スナップショットの開始時点と終了時点の差分もしくは、終了時点の情報になります。レポートに出力されている情報がどの時点の情報なのかは、EXCELの「レポート項目一覧」シートの「特記事項」に記載されています。イメージとしては以下のような形になります。ちなみに簡易じゃないレポート(pg_stats_reporter)もあります。こちらはグラフや表付きで豪華なうえ、ブラウザで見ることができます。https://github.com/ossc-db/pg_stats_reporter確認する項目はここ!まずは10個の着目点!簡易レポートは情報がいっぱいあり、どこから見ればいいか悩みますね。そこで、いくつかの観点に絞り込んでみました。ここでは、性能が出ない(遅い)理由として、以下の5つにアタリを付けて確認していきます。パラメータがきちんと反映されているかを確認します。設定漏れ、設定値誤りがないか等をチェックします。デフォルト値から変更したパラメータがリストされます。設計書と突き合わせたりし、明らかにおかしな設定値がないかを確認します。file●キャッシュヒット率が低くないか2キャッシュヒット率を確認データベース毎の平均値と、アクセス頻度の高いテーブル別にキャッシュヒット率を確認します。キャッシュヒット率99%以上はOKと判断してよいと思います。極端に小さい場合は、問題がないか確認する必要があります。Ratio」の値から確認します。データベース別に複数出力されていますので、全て確認しましょう。%」と低いことがわかりますね。Ratio(%)」(一番右の列)の値から確認します。こちらはアクセス頻度の高いテーブルの情報のみが出力されています。ここでは、「pgbench_accounts」テーブルのキャッシュヒット率が50.9%と低いことがわかります。99.8●サーバが重くないか3CPU使用率を確認CPU使用率と、ロードアベレージを確認します。ここの値はスナップショット取得時の情報となります。スナップショット間に高負荷になっているような状態を確認するために、VMSTATやSARなどの情報も別途取得しておくほうが良いです。**/全て確認しましょう。ロードアベレージは平均値なので、CPUコア数より大きな値になっていないかを確認します。0.255●WAL更新量が多くないか4WAL出力量を確認WALの出力量が期待値(処理内容に見合った更新量)より多くないかを確認します。WALの出力量がわかります。出力量が妥当かどうかの観点も必要ですが、単純にサーバスペックに対して書き込み量が多そうかどうかの判断もできますね。file(s)5WAL書き込み待ちの確認WAL出力量が多い場合、WALの書き込み待ちになっていないかを合わせて確認します。Type」と「Event」、「Count」を確認します。Type」に「LWLock(軽量ロック)」の「WALWrite」が多い場合、WALの書き込み待ちが発生して更新性能に影響している可能性があります。0.0176WAL契機のチェックポイント回数を確認WAL出力量が多い場合、チェックポイントの発生回数も確認します。チェックポイント自体重い処理になるので、WAL契機でのチェックポイントが発生している場合は負荷が高いことがわかります。WAL」の数が多い場合、WAL契機のチェックポイントが発生し、I/O負荷が高くなっている可能性があります。ここではWAL契機のチェックポイントが2回発生していることがわかりますね。Incr」(増加サイズ)が想定より大きくなっていないかを確認します。282378自動VACUUMの効果を確認テーブルサイズが想定より大きくなっている場合、VACUUMが正常に動作しているかを確認します。Dead」(回収されなかったデッドタプル)の数が多くないかを確認します。この値が大きい場合は何らかの理由によってデッドタプルが回収されていないことが懸念されますので、調査したほうがよさそう、といった判断ができます。実行されたSQLごとに、実行回数やトータルの実行時間を確認します。1回あたりの実行時間も確認できますので、負荷の高いSQLのチェックが可能です。Time)、1回あたりの実行時間(Time/Call)を確認します。Time」で降順に出力されますので、データベースに対して負荷をかけている可能性の高いSQLの順に並んでいます。1回あたりの実行時間(Time/Call)が長い場合、適切な実行計画になっているかなど、改善を検討する対象とすることができます。$110シーケンシャルスキャンが多いテーブルを確認するシーケンシャルスキャンの多いテーブルは、インデックスを張ることで性能改善が見込めます。大きいテーブルに対してシーケンシャルスキャンが発生している場合は要注意です。Scans」の回数を確認します。該当するテーブルが「負荷の高いTOP20のSQL」でアクセスしているかどうかも突き合わせましょう。対処するべき点になるかもしれません。(7と同じ個所の別列を確認します。簡易レポートから性能問題の要因になりそうな「怪しい」箇所を探す手助けになります。本記事に記載したもの以外にも、有用な情報はたくさんありますので、徐々に慣れていくと良いですね。情報も併せて確認するとより全体が見えてくると思います。PostgreSQLの技術記事を掲載しておりますので、ぜひこちらもご覧ください。