PostgreSQL 源碼性能診斷(perf profiling)指南

postgresql , linux , perf , 性能診斷 , stap , systemtap , strace , dtrace , dwarf , profiler , perf_events , probe , dynamic probe , tracepoint

資料庫的性能優化是一個非常經典的話題，資料庫的優化手段以及優化的角度也各不相同。

例如，可以從os核心、網絡、塊裝置、編譯器、檔案系統、sql、資料庫參數、業務邏輯、源碼等各個方面去進行優化。

但是如果在優化前了解瓶頸在什麼地方，可以向打鼹鼠一樣，先打大的，起到事半功倍的效果。

本文将針對linux平台下的postgresql服務，講解如何診斷postgresql 資料庫服務的瓶頸，了解瓶頸在哪個方面，甚至可以了解到瓶頸在哪段代碼？

有了比較詳細的性能診斷報告，可以給出比較好的指導優化建議。

要輸出完備的跟蹤資訊，如符号表，call stack traces, 彙編指令。必須在編譯postgresql時設定相應的編譯開關，例如gcc需要開啟如下

建議linux核心編譯時加上

編譯perf時需要支援libunwind, 并加上

如果是yum安裝的軟體，可以安裝對應的debuginfo包。

例子

首先，需要定一個目标，比如insert only的場景，如何找到其瓶頸。

建立測試表

建立測試腳本，不停插入

疲勞壓測開始

pgbench壓測的同時，實時觀測。

輸出

按enter鍵彈出可以配置的選項以及目前狀态。

調整壓測指令，連接配接回環位址，(前面連接配接的是unix socket)

再次觀測perf top結果, 采樣消耗排名第一的變成了這條，找到了一個瓶頸，關閉iptables，這條就消失了，tps也提升了。

指定指令進行跟蹤，或者指定pid進行跟蹤。

跟蹤批量插入一批記錄的事件調用統計

計數例子

perf stat重點看的是instructions，判斷cpu是否充分被利用，如果沒有，說明系統有其他瓶頸，例如io等待，或者其他等待。

這個是用得最多的，先采樣，後分析報告。

跑pgbench壓測，和前面的pgbench一樣，不斷并發插入。

然後開啟統計收集，收集10秒的統計資訊，預設輸出到perf.data檔案。

前面使用perf record收集了統計資訊到perf.data，接下來就對perf.data進行分析，輸出報告。

--tui模式可以檢視概覽，支援互動式指令。

展開後的例子

如果要檢視詳情，建議使用--stdio模式，看得非常清晰

perf report輸出為本文，可以較為詳細的進行代碼瓶頸的分析。

如果你覺得perf report的文本輸出不夠直覺，可以生成火焰圖，就更加直覺了。

生成火焰圖需要将perf record的原始資料弄出來，然後繪圖。

perf.data的原始資料perf script即可輸出。

生成火焰圖

<a href="https://github.com/digoal/blog/blob/master/201611/20161129_01_svg_001.svg">perf-kernel.svg</a>

svg可以使用浏覽器打開，轉換的圖檔如下

perf top|stat|record 都支援通過-e指定事件進行跟蹤。

支援的事件如下

事件支援寫通配符，多個事件使用逗号隔開。

如果perf list列出的事件不能滿足跟蹤需求，你可以自行添加任意代碼進行跟蹤。