400-800-0824
info@ymatrix.cn
400-800-0824
info@ymatrix.cn
400-800-0824
info@ymatrix.cn
400-800-0824
info@ymatrix.cn
400-800-0824
info@ymatrix.cn
YMatrix 文档
关于 YMatrix
标准集群部署
数据写入
数据迁移
数据查询
运维监控
参考指南
工具指南
数据类型
存储引擎
执行引擎
系统配置参数
SQL 参考
常见问题(FAQ)
本文档介绍了定位性能瓶颈的思路,以及存在于 YMatrix 数据库内部及外部的一些典型性能调优场景。
当发现某业务 SQL 变慢,或想提升某 SQL 的查询性能时,请先根据现象确认方向性的问题:
是服务器系统整体变慢:
还是只是某个 SQL 变慢:
确定有慢查询 SQL,请参考下述思路进行排查与分析:
注意!
信息收集方法多样,我们在此只详细说明其中 1-2 种。若你有更习惯使用的命令,可以另作收集与分析。
类别 | 信息 | 收集 | 分析 |
服务器资源 | CPU 使用率 | YMatrix 图形化界面 - “集群管理” - “指标视图”: ∙ 每个节点的 CPU 使用率 或使用 top 命令收集 CPU 详细信息: ∙ 用户 CPU(us) ∙ 系统 CPU(sy) ∙ 空闲 CPU(id) | ∙ 当 CPU 使用率高时,确定是用户 CPU 高,还是系统 CPU 高 ∙ 如果是用户 CPU 高,则说明某个程序的 CPU 资源占用率高,需要定位代码程序运行的效率 ∙ 如果是系统 CPU 高,则同步观察是否是其他服务器资源(磁盘 I/O,内存,网络等)不足 |
内存与虚拟内存 | YMatrix 图形化界面 - “集群管理” - “指标视图”: ∙ 每个节点的 MEM 使用率 或使用 vmstat 命令查看内存详细信息: ∙ si(每秒从交换区写到内存的大小) ∙ so(每秒写入到交换区的内存大小) | 如果 si,so 长期不为 0,则表示内存不足,使用了大量虚拟内存导致性能降低 | |
磁盘 I/O(磁盘读/写速率) | YMatrix 图形化界面 - “集群管理” - “指标视图”: ∙ 每个节点的磁盘 I/O 或使用 iostat -x 命令查看磁盘 I/O 详细信息: ∙ %util(每一秒用于 I/O 时间的百分比) ∙ %iowait(CPU 等待 I/O 完成的时间的百分比) | ∙ 影响性能的是磁盘的 I/O 速度,而非磁盘大小。如果 %util 接近 100%,则说明 I/O 请求过多,I/O 系统已经满负荷 ∙ 如果 %iowait 值过高,则表示磁盘存在 I/O 瓶颈,需考虑更换或升级磁盘阵列 |
|
网络 | YMatrix 图形化界面 - “集群管理” - “指标视图”: ∙ 每个节点的网络接收/发送速率 或使用 sar -n DEV 1 2 命令查看网络详细信息: ∙ rxkb/s(每秒接收的数据量,千字节数) ∙ txkb/s(每秒发送的数据量,千字节数) | 将 rxkB/s 与该网络总带宽进行对比,如果其接近网络总带宽,则说明存在网络瓶颈 | |
内核参数 | 如果为 Linux 系统,则在 /proc/sys 目录下查看相应内核参数文件的值,例如:cat overcommit_memory | 针对操作系统的参数优化,主要是调整服务器的内存使用策略,增加 swap 空间,分担内存压力。通过更改 Linux 系统中 /proc/sys 中内核参数对应的文件可以达到修改内核参数的目的(修改过后,保存配置文件就马上自动生效),重新启动机器后之前修改的参数值失效 |
注意!
表格中选项非全部必选。
软件环境 | 操作系统版本 | 使用 uname -a 命令查看 | 分析此瓶颈是否与操作系统版本相关 |
YMatrix 版本 | 使用 SELECT version(); 命令查看 | 分析此瓶颈是否与 YMatrix 版本相关 | |
集群信息 | 集群部署拓扑 | ∙ YMatrix 图形化界面 - “集群管理” ∙ 或使用命令 SELECT * FROM gp_segment_configuration; 查看 | 如果集群发生故障自动转移(Failover),那么单个物理节点会承接更多 Segments,可能会造成一定的性能下降 |
数据库信息 | 表结构 | ∙ YMatrix 图形化界面 - “数据表” ∙ 或使用命令 \d+ 查看 | 确认是否因分布键设置不合理,导致数据倾斜严重 |
相关日志 | YMatrix 部分日志存放的默认目录为 $HOME/gpAdminLogs 数据库相关日志在相关数据目录下 | 如果需要,分析相关日志 | |
慢查询 | YMatrix 图形化界面 - “查询监控“:查看是否存在阻塞会话 | 如果存在慢查询,则需定位并分析该慢查询 | |
查询计划 | 使用 EXPLAIN SELECT... 命令查看某查询的查询计划 | 如果查询计划代价过高,则需分析其具体路径根究原因 | |
保存现场环境 | 使用 YMatrix 提供的分析工具 minirepro |
数据库内部调优即单个查询(SQL)语句的调优。
现象:
数据表中有较大的数据变动(如数据写入、删除等),需要重新对该表执行 ANALYZE
命令,以收集当下更为准确的统计信息,避免在执行查询计划的时候因统计信息不准确而选择错误的计划,最终导致查询性能降低。
分析方法:
可以根据 EXPLAIN ANALYZE
命令的输出确定统计信息是否错误,如果查询计划中 row
值偏差太大,则说明统计信息失真,重新执行以下命令:
=# ANALYZE <tablename>;
现象:
某些业务场景在初始设计数据模型时选取的分布键不合理,使得写入的数据落在集群小部分的 Segment 实例上,造成数据倾斜。数据倾斜会显化 YMatrix 分布式架构的木桶效应:多个 Segments 实例在协作处理数据的时候,执行查询任务的时间取决于最慢的 Segment 实例的执行时间 + Master 的处理时间。
分析方法:
使用以下命令查看某数据表的数据分布情况,如果不同 Segment 的数据分布相差过大,则视为数据倾斜:
=# SELECT gp_segment_id,count(*) FROM <tablename> GROUP BY gp_segment_id;
解决思路:
如果出现数据倾斜现象,那么需要考虑修改分布键,重新均匀地分布数据。修改分布键的行为通过如下命令实现:
=# ALTER TABLE <tablename> SET DISTRIBUTED BY(<newcolumn>);
=# ALTER TABLE <tablename> SET WITH (REORGANIZE=true);
=# ANALYZE <tablename>;
注意!
在设计数据模型时,分布键的选择会影响到表的数据分布,进而影响到其查询性能。而当业务开始运行,再修改分布键就拥有了更大的性能风险。因此我们建议你在设计阶段更加谨慎地选择分布键,可以参考YMatrix DDL 最佳实践。
现象:
数据表因进行频繁的更新或删除操作,而又没有设计合理的数据清理周期,导致数据膨胀。
解决思路:
=# DROP TABLE <partition_tablename>;
=# VACUUM <tablename>;
详见日常清理。
=# ALTER TABLE <tablename> SET WITH (REORGANIZE=true);
=# ANALYZE <tablename>;
如果以上原因都不是造成该 SQL 性能瓶颈的实际原因,那么请分析其查询计划,并且提出以下问题:
enable_\<operator>
参数来看看是否能够强制优化器来为该查询选择一个不同的计划。WHERE
子句。1
并且在 SQL 语句中使用显式的 JOIN
语法来强制优化器用指定的连接顺序。还可以在相关的连接列上收集更多的统计信息。0
行,因为父表中不包含任何数据。查询计划相关信息详见理解查询计划。