不积跬步无以至千里，要想成为一名合格的数据库管理员，首先应该具备扎实的基础知识及问题处理能力。本文参考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.这些孤立进程会引起性能问题吗？ 是的，如果这些孤立进程仍然长时间占用锁，势必会影响性能。 关于性能相关的问题先说这么多，由于性能问题原因千奇百怪，并且分析起来比较复杂，我会在以后单独分享某些性能相关的文章，感谢大家~ 同系列相关文章：

Deepgreen & Greenplum DBA小白普及课之一（一般问题解答）

Deepgreen & Greenplum DBA小白普及课之二（管理问题解答）

Deepgreen & Greenplum DBA小白普及课之三（备份问题解答）