云服务器内容精选

  • 资源对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信息即可看出各个算子的并行情况。 非适用场景:
  • 其他因素对SMP性能的影响 除了资源因素外,还有一些因素也会对SMP并行性能造成影响。例如分区表中分区数据不均,以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时,并行效果较差。例如某表join列上某个值的数据量远大于其他值,开启并行后,根据join列的值对该表数据做hash重分布,使得某个并行线程的数据量远多于其他线程,造成长尾问题,导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用,而在高并发场景下资源剩余较少。所以,如果在高并发场景下,开启SMP并行,会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象,无论是CPU、I/O、内存或者网络资源,都会导致整体性能的下降。因此在高并发场景下,开启SMP经常不能达到性能提升的效果,甚至可能引起性能劣化。
  • 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架构是一种利用富余资源来换取时间的方案,计划并行之后必定会引起资源消耗的增加,包括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并行性能造成影响。例如分区表中分区数据不均,以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时,并行效果较差。例如某表join列上某个值的数据量远大于其他值,开启并行后,根据join列的值对该表数据做hash重分布,使得某个并行线程的数据量远多于其他线程,造成长尾问题,导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用,而在高并发场景下资源剩余较少。所以,如果在高并发场景下,开启SMP并行,会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象,无论是CPU、I/O、内存或者网络资源,都会导致整体性能的下降。因此在高并发场景下,开启SMP经常不能达到性能提升的效果,甚至可能引起性能劣化。
  • 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信息即可看出各个算子的并行情况。 非适用场景:
  • LLVM适用场景与限制 适用场景 支持LLVM的表达式。查询语句中存在以下的表达式支持LLVM优化: Case…when… 表达式 In表达式 Bool表达式 (And/Or/Not) BooleanTest表达式 (IS_NOT_KNOWN/IS_UNKNOWN/IS_TRUE/IS_NOT_TRUE/IS_FALSE/IS_NOT_FALSE) NullTest表达式 (IS_NOT_NULL/IS_NULL) Operator表达式 Function表达式 (lpad, substring, btrim, rtrim, length) Nullif表达式 表达式计算支持的数据类型包括bool,tinyint,smallint,int,bigint,float4,float8,numeric,date,time,timetz,timestamp,timestamptz,interval,bpchar,varchar,text,oid。 仅当表达式出现在以下场景时才会考虑是否使用LLVM动态编译优化: 向量化执行引擎中Scan节点的filter; Hash Join节点中的complicate hash condition、hash join filter、hash join target; Nested Loop节点中的filter、join filter; Merge Join节点的merge join filter、merge join target; Group节点中的filter表达式。
  • LLVM使用建议 目前LLVM在数据库内核侧已默认打开,用户可结合上述的分析进行配置,总体建议如下: 设置合理的work_mem,在允许的条件下尽可能设置较大的work_mem,如果出现大量下盘,则建议关闭LLVM动态编译优化(通过设置enable_codegen=off实现)。 设置合理的codegen_cost_threshold(默认值为10000),确保小数据量场景下避免使用LLVM动态编译优化。当codegen_cost_threshold的值设定后,因使用LLVM动态编译优化引入性能劣化,则建议增加codegen_cost_threshold的取值。 对于表达式计算使用LLVM动态编译优化,如果存在大量的调用C-函数的场景,建议关闭LLVM动态编译优化。 In表达式后常量列表长度不能超过10,否则不能执行LLVM编译优化。 在资源许可的情况下,数据量越大,可获得的性能提升效果越好。
  • 其他因素对LLVM性能的影响 LLVM优化效果不仅依赖于数据库内部具体的实现,还与当前所选择的硬件环境等有关。 表达式调用C-函数个数 数据库内部针对表达式计算并未实现全codegen,即在整个表达式计算中部分表达式实现了codegen,部分直接调用原本的C代码。如果整个表达式计算中后者占据了主要部分,使用LLVM动态编译优化,可能会导致性能劣化。通过设置log_min_messages的级别为DEBUG1可以查看到哪些表达式直接调用了C代码实现。 内存资源 LLVM特性的一个重要思想是保障数据的局域特性,即数据应尽可能的存放在寄存器中。同时应减少数据加载,因此在使用LLVM优化时应设置足够大的work_mem,保证对应使用LLVM优化的执行代码整个过程在内存中实现,否则可能引起性能劣化。 优化器代价估算 LLVM特性实现了简易的代价估算模型,即依据当前参与节点运算的表大小决定当前节点是否考虑使用LLVM动态编译优化。如果优化器低估了实际参与运算的行数,则原本可获得收益的未正常获得收益。反之亦然。