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