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情况。