Clever Geek Handbook

Postgres auto_explain：クエリプランの自動ログ

クエリ実行計画を記録するためにPGを構成する方法と、ゆっくり実行されたすべてのログを確認しない方法を簡単に説明します



私は地元の手押し車にpostgresがないので、最初にインストールします
Ubuntu 18 



> sudo apt install postgresql-10 Success. You can now start the database server using: /usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start Ver Cluster Port Status Owner Data directory Log file 10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log update-alternatives: using /usr/share/postgresql/10/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode Processing triggers for ureadahead (0.100.0-20) ... Processing triggers for systemd (237-3ubuntu10) ... > sudo -u postgres psql postgres psql (10.3 (Ubuntu 10.3-1)) Type "help" for help. postgres=# \password postgres Enter new password: 1 Enter it again: 1 postgres=# create DATABASE test; > sudo -u postgres psql test test=# show config_file; config_file ----------------------------------------- /etc/postgresql/10/main/postgresql.conf (1 row)




auto_explain



実行計画を自動的に記録するためのauto_explainモジュールがあります。

auto_explainモジュールは、遅いオペレーターの実行計画を自動的に記録する機能を提供します。これにより、 EXPLAINを手動で実行する必要がなくなります。 これは、大規模なアプリケーションで最適化されていないクエリを検出する場合に特に便利です。
つまり Postgresは実行時にリクエストプランを見つけることができます



これを行うには2つの方法があります。



  1. リクエストのモジュールを有効にすることにより： 



     load 'auto_explain'; SET auto_explain.log_min_duration = 10; SET auto_explain.log_analyze = true; select count(*) from somet where number < 1000
    これは、特定の要求をプロファイルする必要がある場合に便利です。
  2. サーバー上のすべてのリクエストに対してモジュールを有効にします







    途中でログを修正します




    構成を適用することを忘れないでください 



     test=# SELECT pg_reload_conf(); pg_reload_conf ---------------- t (1 row)


まあ、すべてをテストすることができます



テストデータ生成 
 CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; create table somet( id uuid PRIMARY key, number INTEGER, text text ); insert into somet select uuid_generate_v1(), round(random() * 1000000), round(random() * 1000000)::text from generate_series(1,10000000)




そして、ログをデバッグするリクエストは次のとおりです。 

 select count(*) from somet where number < 1000


ログに移動して、計画があります：







実際には、ニュアンスのみ-リクエストが4回記録され、プランが3回記録された理由-Parallel Seq Scan、つまり、リクエストは2つのスレッドで処理され始め（Workers Planned：2）、その後、共通の結果に組み立てられました（実行計画の新しいステップ） PG10-収集）。 したがって、リクエストごとに正確に3つのプランが取得されます）



したがって、実際には、「オンザフライ」で何か悪いことがあることがわかります-数千行のSecスキャン



インデックスが役立つと確信しています： 



 create index on somet (number) where number < 1000


それだけです。autospleinモジュールはログに何も書き込みません。







pgBadger



ログを目で見るのは不便です。そのため、ログでそのようなクエリを検索するpgbadgerというユーティリティがあります。 要求をグループ化し、単純なhtmlレポートに集約します。 そして、それはあなたのログが詳述されているのと同じくらい詳細になります



pg 9.6に表示します。 10ログはそれほど実証的ではありません




インストール： 



 > sudo apt install pgbadger


ログに基づくレポート生成： 



 > pgbadger -j 4 -p '%t [%p]:[%l-1]' /var/log/postgresql/postgresql-9.6-main.log -o bad.html [========================>] Parsed 43578 bytes of 43578 (100.00%), queries: 115, events: 1 LOG: Ok, generating html report...


そして、同様の美しさが得られます：







一般的に、私はpgbadgerのすべての機能については説明しません。私自身はそれらを知らず、彼のドキュメントは非常に優れています。特に、すべてを明確に示す「 ライブレポート 」があるからです。



そして簡単に言えば、私たちのように：





More articles:


All Articles