不積跬步無以至千裏，要想成為一名合格的數據庫管理員，首先應該具備紮實的基礎知識及問題處理能力。本文參考Pivotal官方FAQ，對在管理Deepgreen & Greenplum時經常會遇到的問題提出解決思路/答案，本篇主要講性能方麵的問題。希望對大家有所幫助，如果有朋友有更多的問題分享，請留言，我將一並整理。

1.我的SQL查詢昨天性能還不錯，到今天就變得非常慢了，我該怎麼辦？

• 如果你的SQL不是在數據庫Master主機上執行了，是遠程執行的，那麼可以通過在Master主機上執行SQL看返回是否正常來定位該遠程連接有沒有問題。
  
• 檢查相關係統表及用戶表是否存在過度膨脹或者數據傾斜問題。具體操作參見toolkit相關文檔。
  
• 檢查一下內部交換網絡是否仍能正常工作。
  

可以使用gpcheckperf工具或者在內部交換網絡之間執行netstat -i來查看丟包率來定位。另外也有可能某個節點的硬件出現了問題，可以通過dmesg命令或者查看/var/log/message*下的日誌來定位。

2.如何計算一個SQL運行多長時間？

• 可以在SQL運行之前使用\timing命令來開啟計時。
  
• 可以為該SQL執行explain analyze命令來查看執行時長。

3.如何追蹤Segment服務器上的子進程？

當會話在Master和Segment之間開啟時，所有子進程都會根據Master上的session_id信息進行定義（ con+sess_id）。

例如主節點session_id為76134：

gpdb=# select * from pg_Stat_activity;
 datid " datname " procpid " sess_id ".. ..
-------+---------+---------+---------+
 16986 " gpdb    "   18162 "   76134 " .. ..

所有Segment上與76134相關的子節點為：

[gpadmin@stinger2]/export/home/gpadmin/gp40>gpssh -f host_file /usr/ucb/ps -auxww "grep con76134
[stinger2] gpadmin  18162  1.7  6.0386000124480 ?        S 09:57:55  0:04 postgres: port  4000, gpadmin gpdb [local] con76134 [local] cmd3 CREATE DATABASE.......................................
[stinger2] gpadmin  18625  0.3  2.726056455932 ?        S 10:01:56  0:01 postgres: port 40000, gpadmin gpdb 10.5.202.12(18864) con76134 seg0 cmd4 MPPEXEC UTILITY...............................
[stinger2] gpadmin  18669  0.0  0.1 3624  752 pts/2    S 10:02:36  0:00 grep con76134
[stinger3] gpadmin  22289  0.8  9.4531860196404 ?        S 09:36:20  0:05 postgres: port 40000, gpadmin gpdb 10.5.202.12(18866) con76134 seg1 cmd4 MPPEXEC UTILITY...............................

4.如何檢查我的查詢是正在進行還是在等待鎖？

• 可以通過檢查pg_stat_activity視圖的waiting列狀態，或者查看pg_locks視圖的granted列來判斷。

5.當係統變慢或者掛起的時候，那種狀態的鎖是我們需要關注的？

• 我們需要關注那種鎖被喚起很長時間，許多查詢都在等待該鎖釋放的情況。

6.什麼是孤立進程？

• 孤立進程是指某個沒有子進程或者同伴進程的進程。

7.這些孤立進程會引起性能問題嗎？

• 是的，如果這些孤立進程仍然長時間占用鎖，勢必會影響性能。

關於性能相關的問題先說這麼多，由於性能問題原因千奇百怪，並且分析起來比較複雜，我會在以後單獨分享某些性能相關的文章，感謝大家~

同係列相關文章：