想象一下这样一个场景：你正享受着难得的周末时光，手机突然疯狂震动。生产环境报警了。你慌忙打开电脑，发现整个数据库集群像是被某种kan不见的巨兽吞噬了一样，彻底瘫痪。geng让你感到脊背发凉的是当你查kan监控时发现那个导致灾难的罪魁祸首，竟然仅仅是一个kan似人畜无害的查询。

这听起来像是恐怖故事的开头，但对于我的朋友 Henrietta Dombrovskia来说这是她Zui近真实经历的一场噩梦。她的生产环境拥有令人咋舌的 1.5TB RAM，这本该是坚不可摧的堡垒。然而就在业务高峰期，OOM Killer无情地出手了直接干掉了数据库进程。

Zui让人费解的是Postgres 的配置文件里那个控制内存使用的参数 work_mem，明明被小心翼翼地设置为了 4MB。4MB 乘以几个连接，撑死也就几百兆，怎么可Neng会吃掉 1.5TB？这中间到底发生了什么？是 Bug，还是我们误解了什么？

一个被遗忘的“透视镜”函数

在深入剖析这个“惨案”的根源之前，我想先和大家分享一个让我有点“无地自容”的小插曲。作为一个和 PostgreSQL 打交道超过二十年的老兵，我自认为对这个数据库的里里外外dou了如指掌。但这次和 Hetty 的对话，狠狠地给我上了一课——在这个领域里永远有新东西等着你去发现。

Hetty 在排查问题时用到了一个我之前闻所未闻的函数：pg_log_backend_memory_contexts。

说实话，不知道这个函数让我感到挺尴尬的。但转念一想，这也正是我深爱 Postgres 的原因：哪怕你用了它几十年，每周依然Neng学到新东西。这个函数就像是给数据库后端进程Zuo了一次全身 CT，它Neng让你kan到内存到底去哪儿了。

它的用法非常简单，你只需要传入一个进程 ID：

select pg_log_backend_memory_contexts;

执行之后Postgres 就会把该后端进程完整的内存上下文树一股脑地倒腾到日志里。每一个分配、每一个上下文、包括大小和块数量，dou无所遁形。正是靠着这个“透视镜”，我们才得以窥见那 1.5TB 内存消失的真相。

内存上下文的“囤积癖”

要理解为什么 4MB 的配置Neng引发 TB 级别的灾难，我们必须先搞懂 PostgreSQL 是如何管理内存的。这和我们习惯的 C 语言中直接使用 malloc 和 free 不太一样。

Postgres 采用了一种叫Zuo“内存上下文”的机制。你Ke以把它想象成一个个带有标签的收纳箱。当你需要内存时你不是向操作系统直接申请，而是向特定的“收纳箱”要。这个机制Zui大的优势在于，当你不再需要这些数据时你不需要费力地把箱子里的每一件小东西dou单独扔掉，你只需要把整个箱子销毁，里面的所有东西就瞬间释放了。

这听起来非常高效，对吧？确实如此。但这也埋下了一个隐患：Postgres 非常喜欢“囤积”。

在日志输出中，我们kan到了两个关键的角色：ExecutorState 和 HashTableContext。

ExecutorState 是查询开始时创建的顶级内存上下文。你Ke以把它kan作是这次查询的“总指挥部”。执行器需要的所有东西——中间结果、状态信息、子上下文——统统dou扔进这个大箱子里。Zui关键的一点是：这个箱子只有在查询完全结束时才会被销毁。在查询执行的过程中，它是只进不出的。

而 HashTableContext 则是 ExecutorState 的子级。它专门用来存放哈希表的数据，比如桶、条目等等。在一个哈希连接的整个生命周期中，它dou一直活着，直到Zui后一次性被父级回收。

work_mem 的数学陷阱

现在我们再来聊聊 work_mem。hen多 DBA 甚至开发者dou有一个误区，认为 work_mem 是“每个查询Neng用的Zui大内存”。错！大错特错！

官方文档写得hen清楚：work_mem 指的是的是单个内部排序操作或者哈希表操作在写入临时磁盘文件之前被允许使用的内存量。

请注意这里的措辞：“单个操作”。

一个复杂的 SQL 查询，可Neng包含多个排序步骤，也可Neng同时进行多个哈希连接。Ru果这个查询还使用了并行查询，那么每一个并行 Worker 进程dou会拥有自己独立的一套操作。

让我们来Zuo一道算术题。假设你的 work_mem 是 4MB。你的查询有 10 个哈希操作，并且开启了 4 个并行 Worker。那么理论上，峰值内存使用量可Neng是：4MB * 10 * 4 = 160MB。这虽然不小，但对于现代服务器来说完全在可接受范围内。

但是这依然解释不了 1.5TB 是怎么来的。即使有惊人的并行数量和操作数量，数学上也不应该得出这个结果。除非……还有别的因素在起作用。

真相：累积效应与延迟释放

回到 Hetty 的日志。我们kan到了成千上万个内存块。每一个块dou使用了接近 work_mem 大小的内存。问题的核心在于：它们dou生活在同一个 ExecutorState 上下文中。

Postgres 的设计哲学是：为了性Neng，内存分配要快，释放也要快。所以它不会在操作结束时就立即把内存还给操作系统或者清空上下文，而是等到整个查询结束时再统一清理。

这就导致了一个可怕的累积效应。Ru果查询的逻辑写得极其糟糕，导致它不断地申请新的内存块来Zuo各种哈希和排序，而这些旧的内存块又因为处于同一个上下文而无法被提前释放，那么内存就会像滚雪球一样越滚越大。

在 Hetty 的案例中，那个查询从未有机会“完成”。它不断地申请内存，直到把 1.5TB 的 RAM 塞满。Zui后Linux 的 OOM Killer kan不下去了直接送了它一颗子弹。

这并不是 Bug，这是 Postgres 的设计如此。它假设你会写出合理的查询，而不是写出一个试图吞噬宇宙的怪物。

那个“面向对象”的致命错误

那么到底是什么样的查询Neng造成这种破坏？Hetty 把那个 SQL 拿出来给我们kan时我们dou惊呆了。

那是一个 SELECT 语句。表面上kan起来平平无奇，但它调用了一个用 plpgsql 编写的函数。这个函数内部执行了一个 copy 操作，然后把结果返回给外层的查询，外层查询再拿着这个结果去和另一个表Zuo连接。

从语法上讲，这完全是合法的 Postgres 代码。但从逻辑上讲，这是一个典型的“重构陷阱”。

开发者们，尤其是习惯了面向对象编程的开发者，非常喜欢把逻辑封装在函数里。他们觉得这样hen干净，hen复用。于是他们在 SQL 连接中把那个函数当作另一个表来使用。这kan起来hen自然就像在代码里调用一个对象的方法一样。

但是数据库的优化器并不是那么智Neng的。当它kan到那个函数时它可Neng无法准确地预估这个函数会吐出多少数据，也不知道这个函数内部会消耗多少资源。结果就是优化器制定了一个极其糟糕的执行计划，导致了那个灾难性的内存累积。

正如 Hetty 所说：“NengZuo某事，并不意味着你应该Zuo。”

我们该如何自救？

面对这种问题，我们NengZuo些什么？hen遗憾，Postgres 并没有一个神奇的开关，Neng让你给每个后端进程设置一个硬性的内存上限。它需要多少，就会拿多少，直到操作系统或者 OOM Killer 喊停。

但是我们依然有一些防御手段：

1. 深入理解 work_mem

必须纠正对 work_mem 的认知。它不是全局上限，它是单操作上限。在调整这个参数时你必须考虑到Zui复杂的查询可Neng包含多少个并发操作，以及你有多少个并发连接。盲目调大 work_mem 可Neng会加速死亡，而不是拯救系统。

2. 警惕“函数式”写法

审查你的 SQL 代码。Ru果你在 FROM 子句中调用了复杂的自定义函数，尤其是那些涉及大量数据处理的函数，请三思。尝试把这些逻辑重写为直接的 SQL 连接或者子查询。让优化器kan到真实的表和关系，而不是被函数封装的黑盒。

3. 善用诊断工具

当你遇到内存飙升却找不到原因时别忘了 pg_log_backend_memory_contexts。它Neng帮你打开黑盒，kan到内存到底被哪些上下文占用了。这比瞎猜要有效得多。

4. 重写查询

这听起来像是废话，但往往是Zui有效的解药。Hetty 的案例中，Zui终解决方案就是重写那个查询。一旦去掉了那个封装不当的函数，内存使用量瞬间降到了正常的 MB 级别。

与数据库共舞的艺术

这次事故让我深刻地意识到，Postgres 的内存管理行为确实有时候会让人感到惊讶，甚至是惊吓。正如社区里的大佬们所说没有人敢说自己完全理解 Postgres 内存行为的方方面面。源代码里的 README 文件可Neng是Zui接近“圣经”的文档，但连那上面也说这东西hen复杂。

写那个导致崩溃函数的开发者，并没有预料到这种行为。大多数开发者dou不会。他们只是在用自己熟悉的思维方式去写数据库代码。

作为 DBA 或者资深后端工程师，我们的职责不仅仅是配置参数，geng是要理解这些参数背后的机制，以及它们与 SQL 逻辑之间微妙的相互作用。当 OOM Killer 在Zui糟糕的时刻来袭时你需要快速找到答案，而不是对着 4MB 的 work_mem 发呆。

所以下次当你kan到那个简单的 select 语句时多留个心眼。它可Neng正潜伏着，准备在你的生产环境里制造下一个 1.5TB 的惊喜。

---