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