合 GreenPlum性能优化系列

架构设计

集群规划中影响性能的因素

1、并行处理时，用户查询的处理速度取决于集群里最慢的数据库实例的完成时间。所以，当各节点服务器硬件配置不一样时，配置高的机器处理速度快，配置低的机器处理慢，此时短板就是配置较差的机器，影响整体性能。如果想再硬件上提升数据库性能，就需要均衡各个节点的服务器配置才有用。

2、实例处理数据量不均衡（表倾斜）。这可能是建表时分布键选择不正确，导致数据倾斜到某些节点，导致该实例上的节点要处理的数量高于其他节点，导致处理时间相对于其他节点变慢，最终导致max_statement_mem整个查询速度变慢。这种情况可以通过表的优化来避免。

3、镜像的分部策略也可能影响数据库性能。这种情况是在数据库中有主实例down了之后才会体现出来。在下面的架构中，每个节点有8个主实例和8个备实例，采用GROUP策略（默认），将8个备实例全部放在另一台服务器上，如果一台服务器down了，另一台服务器上的镜像就会启动工作，这样的话该节点就相当于16个数据库实例在运行。相比其他运行8个数据库实例的节点，性能下降一半。如果是采用SPREAD策略，则3个备实例是分别处于其他3台服务器上，这种策略相对于GROUP策略的性能下降没有那么严重，但是发生主备同时down的几率更大，更容易导致数据库不可用（只要有1对主备实例都down了就会不可用），相对没有那么稳定，这就需要根据实例需要选择某一个策略。

GROUP策略：

SPREAD策略：

服务器配置（硬件选型）

在硬件选型上，我们讲究达到平衡。是要在性能、容量、成本等多个方面综合考虑，取得平衡。不能一味追求容量而忽略了整体性能，忽略了日后维护和扩容的成本；也不能一味追求性能而忽略了成本，而让采购部门望而却步。

CPU主频与核数

就目前来说，一个SQL语句的执行性能，取决于单核的计算能力和有多少个Primary段参与计算。通常对于一个Primary来说，在执行一个任务时，只能利用一个CPU核的计算能力。

现在主流的两路X86服务器，CPU一般都配置64核甚至更高核数。相同核数情况下追求高主频需要很高的成本，性价比很低，基本没有什么选择的空间。所以，要提升集群的整体计算能力，核数是个非常重要的因素。如果有可能，尽量增加CPU核数，配置96核甚至128核以上的CPU，将会带来更好的计算能力。

CPU开启超线程

CPU内核只能处理一项任务，但目前CPU处理速度很快，通常使用率达不到100%。在GP数据库，可以通过开启CPU超线程，提高GP数据库的并行处理能力。

lscpu | grep core结果为2表示开启超线程。

详细请参考：https://www.xmmup.com/wulicpuluojicpucpuhexincpuxianchengdeng.html

参数调优

数据库参数

参考：https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/27985e397e5e819a.md

gp_vmem_protect_limit

Note: 仅当资源管理设置为资源队列时，gp_vmem_protect_limit服务器配置参数才会生效。

控制了每个segment实例为所有运行的查询语句可以分配的内存总量（以MB为单位）。如果查询导致超出此限制，则不会分配内存，查询将失败。

计算gp_vmem_protect_limit 的值：https://greenplum.org/calc/ “Primary Segments Per Server”为所有的实例个数，包括p和m。该参数限制每个Instance上所有语句可以使⽤的内存总量的上限值（以MB为单位）。 如果查询导致超出此限制，则不会分配内存，查询将失败，配置合理可以有效避免OOM的发生。

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/27985e397e5e819a.md#6vehwh

使用gp_vmem_protect_limit设置实例能够为在每个segment数据库中完成的所有 工作分配的最大内存。不要把这个值设置得高于系统上的物理RAM。如果gp_vmem_protect_limit太高，有可能耗尽系统上的内存并且正常的操作可能会失败，导致segment故障。如果gp_vmem_protect_limit被设置为一个安全的较低值，系统上真正的内存耗尽就能避免。查询可能会因为达到限制而失败，但是系统崩溃和 segment故障可以避免，这也是我们想要的行为。

有关计算gp_vmem_protect_limit安全值的步骤，请见 资源队列的segment内存配置。

设置活动segment实例的所有postgres进程可以使用的内存量（以MB为单位）。 如果查询导致超出此限制，则不会分配内存，查询将失败。 请注意，这是一个本地参数，必须为系统中的每个segment（primary和mirror）设置。 设置参数值时，仅指定数值。 例如，要指定4096MB，请使用值4096.不要将单位MB添加到该值。

为了防止内存过度分配，这些计算可以估计安全的gp_vmem_protect_limit值。

首先计算值gp_vmem。 这是主机上可用的Greenplum数据库内存

其中SWAP是主机交换空间，RAM是主机上的RAM，以GB为单位。

接下来，计算max_acting_primary_segments。 这是由于故障而激活mirror时主机上可以运行的primary的最大数量。 例如，如果mirror布置在4个主机块中，每个主机有8个primary，则单个segment主机故障将激活故障主机块中每个剩余主机上的两个或三个mirror。 此配置的max_acting_primary_segments值为11（8个primary加上3个失败时激活的mirror）。

这是gp_vmem_protect_limit的计算。 该值应转换为MB。

对于生成大量工作文件的情况，这是计算工作文件的gp_vmem的计算。

有关监视和管理工作文件使用情况的信息，请参阅Greenplum数据库管理员指南。

根据gp_vmem值，您可以计算vm.overcommit_ratio操作系统内核参数的值。 配置每个Greenplum数据库主机时，将设置此参数。

Note: Red Hat Enterprise Linux中内核参数vm.overcommit_ratio的默认值为50。

示例：

shared_buffers

shared_buffers设置一个segment实例用于共享内存缓冲区的内存量，至少为128KB与16KB * max_connections的较大者，6.14版本的默认为125MB。如果连接Greenplum时发生共享内存分配错误，可以尝试增加SHMMAX或SHMALL操作系统参数的值，或者降低shared_buffers或者max_connections参数的值解决此类问题。

数据距离CPU越近效率越高，而离CPU由近到远的主要设备有寄存器、CPU cache、RAM、Disk Drives等。CPU的寄存器和cache是没办法直接优化的，为了避免磁盘访问，只能尽可能将更多有用信息存放在RAM中。Greenplum数据库的RAM主要用于存放如下信息。

• 执行程序
• 程序数据和堆栈
• postgreSQL shared buffer cache
• kernel disk buffer cache

• kernel

  因此最大化地保持数据库信息在内存中而不影响其他区域才是最佳的调优方式，但这常常不是一件容易的事情。

  PostgreSQL并非直接在磁盘上进行数据修改，而是将数据读入shared buffer cache，进而PostgreSQL后台进程修改cache中的数据块，最终再写回磁盘。后台进程如果在cache中找到相关数据，则直接进行操作，如果没找到，则需要从kernel disk buffer cache 或者磁盘中读入。PostgreSQL 默认的shared buffer较小，因为内存不仅仅用于shared buffer cache。

对于shared_buffers参数，刚开始可以设置一个较小的值，比如1G，然后逐渐增加，过程中监控性能提升和swap的情况。

另外一个方法就是观察缓存命中率，如果缓存命中率较低，那么就可以逐步增加shared_buffers参数。

经验：master节点的shared_buffers参数可以稍微大一点，例如8g或更高，而对于segment节点的shared_buffers参数一般配置1g足矣，注意给OS保留足够的内存，尽量不能频繁用到swap，否则会严重影响GP的性能。

max_connections

max_connections服务器参数限制对Greenplum数据库系统的并发访问数量，6.14版本的默认值Master为250，Segment为750。这是一个本地化参数，就是说需要把Master、Standby Master以及所有Segment都修改。建议Segment的值是Master的5-10倍，不过这个规律并非总是如此，在max_connections较大时通常没有这么高的倍数，2-3倍也是允许的，但Segment上的值不能小于Master。

增加此参数值可能会导致Greenplum数据库请求更多的共享内存。

max_connections = 300 #(master、standby)
max_connections = 1500 #(segment)

增加此参数时，还必须增加max_prepared_transactions。

max_prepared_transactions

max_prepared_transactions设置同时处于准备状态的事务数，6.14版本的默认值为250。Greenplum内部使用准备事务保证跨Segment的数据完整性。该参数值必须大于等于max_connections，并且在Master和Segment上应该设置成相同的值。

这个参数只有在启动数据库时，才能被设置。它决定能够同时处于prepared状态的事务的最大数目（参考PREPARE TRANSACTION命令）。如果它的值被设为0。则将数据库将关闭prepared事务的特性。它的值通常应该和max_connections的值一样大。每个事务消耗600字节(b)共享内存。

设置可以同时处于准备状态的最大事务数。 Greenplum在内部使用准备好的事务来确保各个segment的数据完整性。 该值必须至少与master上的max_connections值一样大。 segment实例应设置为与master相同的值。

work_mem

work_mem（物理内存的2%~5%），每个segment实例用作sort、hash操作的内存大小。对于128G内存的segment实例来说，可以配置3G的work_mem。
当PostgreSQL对大表进行排序时，数据库会按照此参数指定大小进行分片排序，将中间结果存放在临时文件中，这些中间结果的临时文件最终会再次合并排序，所以增加此参数可以减少临时文件个数进而提升排序效率。当然如果设置过大，会导致swap的发生，所以设置此参数时仍需谨慎。

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。