statement_mem 好像是限制节点内存而不是段内存
statement_mem seems to limit the node memory instead of the segment memory
根据 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 是按网段而不是按主机定义的。 （@乔恩·罗伯茨）
在 GP 最佳实践指南第 32 页的开头，它清楚地表明如果 statement_mem 是 125MB 并且我们在服务器上有 8 个段，每个查询将在每个服务器上分配 1GB。
在 https://support.pivotal.io/hc/en-us/articles/201947018-Pivotal-Greenplum-GPDB-Memory-Configuration 上似乎使用 statement_mem 作为段内存而不是主机内存。它与资源队列的内存限制以及 gp_vmem_protect_limit（每个段基础定义的两个参数）保持相互关联 statement_mem。
这就是我对如何正确管理内存资源感到困惑的原因。
谢谢
我错误地指出 statement_mem 在每个主机上，但事实并非如此。这个 link 是在讨论段级别的内存：
http://gpdb.docs.pivotal.io/4370/guc_config-statement_mem.html#statement_mem
使用默认值 "eager_free" gp_resqueue_memory_policy，内存会被重新使用，因此对于特定查询执行而言，使用的内存总量可能看起来很低。如果将其更改为"auto"，其中内存不会被重新使用，内存使用情况会更加明显。
运行 您的查询的 "explain analyze" 并查看使用的切片。使用 eager_free，内存将被重新使用，因此您可能只有一个切片需要比可用内存更多的内存，例如这个：
(slice18) * Executor memory: 10399K bytes avg x 2 workers, 10399K bytes max (seg0). Work_mem: 8192K bytes max, 13088K bytes wanted.
对于您关于如何管理资源的问题，大多数人不会更改默认值。溢出到磁盘的查询通常表明查询需要修改或数据模型需要一些工作。
根据 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 是按网段而不是按主机定义的。 （@乔恩·罗伯茨）
在 GP 最佳实践指南第 32 页的开头，它清楚地表明如果 statement_mem 是 125MB 并且我们在服务器上有 8 个段，每个查询将在每个服务器上分配 1GB。
在 https://support.pivotal.io/hc/en-us/articles/201947018-Pivotal-Greenplum-GPDB-Memory-Configuration 上似乎使用 statement_mem 作为段内存而不是主机内存。它与资源队列的内存限制以及 gp_vmem_protect_limit（每个段基础定义的两个参数）保持相互关联 statement_mem。
这就是我对如何正确管理内存资源感到困惑的原因。
谢谢
我错误地指出 statement_mem 在每个主机上，但事实并非如此。这个 link 是在讨论段级别的内存： http://gpdb.docs.pivotal.io/4370/guc_config-statement_mem.html#statement_mem
使用默认值 "eager_free" gp_resqueue_memory_policy，内存会被重新使用，因此对于特定查询执行而言，使用的内存总量可能看起来很低。如果将其更改为"auto"，其中内存不会被重新使用，内存使用情况会更加明显。
运行 您的查询的 "explain analyze" 并查看使用的切片。使用 eager_free，内存将被重新使用，因此您可能只有一个切片需要比可用内存更多的内存，例如这个：
(slice18) * Executor memory: 10399K bytes avg x 2 workers, 10399K bytes max (seg0). Work_mem: 8192K bytes max, 13088K bytes wanted.
对于您关于如何管理资源的问题，大多数人不会更改默认值。溢出到磁盘的查询通常表明查询需要修改或数据模型需要一些工作。