Greenplum 数据库最佳实践(7)

12:48/data2/primary/gpseg34/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29600_0001.0[sdw6] -rw------- 1 gpadmin gpadmin 986447872 Jul 29

12:48/data2/primary/gpseg35/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29602_0001.0[sdw6] -rw------- 1 gpadmin gpadmin 990543872 Jul 29

12:48/data1/primary/gpseg30/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29592_0001.0[sdw6] -rw------- 1 gpadmin gpadmin 992870400 Jul 29

12:48/data1/primary/gpseg32/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_29596_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 1007321088 Jul 29

12:48/data2/primary/gpseg39/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18530_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 1011187712 Jul 29

12:48/data1/primary/gpseg37/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18526_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 987332608 Jul 29

12:48/data2/primary/gpseg41/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18534_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 994344960 Jul 29

12:48/data1/primary/gpseg38/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18528_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 996114432 Jul 29

12:48/data2/primary/gpseg40/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18532_0001.0[sdw7] -rw------- 1 gpadmin gpadmin 999194624 Jul 29

12:48/data1/primary/gpseg36/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_18524_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 1002242048 Jul 29

12:48/data2/primary/gpseg46/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15675_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 1003520000 Jul 29

12:48/data1/primary/gpseg43/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15669_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 1008009216 Jul 29

12:48/data1/primary/gpseg44/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15671_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:16/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:21/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:24/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0003.2[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:26/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0004.3[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:31/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_00

06.5[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:32/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0005.4[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:34/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0007.6[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:36/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0008.7[sdw8] -rw------- 1 gpadmin gpadmin 1073741824 Jul 29

12:43/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0009.8[sdw8] -rw------- 1 gpadmin gpadmin 924581888 Jul 29

12:48/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0010.9[sdw8] -rw------- 1 gpadmin gpadmin 990085120 Jul 29

12:48/data1/primary/gpseg42/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15667_0001.0[sdw8] -rw------- 1 gpadmin gpadmin 996933632 Jul 29

12:48/data2/primary/gpseg47/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15677_0001.0

从结果可以发现主机 sdw8 上的Segment gpseg45 是罪魁祸首。

4. 使用 SSH 登录到有问题的节点，并切换为 root 用户，使用lsof 找到拥有排序临时文件的进程 PID。

[root@sdw8 ~]# lsof /data2/primary/gpseg45/base/19979/pgsql_tmp/

pgsql_tmp_slice10_sort_15673_0002.1COMMAND PID USER FD TYPE DEVICE SIZE NODE NAMEpostgres 15673 gpadmin 11u REG 8,48 1073741824

64424546751/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1

这个例子中 PID 15673 也是文件名的一部分，然而并不是所有的临时溢出文件名都包含进程PID。

5. 使用 ps 命令识别 PID 对应的数据库和连接信息。

[root@sdw8 ~]# ps -eaf | grep 15673gpadmin 15673 27471 28 12:05 ? 00:12:59 postgres: port 40003, sbaskin bdw 172.28.12.250(21813) con699238 seg45 cmd32 slice10 MPPEXEC SELECTroot 29622 29566 0 12:50 pts/16 00:00:00 grep 15673

6. 最后，我们可以找到造成倾斜的查询语句。到主节点（Master）上，根据用户名 (sbaskin)、连接信息(con699238) 和命令信息(cmd32)查找pg_log下面的日志文件。找到对应的日志行，该行应该包含出问题的查询语句。有时候cmd数字可能不一致。例如 ps 输出中 postgres 进程显示的是 cmd32，而日志中可能会是 cmd34。如果分析的是正在运行的查询语句，则该用户在对应连接上运行的最后一条语句就是出问题的查询语句。

大多数情况下解决这种问题是重写查询语句。创建临时表可以避免倾斜。设置临时表使用随机分布，这样会强制执行两阶段聚合(two-stage aggregation)。

? 分区（PARTITIONING)

好的分区策略可以让查询只扫描需要访问的分区，以降低扫描的数据量。

在每个段数据库上的每个分区都是一个物理文件。读取分区表的所有分区比读取相同数据量的非分区表需要更多时间。 以下是分区最佳实践：

? ? ? ?

只为大表设置分区，不要为小表设置分区。

仅在根据查询条件可以实现分区裁剪时对大表使用分区。 建议优先使用范围 (Range) 分区，否则使用列表 (List) 分区。

仅当SQL查询包含使用不变操作符（例如=，<, <=, >=, <>）的简单直接的约束时，查询优化器才会执行分区裁剪。

? 选择性扫描可以识别查询中的 STABLE 和 IMMUTABLE 函数，但是不能识别 VOLATILE 函数。例如查询优化器对下面的 WHERE 子句 date > CURRENT_DATE

可以启用分区裁剪，但是如果WHERE子句如下则不会启用分区裁剪。 time > TIMEOFDAY

通过检查查询的 EXPLAIN 计划验证是否执行分区裁剪非常重要。

? 不要使用默认分区。默认分区总是会被扫描，更重要的是很多情况下会导致溢出而造成性能不佳。

? ?

切勿使用相同的字段既做分区键又做分布键

避免使用多级分区。虽然支持子分区但不推荐，因为通常子分区包含数据不多甚 …… 此处隐藏：4379字，全部文档内容请下载后查看。喜欢就下载吧 ……