Question

根据GreenPlum文档，诸如statement_mem，gp_vmem_protect_limit等GUC应该在段级别工作。资源队列内存容量也应该发生同样的事情。

在我们的系统上，每个节点有8个主要段。因此，如果我将查询的statement_mem设置为2GB，我希望查询消耗（如果需要）最多2GB x 8 = 16GB的RAM。但它似乎在开始写入磁盘之前每个节点只使用2GB（即每段2GB / 8）。我尝试了不同的statement_values和同样的事情。

永远不会达到max_statement_mem或gp_vmem_protect_limit限制。节点上的RAM使用情况已经使用各种工具进行监控（从GP命令中心到顶部，免费，一直到Pivotal建议的session_level_memory_consumption视图）。

从这里编辑

添加了两个文档源，其中每个段定义了statement_mem，而不是每个主机。（@Jon Roberts）

在GP最佳实践指南中，从第32页开始，它清楚地表明，如果statement_mem为125MB且我们在服务器上有8个段，则每个查询将为每个服务器分配1GB。

在https://support.pivotal.io/hc/en-us/articles/201947018-Pivotal-Greenplum-GPDB-Memory-Configuration上，它似乎使用statement_mem作为段内存而不是主机内存。它使statement_mem与资源队列的内存限制以及gp_vmem_protect_limit（每个段定义的两个参数）保持相互关联。

这就是为什么我对如何正确管理内存资源感到困惑。

由于

Answer 1

我错误地声明statement_mem在每台主机上，但事实并非如此。此链接正在讨论段级别的内存： http://gpdb.docs.pivotal.io/4370/guc_config-statement_mem.html#statement_mem

默认为＆＃34; eager_free＆＃34; gp_resqueue_memory_policy，内存被重用，因此对于特定的查询执行，所使用的内存总量可能看起来很低。如果您将其更改为＆＃34; auto＆＃34;在没有重复使用内存的情况下，内存使用率会更加明显。

运行＆＃34;解释分析＆＃34;您的查询，并查看使用的切片。使用eager_free，内存将被重用，因此您可能只有一个片需要比可用内存更多的内存，如下所示：

(slice18) * Executor memory: 10399K bytes avg x 2 workers, 10399K bytes max (seg0).  Work_mem: 8192K bytes max, 13088K bytes wanted.

关于如何管理资源的问题，大多数人都不会更改默认值。溢出到磁盘的查询通常表示需要修改查询或数据模型需要一些工作。