分布与倾斜 您所在的位置:网站首页 hash分布不均匀 分布与倾斜

分布与倾斜

2023-12-06 20:30| 来源: 网络整理| 查看: 265

当不成比例的数据流向一个或几个节点并由其处理时,则要处理倾斜结果。 它往往是Greenplum数据库性能和稳定性问题的罪魁祸首。 它可能发生在诸如连接,排序,聚合和各种OLAP操作之类的操作中。 处理倾斜在执行查询中发生,并且不容易检测数据倾斜。

如果单个节点失败,即不是主机上的所有节点,则可能是处理倾斜问题。 识别处理倾斜目前是一个手动过程。 首先查看分裂文件。 如果存在倾斜,但不足以导致分裂,则不会成为性能问题。 如果确定存在倾斜,则找到导致倾斜的查询。 以下是要使用的步骤和命令。 (更改名称,例如传递给gpssh的主机文件名):

找到要监视倾斜处理的数据库的OID:SELECT oid, datname FROM pg_database; 示例输出: oid | datname -------+----------- 17088 | gpadmin 10899 | postgres 1 | template1 10898 | template0 38817 | pws 39682 | gpperfmon (6 rows) 运行gpssh命令检测集群所有节点的文件大小。 使用先前命令将替换为数据库的OID: [gpadmin@mdw kend]$ gpssh -f ~/hosts -e \ "du -b /data[1-2]/primary/gpseg*/base//pgsql_tmp/*" | \ grep -v "du -b" | sort | awk -F" " '{ arr[$1] = arr[$1] + $2 ; tot = tot + $2 }; END \ { for ( i in arr ) print "Segment node" i, arr[i], "bytes (" arr[i]/(1024**3)" GB)"; \ print "Total", tot, "bytes (" tot/(1024**3)" GB)" }' - 示例输出: Segment node[sdw1] 2443370457 bytes (2.27557 GB) Segment node[sdw2] 1766575328 bytes (1.64525 GB) Segment node[sdw3] 1761686551 bytes (1.6407 GB) Segment node[sdw4] 1780301617 bytes (1.65804 GB) Segment node[sdw5] 1742543599 bytes (1.62287 GB) Segment node[sdw6] 1830073754 bytes (1.70439 GB) Segment node[sdw7] 1767310099 bytes (1.64594 GB) Segment node[sdw8] 1765105802 bytes (1.64388 GB) Total 14856967207 bytes (13.8366 GB)

如果磁盘使用率存在显着且持续的差异,则应调查正在执行的查询是否存在可能的倾斜(上面的示例输出未显示出明显的倾斜)。 在监控系统中,总会存在一些倾斜,但通常是短暂的,持续时间很短。

如果出现显着且持续的偏斜,则下一个任务是识别违规查询。

上一步中的命令汇总了全部节点。 这次,找到实际的节点目录。 您可以从master执行此操作,也可以登录到上一步中标识的特定节点。 以下是从master运行的示例。

此示例专门查看排序文件。 并非所有分裂文件或倾斜情况都是由排序文件引起的,因此您需要自定义命令: $ gpssh -f ~/hosts -e "ls -l /data[1-2]/primary/gpseg*/base/19979/pgsql_tmp/*" | grep -i sort | awk '{sub(/base.*tmp\//, ".../", $10); print $1,$6,$10}' | sort -k2 -n 如下是该命令的输出: [sdw1] 288718848 /data1/primary/gpseg2/.../pgsql_tmp_slice0_sort_17758_0001.0[sdw1] 291176448 /data2/primary/gpseg5/.../pgsql_tmp_slice0_sort_17764_0001.0[sdw8] 924581888 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0010.9[sdw4] 980582400 /data1/primary/gpseg18/.../pgsql_tmp_slice10_sort_29425_0001.0[sdw6] 986447872 /data2/primary/gpseg35/.../pgsql_tmp_slice10_sort_29602_0001.0...[sdw5] 999620608 /data1/primary/gpseg26/.../pgsql_tmp_slice10_sort_28637_0001.0[sdw2] 999751680 /data2/primary/gpseg9/.../pgsql_tmp_slice10_sort_3969_0001.0[sdw3] 1000112128 /data1/primary/gpseg13/.../pgsql_tmp_slice10_sort_24723_0001.0[sdw5] 1000898560 /data2/primary/gpseg28/.../pgsql_tmp_slice10_sort_28641_0001.0...[sdw8] 1008009216 /data1/primary/gpseg44/.../pgsql_tmp_slice10_sort_15671_0001.0[sdw5] 1008566272 /data1/primary/gpseg24/.../pgsql_tmp_slice10_sort_28633_0001.0[sdw4] 1009451008 /data1/primary/gpseg19/.../pgsql_tmp_slice10_sort_29427_0001.0[sdw7] 1011187712 /data1/primary/gpseg37/.../pgsql_tmp_slice10_sort_18526_0001.0[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0001.0[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0002.1[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0003.2[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0004.3[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0005.4[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0006.5[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0007.6[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0008.7[sdw8] 1573741824 /data2/primary/gpseg45/.../pgsql_tmp_slice10_sort_15673_0009.8

扫描此输出显示主机sdw8上的节点gpseg45是罪魁祸首,因为其排序文件比输出中的其他文件大。

使用ssh登录到有问题的节点并切换到root。 使用lsof命令找到排序文件所属进程的PID: [root@sdw8 ~]# lsof /data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME postgres 15673 gpadmin 11u REG 8,48 1073741824 64424546751 /data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.1 PID, 15673, 也是文件名的一部分,但并不是总是这样。 使用ps命令找到PID并确认数据库和连接信息: [root@sdw8 ~]# ps -eaf | grep 15673 gpadmin 15673 27471 28 12:05 ? 00:12:59 postgres: port 40003, sbaskin bdw 172.28.12.250(21813) con699238 seg45 cmd32 slice10 MPPEXEC SELECT root 29622 29566 0 12:50 pts/16 00:00:00 grep 15673 在master上,检查上一个命令(sbaskin),连接(con699238)和命令(cmd32)中用户的pg_log日志文件。 具有这三个值的日志文件中的行应该是包含查询的行,但有时,命令编号可能略有不同。 例如,ps输出可能显示cmd32,但在日志文件中它是cmd34。 如果查询仍在运行,则用户和连接的最后一个查询是违规查询。

几乎在所有情况下处理倾斜的解决方法是重写查询。 创建临时表可以消除倾斜。 临时表可以随机分配以强制进行两阶段聚合。



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有