閱讀912 返回首頁    go 阿裏雲 go 技術社區[雲棲]

從redo日誌分析數據庫的profile

標簽

PostgreSQL , pg_xlogdump , 數據庫profile

背景

在PostgreSQL中查看TOP SQL是比較方便的，如下：

《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL)》

而從另一個角度，比如REDO文件，我們也能分析出每個時間段數據庫的操作類型，分析數據庫資源消耗，以及提出優化建議。

redo日誌長什麼樣

pg_xlogdump

要查看redo日誌，不得不提pg_xlogdump，原理和介紹詳見如下

《PostgreSQL xlog dump - pg_xlogdump 源碼講解》

我們簡單的看看某個REDO文件的內容：

pg_xlogdump 000000050000159E00000095 000000050000159E00000099|less  
  
rmgr: Btree       len (rec/tot):     42/    74, tx:  891772656, lsn: 159E/95000CA0, prev 159E/94FFEC78, bkp: 0000, desc: insert: rel 1663/56867/10216768; tid 19180/150  
rmgr: Btree       len (rec/tot):     34/    66, tx:  891772656, lsn: 159E/95000CF0, prev 159E/95000CA0, bkp: 0000, desc: insert: rel 1663/56867/10906168; tid 150019/337  
rmgr: Transaction len (rec/tot):     12/    44, tx:  891772656, lsn: 159E/95000D38, prev 159E/95000CF0, bkp: 0000, desc: commit: 2017-05-04 13:15:50.262106 CST  
rmgr: Heap2       len (rec/tot):     26/    58, tx:          0, lsn: 159E/95000D68, prev 159E/95000D38, bkp: 0000, desc: clean: rel 1663/56867/10216762; blk 402406 remxid 891772032  
rmgr: Heap        len (rec/tot):     25/  8065, tx:  891772657, lsn: 159E/95000DA8, prev 159E/95000D68, bkp: 1000, desc: lock 891772657: rel 1663/56867/10216770; tid 39310/2 LOCK_ONLY EXCL_LOCK   
rmgr: Heap        len (rec/tot):     36/  8116, tx:  891772657, lsn: 159E/95002D48, prev 159E/95000DA8, bkp: 0100, desc: update: rel 1663/56867/10216770; tid 39310/2 xmax 891772657 ; new tid 122748/1 xmax 0  
rmgr: Btree       len (rec/tot):     18/  5238, tx:  891772657, lsn: 159E/95004D18, prev 159E/95002D48, bkp: 1000, desc: insert: rel 1663/56867/10216776; tid 15681/11  
rmgr: Transaction len (rec/tot):     12/    44, tx:  891772657, lsn: 159E/950061A8, prev 159E/95004D18, bkp: 0000, desc: commit: 2017-05-04 13:15:50.320538 CST

rmgr是指這筆REDO RECORD的類別，後麵是長度等信息。

通過以下命令，可以統計每個資源有多少筆redo記錄，描述是什麼？

pg_xlogdump 000000050000159E00000095 000000050000159E00000099|grep -v " lock "| awk '{print $2" "$16" "$17}'|sort |uniq -c|sort -n -r  
  
 178464 Gin Insert item,  
  39060 Gin Vacuum page,  
  30980 Heap2 clean: rel  
  23855 Gin Vacuum data  
  22240 Btree insert: rel  
  18068 Heap insert: rel  
  15650 Heap2 visible: rel  
   8516 Heap delete: rel  
   4057 Transaction commit: 2017-05-04  
   3727 XLOG full-page image:  
   3331 Gin Insert new  
   3026 Heap update: rel  
   1196 Transaction abort: 2017-05-04  
   1191 Gin Update metapage,  
    765 Btree vacuum: rel  
    755 Heap hot_update: rel  
    243 Gin Delete list  
     55 Btree insert_upper: rel  
     50 Btree split_r: rel  
     32 Btree unlink_page: rel  
     32 Btree mark_page_halfdead: rel  
     29 Btree reuse_page: rel  
     28 Heap2 freeze_page: rel  
     27 Standby running xacts:  
     27 Heap insert(init): rel  
     20 Heap inplace: rel  
     11 Btree delete: index  
      9 Heap2 cleanup info:  
      5 Standby AccessExclusive locks:  
      5 Btree split_l: rel  
      4 Gin Page split,  
      2 XLOG checkpoint: redo  
      2 Gin Create posting  
      1 Heap update(init): rel

這個日誌可以看出什麼問題呢？

比如我們可以看到Gin的REDO非常多，說明用戶使用了GIN索引，同時這個索引的寫入，更新非常頻繁。

對於這種情況，用戶可以設置GIN索引的fastupdate特性，同時調大vacuum naptime，以及調大表的vacuum閾值，盡量的減少GIN的合並頻率，（但是fastupdate會降低檢索性能）。

其他，

如果你看到VACUUM非常多，說明這些REDO中包含大量的垃圾回收信息，用戶可能產生了較多垃圾，正在被回收。

如果是VACUUM FREEZE較多，說明凍結較多，用戶可以修改一下凍結周期，減少這種REDO。

參考

《PostgreSQL 使用pg_xlogdump找到誤操作事務號》

《PostgreSQL xlog dump - pg_xlogdump 源碼講解》

《PostgreSQL 如何查找TOP SQL (例如IO消耗最高的SQL)》

最後更新：2017-05-04 21:01:14

  上一篇：go 異步流複製模式如何保證不丟數據?
  下一篇：go PostgreSQL全角、半角互相轉換