【實錄】首次利用GPCC歷史數據調優Greenplum 第一部分

數據庫性能分析和優化是一個難題，筆者所在的Greenplum研發部門近期正好在解決一個實際用戶的全局性能問題，本文記錄了分析過程和解決思路。本案例是第一次對實際客戶的生產庫以GPCC歷史數據爲核心剖析性能問題，所以有必定的開創性和借鑑意義，故撰文供研發同事、現場工程師、支持工程師參考，同時也適合具有必定GP基礎並但願提升的讀者閱讀。同時爲了保護客戶的商業祕密，本文不透露任何關於該商業用戶的名稱、行業等信息，並對數據中的縮寫、表名等敏感信息都進行了脫敏處理。

客戶在2019-09-22執行了從 GP4.3 到 GP5.20 的升級，隨後在10月中旬提出升級後總體性能降低的問題 「overall performance degrade after upgrade」 。現場工程師提出了包括ANALYZE、VACUUM等合理建議，同時售後支持和研發着手分析性能問題。

該客戶升級先後都使用了GPCC，GP4.3使用了GPPerfmon+GPCC3的組合，GP5.20使用的是GPCC4.8 (截止發稿時4.9版本已經發布，請使用最新版本)，並正確開啓了歷史數據收集（參見博文如何開啓）。在支持人員的協助下，咱們得以得到升級先後的相關歷史數據。

GPCC的歷史數據主要包括系統性能信息和查詢歷史，後文會結合分析過程詳細展開。

該部分歷史數據很是龐大，僅9月22日升級後到十月中旬幾周內，GPCC 4.8就記錄了1.5億次查詢。面對overall performance這一模糊的課題，咱們要想真正幫到客戶，就須要讓這些數聽說話。

第一部分，瞭解GPDB集羣的總體性能特徵

先介紹GPCC的系統性能歷史表

這個表的定義從GPPerfmon到GPCC4.8變化不大，在GPPerfmon時表明名爲public.system_history，GPCC4之後爲gpmetrics.gpcc_system_history。

GPCC運做時會每分鐘四次（分別在00秒、15秒、30秒、45秒）對GPDB集羣的每一個主機（包括Master、Segment和Standby Master）採樣上面所列信息，做用是掌握用戶數據庫的總體負載情況，能夠幫助咱們回答諸如如下幾個問題：

• 用戶的系統負載高不高
• 什麼時間段負載最高，是否呈現按小時、天、周的規律
• CPU和DiskIO是否用滿，誰是瓶頸
• 系統負載是否隨時間推移愈來愈高（性能退化）

咱們使用下面查詢來分析一週內的系統資源變化狀況

SELECT
   ctime::date || '_' || CASE WHEN extract(hour from ctime) < 10 THEN '0' ELSE '' END || extract(hour from ctime) AS date_hour
 , avg(cpu_sys) AS cpu_sys
 , avg(cpu_user) AS cpu_user
 , avg(cpu_sys+cpu_user) AS cpu
 , avg(mem_total) AS mem_total
 , avg(mem_used) AS mem_used
 , avg(mem_actual_used) AS mem_actual
 , avg(load0) AS load0
 , avg(load1) AS load1
 , avg(load2) AS load2
 , avg(disk_rb_rate) / 1024 / 1024 AS disk_R_MBs
 , avg(disk_wb_rate) / 1024 / 1024 AS disk_W_MBs
 , avg(net_rb_rate) / 1024 / 1024 AS net_I_MBs
 , avg(net_wb_rate) / 1024 / 1024 AS net_O_MBs
FROM
   gpmetrics.gpcc_system_history
WHERE
   hostname LIKE 'sdw%'
AND ctime >= '2019-10-09 00:00:00'
AND ctime < '2019-10-16 00:00:00'
GROUP BY 1
ORDER BY 1
;

• 因爲每一個主機都會被採樣，這裏咱們更關心Segment的負載，所以在WHERE條件上過濾掉了MASTER。也能夠根據須要反過來觀察MASTER或單個主機上的性能指標。
• 這裏咱們更關心每一個小時的平均值，所以多采用avg()，實際應用中還能夠根據須要活用max(), min(), rank()等分析角度。

取得的結果咱們能夠導入到 Excel、Grafana、Tableu 等辦公軟件進行圖形化的對比。下圖是對客戶升級先後各取一週時間的樣本，重疊到一塊兒觀察變化趨勢。

剖析

• 總體來看CPU處於很是繁忙狀態、全天（周）都處在平均70%以上
• 圖中能夠看出GP4時代用戶天天有一段時間作維護（ANALYZE、VACUUM）致使系統態CPU出現峯值。GP5以後沒有天天作。與用戶自述一致。
• GP5以後總體CPU比GP4低幾個百分點，這個比較複雜，有多是GP5優化更好，也多是計算資源不能充分利用，引發查詢變慢，尚不明確。
• 內存方面，升級先後系統總內存沒變。進程佔用的內存先後無太大變化。
• 大部份內存被用做Buff+Cache，這是PostgreSQL特性，無異常。
• Load也表現出GP5略低於GP4，與CPU下降相通，尚不明確。
• 系統總體負載沒有明顯變化趨勢，因此基本排除升級後9月22日到10月中旬期間用戶人爲引入額外工做負載帶來總體性能降低的可能。（後續其餘分析佐證）

剖析

• 磁盤IO對比差別明顯，GP5的IO大幅增長。
• 網絡IO一樣提示GP5的開銷增大了。

初步診斷用戶升級GP5以後磁盤IO/網絡IO增長的確存在潛在的性能問題，咱們列舉出如下一些可能性。

1. 用戶升級後跑的查詢個數是否變多了？（見下面第二部分）
2. 表裏的數據行數是否變多了？（見下面第三部分）
3. 查詢的執行計劃是否變差了？（見下面第四部分）
4. GP5的執行器、BufferPool等內核組件是否有bug？

針對這些懷疑，咱們須要進一步查證用戶的查詢負載。

（未完待續）

得到更多關於Greenpum的技術乾貨，請訪問Greenplum中文社區網站。

---