Deepgreen & Greenplum DBA小白普及课之四（性能问题解答）

2017-07-02 2828

简介： 不积跬步无以至千里，要想成为一名合格的数据库管理员，首先应该具备扎实的基础知识及问题处理能力。本文参考Pivotal官方FAQ，对在管理Deepgreen & Greenplum时经常会遇到的问题提出解决思路/答案，本篇主要讲性能方面的问题。

+关注继续查看

不积跬步无以至千里，要想成为一名合格的数据库管理员，首先应该具备扎实的基础知识及问题处理能力。本文参考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.如何检查我的查询是正在进行还是在等待锁？