PostgreSQL 慢查詢SQL跟蹤操作

postgresql 開啟慢sql捕獲在排查問題時是個很有效的手段。根據慢sql讓我在工作中真正解決了實際問題，很有幫助。

postgresql 日誌支援的輸出格式有 stderr（預設）、csvlog 、syslog

一般的錯誤跟蹤，只需在配置檔案【postgresql.conf】簡單設定幾個引數，當然還有錯誤級別等要設定。12

3456

78910

1112

logging_collector = on

log_destination = 'stderr'

log_directory = 'log'

log_filename = 'postgresql-%y-%m-%d_%h%m%s.log'

select

name,

setting,

vartype,

boot_val,

reset_val

from pg_settings

where name in('logging_collector','log_destination','log_directory','log_filename');

預設的跟蹤日誌記錄在 pgdate/log 中，如 /usr/local/pgsql/data/log 。

其他幾個重要引數說明：12

3log_rotation_age = 1440 #minute,多長時間建立新的檔案記錄日誌。0 表示禁擴充套件。

log_rotation_size = 10240 #kb,檔案多大後建立新的檔案記錄日誌。0 表示禁擴充套件。

log_truncate_on_rotation = on #可重用同名日誌檔案

當需要跟蹤sql語句或者慢語句，得需要設定以下引數：12

log_statement = all #需設定跟蹤所有語句，否則只能跟蹤出錯資訊

log_min_duration_statement = 5000 #milliseconds,記錄執行5秒及以上的語句

log_statement：

設定跟蹤的語句型別，有4種型別：none(預設), ddl, mod, all。跟蹤所有語句時可設定為 "all"。

log_min_duration_statement：

跟蹤慢查詢語句，單位為毫秒。如設定 5000，表示日誌將記錄執行5秒以上的sql語句。

當 log_statement=all 和 log_min_duration_statement 同時設定時，將跟蹤所有語句，忽略log_min_duration_statement 設定。所以需按情況設定其中乙個或兩個值。

載入配置12

select pg_reload_conf();

show log_min_duration_statement;

針對某個使用者或者某資料庫進行設定

1alter database test set log_min_duration_statement=5000;

捕獲正在查詢的慢sql

1select * from pg_stat_activity where state<>'idle' and now()-query_start > interval '5 s' order by query_start ;

補充：postgresql cpu占用100%效能分析及慢sql優化

檢視連線數變化

cpu利用率到達100%，首先懷疑，是不是業務高峰活躍連線陡增，而資料庫預留的資源不足造成的結果。我們需要檢視下，問題發生時，活躍的連線數是否比平時多很多。

對於rds for pg，資料庫上的連線數變化，可以從控制台的監控資訊中看到。而當前活躍的連線數》可以直接連線資料庫，使用下列查詢語句得到：

1select count( * ) from pg_stat_activity where state not like '%idle';

追蹤慢sql

如果活躍連線數的變化處於正常範圍，則很大概率可能是當時有效能很差的sql被大量執行導致。由於rds有慢sql日誌，我們可以通過這個日誌，定位到當時比較耗時的sql來進一步做分析。但通常問題發生時，整個系統都處於停滯狀態，所有sql都慢下來，當時記錄的》慢sql可能非常多，並不容易排查罪魁禍首。這裡我們介紹幾種在問題發生時，即介入追查慢sql的方法。

1、第一種方法是使用pg_stat_statements外掛程式定位慢sql，步驟如下。

1.1 如果沒有建立這個外掛程式，需要手動建立。我們要利用外掛程式和資料庫系統裡面的計數資訊（如sql執行時間累積等），而這些資訊是不斷累積的，包含了歷史資訊。為了更方便的排查當前的cpu滿問題，我們要先重置計數器。12

3create extension pg_stat_statements;

select pg_stat_reset();

select pg_stat_statements_reset();

1.2 等待一段時間（例如1分鐘），使計數器積累足夠的資訊。

1.3 查詢最耗時的sql（一般就是導致問題的直接原因）。

1select * from pg_stat_statements order by total_time desc limit 5;

1.4 查詢讀取buffer次數最多的sql，這些sql可能由於所查詢的資料沒有索引，而導致了過多的buffer讀，也同時大量消耗了cpu。

1select * from pg_stat_statements order by shared_blks_hit+shared_blks_read desc limit 5;

2、第二種方法是，直接通過pg_stat_activity檢視，利用下面的查詢，檢視當前長時間執行，一直不結束的sql。這些sql對應造成cpu滿，也有直接嫌疑。

3.1 通過下面的查詢，查出使用表掃瞄最多的表：

1select * from pg_stat_user_tables where n_live_tup > 100000 and seq_scan > 0 order by seq_tup_read desc limit 10;

3.2 查詢當前正在執行的訪問到上述表的慢查詢：

1select * from pg_stat_activity where query ilike '%%' and query_start - now() > interval '10 seconds';

3.3 也可以通過pg_stat_statements外掛程式定位涉及到這些表的查詢：

1select * from pg_stat_statements where query ilike '%%'order by shared_blks_hit+shared_blks_read desc limit 3;

處理慢sql

對於上面的方法查出來的慢sql，首先需要做的可能是cancel或kill掉他們，使業務先恢復：12

select pg_cancel_backend(pid) from pg_stat_activity where query like '%%' and pid != pg_backend_pid();

select pg_terminate_backend(pid) from pg_stat_activity where query like '%%' and pid != pg_backend_pid();

PostgreSQL 慢查詢SQL跟蹤操作

PostgreSQL 慢查詢SQL語句跟蹤

PostgreSQL 慢查詢SQL 追蹤配置

定時傳送MySQL的TOP 10慢查詢SQL

PostgreSQL 慢查詢SQL跟蹤操作

PostgreSQL 慢查詢SQL語句跟蹤

PostgreSQL 慢查詢SQL 追蹤配置

定時傳送MySQL的TOP 10慢查詢SQL

相關推薦