如何追溯 PostgreSQL 慢查詢當時的狀态

資料庫出現慢查詢的原因很多，例如io等待，cpu繁忙，執行計劃異常，鎖等待，等等。

那麼在發生慢查詢後，如何能追溯慢查詢當時的狀态呢？

下面給大家提供一種思路，

.1. 首先，我們是如何監測慢查詢的

.2. 監測到慢查詢後，需要采集哪些資訊

.3. 資料庫核心層面能做什麼

.4. 如何分析

如何實作？

.1. 如何監測慢查詢

其中 now()-xact_start 是指事務截至目前已運作時間。

now() - query_start query截至目前已運作時間。

pid 指服務端程序id。

.2. 采集哪些資訊

如果發現運作時間超過設定門檻值，記錄該程序的以下資訊：

.2.1.

針對pid檢視它的pstack, 采集間隔自己定，比如1秒，直到對應的pid運作結束。

.2.2.

鎖等待記錄， 采集間隔自己定，比如1秒，直到對應的pid運作結束。

.2.3.

整機 io 情況, 例如 iostat -x 1 ，采集間隔自己定，比如1秒，直到對應的pid運作結束。

程序io情況, iotop -p $pid ，采集間隔自己定，比如1秒，直到對應的pid運作結束。

.2.4.

網絡情況，例如sar -n dev 1 1 ， 采集間隔自己定，比如1秒，直到對應的pid運作結束。

程序網絡情況，例如 iptraf， 根據用戶端ip和端口号， 采集間隔自己定，比如1秒，直到對應的pid運作結束。

.2.5.

cpu 使用情況

top -p $pid ， 采集間隔自己定，比如1秒，直到對應的pid運作結束。

.3.1. 對執行時間超過門檻值的sql，自動記錄sql的explain 輸出，以及每個node的耗時。

配置auto_explain來實作以上目的，配置例子：

<a href="http://blog.163.com/digoal@126/blog/static/16387704020115825612145/">http://blog.163.com/digoal@126/blog/static/16387704020115825612145/</a>

.3.2. 自動記錄sql的鎖等待耗時。

配置例子：

.3.3. 核心還可以記錄sql io的時間，需要開啟io timing trace.

.3.4. pg核心目前輸出的sql時間包含了資料傳輸到用戶端的時間，但是網絡傳輸的時間沒有單獨統計，是以這個可以通過hack核心來實作。

有了以上資訊，就可以追溯慢查詢到底慢在什麼地方了。