性能问题的常见原因
这一节解释了常见性能问题的排查以及对这些问题可能的解决方案。
Parent topic: 性能管理
识别硬件和Segment失效
Greenplum数据库的性能取决于它所运行的硬件和IT基础设施。Greenplum数据库由多台服务器(主机)构成,它们作为一个紧密的系统(阵列)一起工作。 作为诊断性能的第一步,应确保所有的Greenplum数据库的Segment都在线。Greenplum数据库的性能将和阵列中最慢的那一台主机相同。 CPU利用、内存管理、I/O处理或者网络负载方面的问题都会影响性能。常见的与硬件相关的问题有
- 磁盘失效 – 尽管在使用RAID时单一磁盘失效不会剧烈的影响数据库性能,但磁盘重新同步确实会在有失效磁盘的主机上消耗资源。 gpcheckperf 工具可以帮助发现有磁盘I/O问题的Segment主机。
- 主机失效 – 当一台主机离线时,该主机上的Segment就不可操作。这意味着阵列中的其他主机必须执行两倍于它们通常的负载,因为它们运行着主要Segment和多个镜像。 如果没有启用镜像,服务就会中断。为恢复失效的Segment也需要临时中断服务。 gpstate 工具可以帮助发现失效的Segment。
- 网络失效 – 一块网卡、一台交换机或者DNS服务器的失效都可能让Segment宕掉。 如果在Greenplum阵列中无法解析主机名或者IP地址,这就表明它们是Greenplum数据库中的Interconnect错误。 gpcheckperf可以帮助发现出现网络问题的Segment主机。
磁盘容量 – Segment主机上的磁盘容量应该永远不超过70%充满。Greenplum数据库需要一些空闲空间来做运行时处理。 要回收已删除行占用的磁盘空间,可以在装载或者更新后运行VACUUM。 gp_toolkit 管理方案中有很多视图可用来检查分布式数据库对象的尺寸。
有关检查数据库对象尺寸和磁盘空间的信息请见 Greenplum 数据库参考指南 。
管理负载
一个数据库系统的CPU容量、内存和磁盘I/O资源是有限的。当多个负载竞争访问这些资源时,数据库性能就会受到影响。 负载管理能在符合多变的业务需求的同时最大化系统吞吐。Greenplum数据库提供了资源队列和资源组来协助管理这些系统资源。
资源队列和资源组限制了特定队列或组的资源使用量和并行查询总数,管理员可以控制并行用户查询,防止系通过载。 更多有关资源队列和资源组的信息,包括如何选择合适的管理模式,请参见 管理资源.
Greenplum数据库管理员应该在业务时段之后运行维护负载,例如数据装载和 VACUUM ANALYZE操作, 不要与数据库用户竞争系统资源,在低使用率时段执行管理任务。
避免竞争
当多个用户或者负载尝试以冲突的方式使用系统时,竞争就会发生。例如,当两个事务尝试同时更新一个表时会发生竞争。 一个寻求表级或行级锁的事务将无限等待冲突的锁被释放。应用不应该保持事务打开很长时间,例如,在等待用户输入时。
维护数据库统计信息
Greenplum数据库使用一种依赖于数据库统计信息的基于代价的查询优化器。准确的统计信息让查询优化器更好地估计一个查询检索的行数, 以便选择最有效的查询计划。如果没有数据库统计信息,查询优化器就不能估计将返回多少记录。优化器并不假设它有足够多的内存来执行特定的操作, 例如聚集,因此它会采取最保守的行动并且通过读写磁盘来做这些操作。这比在内存中做要慢很多。 ANALYZE 会收集查询优化器需要的数据库相关的统计信息。
Note: 在使用GPORCA执行SQL命令时,如果通过在该命令引用的一列或者多列上收集统计信息可以改进命令的性能,Greenplum数据库会发出一个警告。 该警告在命令行上发出并且信息会被加入到Greenplum数据库的日志文件中。 有关在表列上收集统计信息的内容请见Greenplum Database 数据库参考指南中的ANALYZE命令
识别查询计划中的统计信息问题
在使用EXPLAIN 或 EXPLAIN ANALYZE解释一个查询的计划之前,先熟悉一下有助于帮助发现统计信息问题的数据。在计划中检查下列不准确统计信息的指示器:
- 优化器的估计接近于现实吗? 运行 EXPLAIN ANALYZE 并且看看优化器估计的行数是否和查询操作返回的行数接近。
- 计划中是否比较早地应用了选择性谓词? 最具选择性的过滤条件应该在计划中早早地被应用,这样会有较少的行在计划树中向上移动。
- 优化器是否选择了最好的连接顺序? 在一个查询连接多个表时,确保优化器选择最具选择性的连接顺序。消除行数最多的连接应该在计划中被最早执行,这样会有较少的行在计划树中向上移动。
更多有关阅读查询计划的信息请见查询分析
调整统计收集
下列配置参数控制统计信息收集采样的数据量:
- default_statistics_target
这些参数控制系统层面的统计信息采样。最好只对查询谓词中最频繁使用的列采样增加的统计信息。 用户可以对一个特定的列采用下面的命令调整统计信息:
ALTER TABLE…SET STATISTICS
例如:
ALTER TABLE sales ALTER COLUMN region SET STATISTICS 50;
这等效于为特定列增加default_statistics_target。后续的ANALYZE操作接着将为该列收集更多统计数据并且结果就是会产生更好的查询计划。
优化数据分布
当用户在Greenplum数据库中创建一个表时,用户必须声明一个分布键,它允许在系统中所有的Segment上均匀地分布数据。 因为Segment会以并行的方式工作在查询上,Greenplum数据库将总是和最慢的Segment速度相同。 如果数据不平衡,拥有更多数据的Segment将更慢地返回它们的结果,因此会拖慢整个系统。
优化数据库设计
很多性能问题可以通过数据库设计改进。检查用户的数据库设计并且考虑以下几点:
- 模式是否反映了数据被访问的方式?
- 较大的表是否能被分解成分区?
- 是否在使用尽可能小的数据类型来存储列值?
- 用于连接表的列是否为相同的数据类型?
- 索引有没有被使用?
Greenplum数据库最大量限制
为了帮助优化数据库设计,回顾一下Greenplum数据库支持的最大量限制:
维度 | 限制 |
---|---|
数据库尺寸 | 无限 |
表尺寸 | 无限,每个Segment的每个分区是128TB |
行大小 | 1.6 TB (1600 列 * 1 GB) |
域尺寸 | 1 GB |
每个表的行 | 281474976710656 (2^48) |
每个表/视图的列 | 1600 |
每个表的索引 | 无限 |
每个索引的列 | 32 |
每个表的表级约束 | 无限 |
表明长度 | 63 字节 (受name数据类型限制) |
这里列出的“无限”维度本质上不受Greenplum数据库的限制。 不过,它们实际受限于可用的磁盘空间和内存/交换空间。当这些值异乎寻常地大时,性能可能会受到损害。
Note:
可以同时存在的对象(表、索引 以及视图,但不包括行) 数有一个最大限制。该限制为4294967296 (2^32).