性能问题的常见原因

    上级主题： 管理性能

    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操作。不要与数据库用户竞争系统资源，在低使用率时段执行管理任务。

    当多个用户或者负载尝试以冲突的方式使用系统时，竞争就会发生。例如，当两个事务尝试同时更新一个表时会发生竞争。一个寻求表级或行级锁的事务将无限等待冲突的锁被释放。应用不应该保持事务打开很长时间，例如，在等待用户输入时。

    维护数据库统计信息

    注意： 在使用GPORCA执行SQL命令时，如果通过在该命令引用的一列或者多列上收集统计信息可以改进命令的性能，Greenplum数据库会发出一个警告。该警告在命令行上发出并且信息会被加入到Greenplum数据库的日志文件中。有关在表列上收集统计信息的内容请见Greenplum数据库参考指南中的ANALYZE命令。

    在使用EXPLAIN或者EXPLAIN ANALYZE解释一个查询的计划之前，先熟悉一下有助于帮助发现统计信息问题的数据。在计划中检查下列不准确统计信息的指示器：

    • 优化器的估计接近于现实吗？ 运行EXPLAIN ANALYZE并且看看优化器估计的行数是否和查询操作返回的行数接近。
    • 计划中是否比较早地应用了选择性谓词？ 最具选择性的过滤条件应该在计划中早早地被应用，这样会有较少的行在计划树中向上移动。

    更多有关阅读查询计划的信息请见查询画像。

    下列配置参数控制统计信息收集采样的数据量：

    • default_statistics_target
    • gp_analyze_relative_error

    这些参数控制系统层面的统计信息采样。最好只对查询谓词中最频繁使用的列采样增加的统计信息。用户可以对一个特定的列采用下面的命令调整统计信息：

    ALTER TABLE…SET STATISTICS

    这等效于为特定列增加default_statistics_target。后续的ANALYZE操作接着将为该列收集更多统计数据并且结果就是会产生更好的查询计划。

    当用户在Greenplum数据库中创建一个表时，用户必须声明一个分布键，它允许在系统中所有的Segment上均匀地分布数据。因为Segment会以并行的方式工作在查询上，Greenplum数据库将总是和最慢的Segment速度相同。如果数据不平衡，拥有更多数据的Segment将更慢地返回它们的结果，因此会拖慢整个系统。

    优化数据库设计

    很多性能问题可以通过数据库设计改进。检查用户的数据库设计并且考虑以下几点：

    • 模式是否反映了数据被访问的方式？
    • 较大的表是否能被分解成分区？
    • 是否在使用尽可能小的数据类型来存储列值？
    • 用于连接表的列是否为相同的数据类型：？
    • 索引有没有被使用？

    为了帮助优化数据库设计，回顾一下Greenplum数据库支持的最大量限制：

    这里列出的“无限”维度本质上不受Greenplum数据库的限制。不过，它们实际受限于可用的磁盘空间和内存/交换空间。当这些值异乎寻常地大时，性能可能会受到损害。

    注意：