GreenPlum优化点之参数篇

前言：
针对GP的性能优化目前可以参考做到的有SQL/索引、查询优化以及参数调整等方向，本篇针对参数调优做出详细规划，针对不同参数类型给出参考意见，参数详解见下。

一. 连接和权限认证参数
这些参数控制客户端连接和权限认证。

连接参数
gp_vmem_idle_resource_timeout：默认18s，当连接空闲时间超过该值时，服务端回释放掉其资源，但不断开连接
max_connections：大连接数，master上250，segments上750。segment上大连接数量应该是master上的5-10倍，当增加这个参数时，也要增加max_prepared_transactions参数。增加这个参数可能到时GP需要更多的共享内存。
max_prepared_transactions：该值至少要和master的大连接数相等。设置处于准备好状态的事务数，master和segement的该配置项要相等。默认250.
权限认证参数

authentication_timeout：客户端连接超时时间，默认1分钟。修改后重启生效。防止因为客户端挂起而无限占用连接。
二. 内存消耗参数
这些参数控制系统的内存使用，可以通过调整gp_vmem_protect_limit来避免segment hosts在查询过程中内存耗尽。

gp_vmem_protect_limit：默认8192，内存资源限制。计算公式为（x单台机器物理内存)/主segment数目。x为1到1.5之间。例如物理机126G内存，主segment16个。(1126)/16=7.875GB.7.875*1024=7971MB，则该值设置为7971。 当查询需要的内存达到这个上限，内存不能够再分配，将导致查询失败。
gp_vmem_protect_segworker_cache_limit：cache限制，当查询执行器消耗的内存超过这个上限，这个过程不会缓存下来，不会为后续的查询提供缓存。默认500MB。如果系统有大量的连接或者是空闲的进程，可以减小这个上限来释放内存。
gp_workfile_limit_files_per_query：每个查询大可使用的tmp spill file数目，当超过上限时查询终止。默认100000，设置为0为不限制。（在执行查询时，当需要的内存大于给分配的内存时就会在硬盘上产生spill files）
max_prepared_transactions：该值至少要和master的大连接数相等。设置处于准备好状态的事务数，master和segement的该配置项要相等。默认250.
max_stack_depth：声明服务器的执行栈的大安全深度。该值不要超过ulimit -s得出来的值，好比ulimit -s小于1024。默认2MB。
shared_buffers:默认128MB，共享缓冲区。至少是128KB并且至少是max_connections的16K倍。
FreeSpaceMap参数

这些参数控制free space map的大小，free space map里记录失效的行数据。通过使用VACUUM回收free space map的磁盘空间。
max_fsm_pages：设置在共享的自由空间映射表里自由空间会跟踪的大数目的磁盘页面数。每个页面槽位需要消耗六个字节的共享内存，默认200000，该值必须要大于16 *max_fsm_relations.
max_fsm_relations:设置自由空间将在共享地自由空间映射里跟踪的大数目的关系（表和索引）。该值需要设置成大于所有的表数量+索引数+系统表数量，每一个大概会消耗60bytes内存。默认1000。
Cost-Based Vacuum 延迟参数

可以通过配置VACUUM和ANALYZE的执行消耗来减少在并发场景下的I/O影响。当I/O操作累加消耗达到阈值时，暂停VACUUM和ANALYZE的执行一会儿，然后累加清零，继续执行。
（Warning: GP不建议Cost-Based Vacuum 延迟，因为这个延迟在各个segment实例上是异步执行的。累加消耗和延迟在segment级别，而没有考虑到整个segment集群的运行情况。）

vacuum_cost_delay:当执行vacuum或analyze时累计的磁盘I/O消耗带到上限时，睡眠时间毫秒数。0禁止cost-based vacuum delay. 默认0.
vacuum_cost_limit：当执行vacuum累计的磁盘I/O消耗带到上限时，vacuum会睡眠。默认200.
vacuum_cost_page_dirty：修改一个数据块的代价，主要是将脏数据块写到磁盘上需要的I/O
vacuum_freeze_min_age：在表扫描的时候，它之前更旧的XID将被替换为FrozenXID. FrozenXID不遵循与普通XID比较的规则，它被认为总是比任何普通的XID旧的。
Transaction ID管理参数

xid_stop_limit：设置事务ID号，到达此ID号上限时停止创建新事务，会产生fatal error，以避免因为事务ID号循环造成的数据丢失。当达到上限值时GP无法响应，需要一些步骤恢复，详见GP Admin文档。取值范围在1千万到二十亿，默认为10亿。

xid_warn_limit：设置事务ID号，到达此ID号时发出warning提醒执行vacuum，以避免因为事务ID号循环造成的数据丢失。取值范围在1千万到二十亿，默认为5亿。
三. 查询调优参数
查询计划功能控制参数

这些参数控制查询规划器采用哪种运算。打开或关闭某种运算能够强制查询规划器选择另一个不同的查询计划。这在使用不同的查询计划测试、比较查询性能时很有用。

gp_enable_adaptive_nestloop：查询计划能使用adaptive_nestloop做join，当外层数据行数大于阈值时，查询规划器偏向于选择hash join, 而不是nestloop join
gp_enable_direct_dispatch：默认打开。是否允许将查询计划直接发送到单个segment上，当查询的数据都在同一个segment上时，直接给该segment发送查询计划相比于对所有segment都发送查询计划要快，主要是节省了响应时间，不过相应的master上会多一些cpu消耗。
gp_enable_multiphase_agg：默认打开，是否2或3阶段并行聚合，如果这个功能关闭那么gp_enable_agg_distinct和gp_enable_agg_distinct_pruning功能也将关闭
gp_enable_predicate_propagation：默认打开，当表在分布键上join时，允许查询规划器预测。join时，两表都先过滤，会更高效。
gp_enable_preunique：默认打开，当打开时，对于select distinct查询，会在数据motion前添加额外的sort distinct操作，从而减少记录的行数。额外的sort distinct操作，相比于数据通过interconnect传输要高效得多。
查询计划开销预估参数

（Warning: GP建议不要调整这些开销预估参数。这些参数用来反映GP硬件配置和典型的工作负载。这些参数是相关的，只调整期中一个可能会对性能造成不利影响。）

effective_cache_size：默认512MB，查询计划对磁盘缓存的预估值。较大的值使得查询规划器更偏向于选择index scan, 小一点的值使得查询规划器更偏向于选择sequential scan.
gp_segments_for_planner：假设segment instances所需要的开销，如果设置为0，则该值等于主segment数。这个参数影响查询规划器对motion操作收/发数据量的估计。
random_page_cost：执行计划预估随机读每页的开销，默认100，该值越高，走索引的概率越小。
数据统计采样参数（ANALYZE参数）

这些参数调整ANALYZE采样的数据量。可以对某一个表或者某一列使用ALTER TABLESET STATISTICS语句来配置统计数据集。

default_statistics_target：设置默认统计数据目标，默认值25. 数值大analyze统计需要的时间越多，但可能提高查询规划器预估的质量。
聚合函数参数

gp_workfile_compress_algorithm:默认为None，如果是sata盘，设置为zlib，可以缓解磁盘io的瓶颈。
join参数
gp_hashjoin_tuples_per_bucket：默认5，设置hash join的密度，越小的值会产生越大的hash表，会影响join的性能。
gp_statistics_use_fkeys：默认关闭，如果打开，，当主键和外键做join查询时，允许优化器使用外键信息。
其他查询计划参数

gp_enable_predicate_propagation：默认打开，当表在分布键上join时，允许查询规划器预测。join时，两表都先过滤，会更高效。
gp_max_plan_size:查询计划的大小，默认是0，不管该值大小。当指定数值时，如果查询计划超过该值，则查询直接取消并报错。
四. 系统监控参数
GCC告警（Greenplum Command Center Agent）

gp_gpperfmon_send_interval：服务器给data collection agent发送查询执行更新的时间间隔。在这个间隔内执行的查询通过UDP发送到segment上的mornitor agent。如果在耗时长的复杂查询中发现有大量UDP丢包，可以考虑将这个间隔时间调大。默认1s
自动analyze参数
当自动统计数据收集功能打开后，当同一个事务里insert, update, delete, copy 或者 create table… as select语句影响的行数达到阈值时(on_change)，或者新生成的表还没有统计数据时(on_no_stats)，analyze会自动运行。为了打开自动统计数据收集的功能，需要在master的postgresql.conf里配置，并重启。

gp_autostats_mode：默认onno stats，有none, onno stats, on_change三个配置项。当设置为none的时候，则不会自动收集，当设置为on_change的时候，则一行dml语句（create table as select ,update ,delete,insert ,copy）影响数据量超过了gp_autostats_on_change_threshold配置的时候会收集，on_no_stats，当执行完一行dml语句后，发现该表没有统计过数据，就自动统计。对于分区表来说，如果数据是插入的是父表是不会触发自动收集的，只有插入叶子表才会触发自动收集，并且只收集叶子表里的数据。
锁管理参数
deadlock_timeout:检查是否死锁之前，等待的时间，默认1s。这个时间应该要比一般的事务长，以保证在检查死锁前，正常的锁都释放了。
max_locks_per_transaction：每个事务多能占用多少个锁，默认128. 如果在一个事务中需要很多不同的表，可以考虑提高该值。
append-only 表参数
max_appendonly_tables：默认10000 ，append-optimized表能够并发读写的大数目，计算数目时分区表和子分区表视为单独的表
gp_appendonly_compaction：默认开，如果关闭，那vacuum命令只会执行清空segment下标记为EOF的文件。在I/O负载高或者磁盘空间少的情况下，可以考虑关闭。
interconnect配置参数

gp_interconnect_fc_method：UDP的流量控制方式，当gp_interconnect_fc_method是UDPIFC时有效。有两种流量控制方式，capacity和loss。capacity方式，发送方根据接受方的窗口来发送，当接收方窗口为0时暂停发送。loss方式，则是根据丢包情况来控制发送速度。默认loss.
gp_interconnect_hash_multiplier：设置UDP interconnect 用于track connection的hash表大小。取值范围在2-25，默认2，这个值将乘以segment数目来决定hash表有多少个槽。对于复杂、slice多的查询，提高这个值可以改善interconnect的性能。
gp_interconnect_queue_depth：设置接受端UDP接收窗口大小。当数据到达接收方，但是接受窗口没位置的时候，就会丢弃这个数据，需要重新传输。因此，增加该值虽然需要更多的内存，但是能够改善性能。默认为4. 设置为1-10较为合理。
gp_interconnect_setup_timeout：在此时间内interconnect setup, 否则超时。当gp_interconnect_type设置为UDP时生效。默认2小时。
gp_interconnect_snd_queue_depth：设置发送方的发送窗口大小，增加该值会占用更多内存，设置为1-4较为合理。默认为2. 该值只有当gp_interconnect_type为UDPIFC时生效。
gp_interconnect_type：设置interconnect的通信协议。有三种方式TCP/UDP/UDPIFC。对于复杂、slice多的查询，TCP多能够支持1000个segment实例。UDP能够支持更多的segment实例，且GP采用经过校验、检查的UDP，和TCP一样可靠。UDPIFC是UDP的流量控制版本，通过gp_interconnect_fc_method来选择流控方式。
dispatch配置参数

gp_cached_segworkers_threshold：默认5. gangs 是在不同segment上执行同一个slice的work processes, 当这些gangs完成任务后将会destroyed，除非有缓存。该参数值低则较节省系统资源，增加该值能够改善行上 的复杂查询。
gp_connections_per_thread：分派查询计划分片时的线程数，默认64，通常情况下该值不需要修改，除非在吞吐量上有已知的性能问题。
gp_enable_direct_dispatch：默认打开。是否允许将查询计划直接发送到单个segment上，当查询的数据都在同一个segment上时，直接给该segment发送查询计划相比于对所有segment都发送查询计划要快，主要是节省了响应时间，不过相应的master上会多一些cpu消耗。
gp_segment_connect_timeout：设置超时时间，作用于master 和segment，primary和mirror。
Fault Operation参数

gp_fts_probe_interval：默认1分钟，该值大于等于10，错误进程检测，ftsprobe会定期检测segment是否失败。（ftsprobe用来检测集群是否存在故障）
gp_fts_probe_threadcount：默认16，该值需要大于等于每个Hosts上的segment数。ftsprobe使用多少个线程。
gp_max_local_distributed_cache:默认1024，设置分布式事务缓存数，较高的值可能影响性能。
master mirroring参数
这些参数配置主备master之间的复制。主备同步的过程是：首先使用主master的事务快照部署到备master上，完成部署后，主备一致，后续更新使用walsender和walreciver进程完成主备间的同步，同步的是write-ahead log(WAL，所有的操作在提交前都要写入log文件中)。walsender时主master上的进程，walreciver是备master上的进程，两进程采用wal-based streamin同步。

keep_wal_segments：WAL segment file数目，默认5。WAL将日志记录在segment file中（这里的segment和GP中的segment不是一个概念），这些WAL segment file将在checkpoint时写到磁盘上。
repl_catchup_within_range：默认1（如果WAL segment file的编号超过了walsender正在发送的file编号，GP更新当前master，否则GP阻塞walsender发送，当所有WAL segment处理完，当前master可更新）
replication_timeout：在master和standerby传输时，walsernder进程和walreceiver进程复制的超时时间，默认60000ms
wal_receiver_status_interval：设置walreceive向master发送消息的时间间隔。在高负载的场景下，该值应该长一点。默认10s. replication_timeout 用来控制walsender进程等待walreciever消息的时间。

本文来源：https://blog.csdn.net/JxiaoZhang/article/details/127383911