云服务器内容精选

  • 其他因素对SMP性能的影响 除了资源因素外,还有一些因素也会对SMP并行性能造成影响。例如分区表中分区数据不均,以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时,并行效果较差。例如某表join列上某个值的数据量远大于其他值,开启并行后,根据join列的值对该表数据做hash重分布,使得某个并行线程的数据量远多于其他线程,造成长尾问题,导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用,而在高并发场景下资源剩余较少。所以,如果在高并发场景下,开启SMP并行,会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象,无论是CPU、I/O、内存或者网络资源,都会导致整体性能的下降。因此在高并发场景下,开启SMP经常不能达到性能提升的效果,甚至可能引起性能劣化。
  • 资源对SMP性能的影响 SMP架构是一种利用富余资源来换取时间的方案,计划并行之后必定会引起资源消耗的增加,包括CPU、内存、I/O和网络带宽等资源的消耗都会出现明显的增长,而且随着并行度的增大,资源消耗也随之增大。当上述资源成为瓶颈的情况下,SMP无法提升性能,反而可能导致集群整体性能的劣化。SMP支持自适应特性,该特性会根据当前资源和查询特征,动态选取最优的并行度。下面对各种资源对SMP性能的影响情况分别进行说明: CPU资源 在一般客户场景中,系统CPU利用率不高的情况下,利用SMP并行架构能够更充分地利用系统CPU资源,提升系统性能。但当数据库服务器的CPU核数较少,CPU利用率已经比较高的情况下,如果打开SMP并行,不仅性能提升不明显,反而可能因为多线程间的资源竞争而导致性能劣化。 内存资源 查询并行后会导致内存使用量的增长,但每个算子使用内存上限仍受到work_mem等参数的限制。假设work_mem为4GB,并行度为2,那么每个并行线程所分到的内存上限为2GB。在work_mem较小或者系统内存不充裕的情况下,使用SMP并行后,可能出现数据下盘,导致查询性能劣化的问题。 网络带宽资源 为了实现查询并行执行,会新增并行线程间的数据交换算子。对于Local类Stream算子,所需要进行数据交换的线程在同一个DN内,通过内存交换,不会增加网络负担。而非Local类算子,需要通过网络进行数据交换,因此会加重网络负担。当网络资源成为瓶颈的情况下,并行可能会导致一定程度的劣化。 I/O资源 要实现并行扫描必定会增加I/O的资源消耗,因此只有在I/O资源充足的情况下,并行扫描才能够提高扫描性能。
  • SMP相关参数配置建议 如果要打开SMP自适应功能,要设置query_dop=0,需同步调整以下相关参数值,以获取更佳的dop选择: comm_usable_memory 当系统内存较大时,max_process_memory设置较大,可适当调大该值,建议设置为max_process_memory的5%,默认值为4GB。 comm_max_stream 设置建议值为:comm_max_stream=Min(dop_limit * dop_limit * 20 * 2, max_process_memory(字节数) * 0.025 / 总DN数 / 260),且该值在comm_max_stream取值范围内。 max_connections 设置建议值为:max_connections=dop_limit * 20 * 6 + 24,且该值在max_connections取值范围内。 公式中的dop_limit为集群中每个DN对应的CPU数,计算公式为:dop_limit = 单机器的CPU逻辑核数 / 单机器的DN数。
  • SMP适用场景与限制 SMP适用场景: 支持并行的算子 计划中存在以下算子支持并行: Scan:支持行存普通表和行存分区表顺序扫描、列存普通表和列存分区表顺序扫描、HDFS内外表顺序扫描;支持GDS数据导入的外表扫描并行。以上均不支持复制表。 Join:HashJoin、NestLoop Agg:HashAgg、SortAgg、PlainAgg、WindowAgg(只支持partition by,不支持order by) Stream:Redistribute、Broadcast 其他:Result、Subqueryscan、Unique、Material、Setop、Append、VectoRow、RowToVec SMP特有算子 为了实现并行,新增了并行线程间的数据交换Stream算子供SMP特性使用。以下新增的算子可以看做Stream算子的子类: Local Gather:实现DN内部并行线程的数据汇总 Local Redistribute:在DN内部各线程之间,按照分布键进行数据重分布 Local Broadcast:将数据广播到DN内部的每个线程 Local RoundRobin:在DN内部各线程之间实现数据轮询分发 Split Redistribute:在集群跨DN的并行线程之间实现数据重分布 Split Broadcast:将数据广播到集群所有DN的并行线程 上述新增算子可以分为Local与非Local两类,Local类算子实现了DN内部并行线程间的数据交换,而非Local类算子实现了跨DN的并行线程间的数据交换。 示例说明 以TPCH Q1的并行计划为例: 在这个计划中,实现了Hdfs Scan以及HashAgg算子的并行,并且新增了Local Gather和Split Redistribute数据交换算子。 其中6号算子为Split Redistribute算子,上面标有的“dop: 4/4”表明Split Redistribute的发送端和接收端线程的并行度均为4。4号算子为Local Gather,上面标有“dop: 1/4”,该算子的发送端线程并行度为4,而接收端线程并行度为1,即下层的5号Hash Aggregate算子按照4并行度执行,而上层的1~3号算子按照串行执行,4号算子实现了DN内并行线程的数据汇总。 通过计划Stream算子上标明的dop信息即可看出各个算子的并行情况。 非适用场景:
  • SMP相关参数配置建议 如果要打开SMP自适应功能,要设置query_dop=0,需同步调整以下相关参数值,以获取更佳的dop选择: comm_usable_memory 当系统内存较大时,max_process_memory设置较大,可适当调大该值,建议设置为max_process_memory的5%,默认值为4GB。 comm_max_stream 设置建议值为:comm_max_stream=Min(dop_limit * dop_limit * 20 * 2, max_process_memory(字节数) * 0.025 / 总DN数 / 260),且该值在comm_max_stream取值范围内。 max_connections 设置建议值为:max_connections=dop_limit * 20 * 6 + 24,且该值在max_connections取值范围内。 公式中的dop_limit为集群中每个DN对应的CPU数,计算公式为:dop_limit = 单机器的CPU逻辑核数 / 单机器的DN数。
  • 其他因素对SMP性能的影响 除了资源因素外,还有一些因素也会对SMP并行性能造成影响。例如分区表中分区数据不均,以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时,并行效果较差。例如某表join列上某个值的数据量远大于其他值,开启并行后,根据join列的值对该表数据做hash重分布,使得某个并行线程的数据量远多于其他线程,造成长尾问题,导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用,而在高并发场景下资源剩余较少。所以,如果在高并发场景下,开启SMP并行,会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象,无论是CPU、I/O、内存或者网络资源,都会导致整体性能的下降。因此在高并发场景下,开启SMP经常不能达到性能提升的效果,甚至可能引起性能劣化。
  • 资源对SMP性能的影响 SMP架构是一种利用富余资源来换取时间的方案,计划并行之后必定会引起资源消耗的增加,包括CPU、内存、I/O和网络带宽等资源的消耗都会出现明显的增长,而且随着并行度的增大,资源消耗也随之增大。当上述资源成为瓶颈的情况下,SMP无法提升性能,反而可能导致集群整体性能的劣化。SMP支持自适应特性,该特性会根据当前资源和查询特征,动态选取最优的并行度。下面对各种资源对SMP性能的影响情况分别进行说明: CPU资源 在一般客户场景中,系统CPU利用率不高的情况下,利用SMP并行架构能够更充分地利用系统CPU资源,提升系统性能。但当数据库服务器的CPU核数较少,CPU利用率已经比较高的情况下,如果打开SMP并行,不仅性能提升不明显,反而可能因为多线程间的资源竞争而导致性能劣化。 内存资源 查询并行后会导致内存使用量的增长,但每个算子使用内存上限仍受到work_mem等参数的限制。假设work_mem为4GB,并行度为2,那么每个并行线程所分到的内存上限为2GB。在work_mem较小或者系统内存不充裕的情况下,使用SMP并行后,可能出现数据下盘,导致查询性能劣化的问题。 网络带宽资源 为了实现查询并行执行,会新增并行线程间的数据交换算子。对于Local类Stream算子,所需要进行数据交换的线程在同一个DN内,通过内存交换,不会增加网络负担。而非Local类算子,需要通过网络进行数据交换,因此会加重网络负担。当网络资源成为瓶颈的情况下,并行可能会导致一定程度的劣化。 I/O资源 要实现并行扫描必定会增加I/O的资源消耗,因此只有在I/O资源充足的情况下,并行扫描才能够提高扫描性能。
  • SMP适用场景与限制 SMP适用场景: 支持并行的算子 计划中存在以下算子支持并行: Scan:支持行存普通表和行存分区表顺序扫描、列存普通表和列存分区表顺序扫描、HDFS内外表顺序扫描;支持GDS数据导入的外表扫描并行。以上均不支持复制表。 Join:HashJoin、NestLoop Agg:HashAgg、SortAgg、PlainAgg、WindowAgg(只支持partition by,不支持order by) Stream:Redistribute、Broadcast 其他:Result、Subqueryscan、Unique、Material、Setop、Append、VectoRow、RowToVec SMP特有算子 为了实现并行,新增了并行线程间的数据交换Stream算子供SMP特性使用。以下新增的算子可以看做Stream算子的子类: Local Gather:实现DN内部并行线程的数据汇总 Local Redistribute:在DN内部各线程之间,按照分布键进行数据重分布 Local Broadcast:将数据广播到DN内部的每个线程 Local RoundRobin:在DN内部各线程之间实现数据轮询分发 Split Redistribute:在集群跨DN的并行线程之间实现数据重分布 Split Broadcast:将数据广播到集群所有DN的并行线程 上述新增算子可以分为Local与非Local两类,Local类算子实现了DN内部并行线程间的数据交换,而非Local类算子实现了跨DN的并行线程间的数据交换。 示例说明 以TPCH Q1的并行计划为例: 在这个计划中,实现了Hdfs Scan以及HashAgg算子的并行,并且新增了Local Gather和Split Redistribute数据交换算子。 其中6号算子为Split Redistribute算子,上面标有的“dop: 4/4”表明Split Redistribute的发送端和接收端线程的并行度均为4。4号算子为Local Gather,上面标有“dop: 1/4”,该算子的发送端线程并行度为4,而接收端线程并行度为1,即下层的5号Hash Aggregate算子按照4并行度执行,而上层的1~3号算子按照串行执行,4号算子实现了DN内并行线程的数据汇总。 通过计划Stream算子上标明的dop信息即可看出各个算子的并行情况。 非适用场景:
  • 数据库通信相关参数 数据库集群默认使用TCP代理通信库进行节点间通信。 表2 数据库通信相关参数 GUC参数 描述 建议 comm_quota_size 参数comm_quota_size控制每个流通道每次数据传输的大小,默认数值1M。 大并发场景下,提升该数值时,可提升通信性能,但消耗更多的内存,需要根据实际场景进行调优。若通过查询DN的视图pg_total_memory_detail,发现通信层使用内存已达参数comm_usable_memory的阈值时,需要减少该数值,如修改为512K。 comm_usable_memory 参数comm_usable_memory用于控制数据库传输时,整个DN上可以用于通信的内存使用量。 该参数的取值并不是用于总量控制,仅作为内存流控的手段,即默认流控数值为1M,若内存使用量超过了该参数取值的1/2时,流控数值自动调整为默认流控的一半,若仅剩20%时,则流控数值改为最小流控值8K。
  • 数据库连接相关参数 表3 数据库连接相关参数 GUC参数 描述 建议 max_connections 允许和数据库连接的最大并发连接数。此参数会影响集群的并发能力。 CN中此参数建议保持默认值。DN中此参数建议设置为CN的个数乘以CN中此参数的值。 增大这个参数可能导致 GaussDB (DWS)要求更多的System V共享内存或者信号量,可能超过操作系统缺省配置的最大值。这种情况下,请酌情对数值加以调整。 max_prepared_transactions 设置可以同时处于“预备”状态的事务的最大数目。增加此参数的值会使GaussDB(DWS)比系统默认设置需要更多的System V共享内存。 max_connections取值的设置受max_prepared_transactions的影响,在设置max_connections之前,应确保max_prepared_transactions的值大于或等于max_connections的值,这样可确保每个会话都有一个等待中的预备事务。 session_timeout 客户端连接数据库后处于空闲状态时会根据该参数的默认值自动断开连接。 0-86400,最小单位为秒(s),0表示关闭超时设置。一般不建议设置为0。
  • 数据库内存相关参数 表1 数据库内存相关参数 GUC参数 描述 建议 max_process_memory max_process_memory设置单个CN/DN可用的最大物理内存。 DN上该数值需要根据系统物理内存及单节点部署主DN个数决定的。计算公式如下:(物理内存大小 – vm.min_free_kbytes)* 0.8 / (n+主DN个数)。该参数目的是尽可能保证系统的可靠性,不会因数据库内存膨胀导致节点OOM。这个公式中提到vm.min_free_kbytes,其含义是预留操作系统内存供内核使用,通常用作操作系统内核中通信收发内存分配,至少为5%内存。即, max_process_memory=物理内存*0.8/(n+主DN个数),其中,当集群规模小于256时, n=1;当集群规模大于256且小于512时, n=2;当集群规模超过512时,n=3。 CN上该数值内存可设置与DN数值一样。 RAM :集群规划时分配给集群的最大使用内存。 shared_buffers 设置DWS使用的共享内存大小。增加此参数的值会使DWS比系统默认设置需要更多的System V共享内存。 建议设置shared_buffers值为内存的40%以内。行存列存分开对待。行存设大,列存设小。列存:(单服务器内存/单服务器DN个数)*0.4*0.25。 如果设置较大的shared_buffers需要同时增加checkpoint_segments的值,因为写入大量新增、修改数据需要消耗更多的时间周期。 cstore_buffers 设置列存和OBS、HDFS外表列存格式(orc、parquet、carbondata)所使用的共享缓冲区的大小。 列存表使用cstore_buffers设置的共享缓冲区,几乎不用shared_buffers。因此在列存表为主的场景中,应减少shared_buffers,增加cstore_buffers。 OBS、HDFS外表使用cstore_buffers设置ORC、Parquet、Carbondata的元数据和数据的缓存,元数据缓存大小为cstore_buffers的1/4,最大不超过2GB,其余缓存空间为列存数据和外表列存格式数据共享使用。 work_mem 设置内部排序操作和Hash表在开始写入临时磁盘文件之前使用的内存大小。 该参数默认小规格内存为512MB, 大规格内存为2GB(max_process_memory大于等于30GB为大规格内存,否则为小规格内存)。 建议参数work_mem依据查询特点和并发来确定,一旦work_mem限定的物理内存不够,算子运算数据将写入临时表空间,带来5-10倍的性能下降,查询响应时间从秒级下降到分钟级。 对于串行无并发的复杂查询场景,平均每个查询有5-10关联操作,建议work_mem=50%内存/10。 对于串行无并发的简单查询场景,平均每个查询有2-5个关联操作,建议work_mem=50%内存/5。 对于并发场景,建议work_mem=串行下的work_mem/物理并发数。 maintenance_work_mem 设置维护性操作(比如VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等)中可使用的最大的内存。 建议设置此参数的值等于work_mem,可以改进清理和恢复数据库转储的速度。因为在一个数据库会话里,任意时刻只有一个维护性操作可以执行,并且在执行维护性操作时不会有太多的会话。 当自动清理进程运行时,autovacuum_max_workers倍数的内存将会被分配,所以此时设置maintenance_work_mem的值应该不小于work_mem。
  • 数据库并发队列相关参数 GUC参数 描述 建议 max_active_statements(全局并发队列) 控制单个CN上运行并发执行的作业数量。 采用全局并发队列机制将控制所有普通用户的执行作业,不区分复杂度,即执行语句都将作为一个执行单元,当并发执行的作业数量达到此参数阈值时,将进入队列等待。对于管理员执行的作业,不受全局并发控制的限制。 需根据系统资源(如CPU资源、IO资源和内存资源)情况,调整此数值大小,使得系统支持最大限度的并发作业,且防止并发执行作业过多,引起系统崩溃。 parctl_min_cost(局部并发队列) 控制在一个CN上同一资源池内的并发作业数量。 局部并发控制机制根据执行作业的cost,控制复杂查询的并发作业数量。