Greenplum针对最常见的内存错误OOM

针对最常见的内存错误OOM,需要说明(针对4.1之后版本,早起版本请前去查询相关文档):
单语句的内存消耗受3个参数控制:gp_resqueue_memory_policy、statement_mem、max_statement_mem

    A、缺省gp_resqueue_memory_policy配置为eager_free,在此情况下,内存将物尽其用(我从词面理解的,官方并未给出详细说明),但不能超过max_statement_mem的限制以及resource queue的memory_limit限制,此时如果resource queue未做限制(缺省资源队列均无内存限制),既存在OOM缺口,而此时statement_mem将不具备严格限制功能,同时max_statement_mem的缺省值为2000MB。
    B、当gp_resqueue_memory_policy配置为auto时,内存消耗将受statement_mem和resourcequeue的memory_limit限制,同样,缺省资源队列无内存限制,不过,statement_mem的缺省值为125MB。
综合考虑内存限制参数,由于资源队列的memory_limit缺省是没有限制的,我们假设有10个需要消耗1000MB的语句同时提交。
       对于A情况来说,需要向OS申请1000MB×10≈10GB的内存,这已经大于gp_vmem_protect_limit的缺省限制,此时,如果gp_vmem_protect_limit×节点节点实例数>>节点内存,则极有可能出现OOM错误,此时通过放大gp_vmem_protect_limit是可能带来缓解的,但并非良措,因为超过物理内存部分的内存申请需要SWAP来响应。而且,很容易超过物理内存+SWAP的总和,将继续出现OOM且将进入无解状态。
       对于B情况来说,需要向OS申请125MB×10≈1.25GB<<10GB的内存,通常的硬件环境,每个Instance不至于少于2GB的内存。
       如果按照gp_vmem_protect_limit缺省为8192来计算,对于A情况,每个Instance需要向系统申请8GB内存,其余的2GB需要pgsql_tmp目录来响应。而对于B情况,每个Instance需要向系统申请2GB的内存,其余的8GB需要pgsql_tmp目录来响应。由于pgsql_tmp位于性能高于SWAP的数据盘(通常的环境是如此,不排除高福帅配置),性能有一定保障,B情况通常不会出现OOM,且可承受的并发数远大于A情况。

 

你可能感兴趣的:(GreenPlum)