阿里云上的 HybridDB for PostgreSQL 是基于 PostgreSQL 开发，定位于 OLAP 场景的 MPP 架构数据库集群。它不少的内部机制沿用了 PostgreSQL 的实现。其中就包括了内存管理机制 MemoryContext。

PostgreSQL 对内存的使用方式主要分两大块

1. shared_buffer 和同类 buffer。 简单的说 shared_buffer 用于存放数据页面对应数据文件中的 block，这部分内存是 PostgreSQL 中各进程共享。这部分不在本文讨论。 2. MemoryContext 以功能为单位组织起来的树形数据结构，不同的阶段使用不同的 MemoryContext。

简单的说 MemoryContext 的存在是为了更清晰的管理内存

  • 合理管理碎片小内存。频繁的向 OS 申请和释放内存效率是很差的。MemoryContext 会以 trunk 为单位向 OS 申请成块的内存，并管理起来。当程序需求小内存时从 trunk 中分配，用完后归还给对应的 MemoryContext ，并不归还给 OS。
  • 赋予内存功能和生命周期属性
    • 以功能为单位管理内存。不同功能和阶段使用对应的 MemoryContext。
    • TopTransactionContext：一个事务的生命周期，事务管理相关数据放在 TopTransactionContext，当一个事务提交时该上下文被整个释放。
    • ExprContext PostgreSQL 以行为单位处理数据，每一行数据的表达式计算都会在 ExprContext 完成，每处理完一行都会重置对应的 ExprContext。
  • 树形的 MemoryContext 结构
    • 每个数据库后端进程顶层是 TopMemoryContext
    • TopMemoryContext 下有很多子 Context
      • 缓存相关的 CacheMemoryContext；
      • 本地锁相关的 LOCALLOCK hash；
      • 当前事务相关的 TopTransactionContext
      • 注意 CacheMemoryContext 为何不属于 TopTransactionContext，那是由于 Cache 是独立于事务存在的，事务提交不影响 Cache 的存在。

你可能明白了，实现不同的模块时，对待内存的方式可能区别很大。 比如：

1. 执行器在做表达式计算时，一些诸如字符串类型数据处理的函数，大多会比较随意的使用 palloc 分配内存，但直到函数返回，却并没有释放它们。 2. 在处理缓存模块处理数据时，却倍加小心的释放内存。

1. 执行器对数据的处理是以行为单位，都在 ExprContext 中，每处理完一行，会重置 ExprContext，以此释放相关的内存。 2. 缓存的生命周期很长，不会定期重置整个 MemoryContext。哪怕少量的内存泄漏，积攒的后果都很严重。这部分的实现容易出问题，也不好排查。

虽然有很好的内存管理机制，但进程中内存间没有强隔离，也可能出现内存问题。

造成内存泄漏的原因很大可能是：

1. 在较长生存周期的 MemoryContext 中正常处理流程中没有释放内存。 2. 由于发生了异常，跳转到在异常处理阶段没有释放内存。 3. 没有使用内存管理机制，使用 OS 调用 malloc，free 处理内存（某些实现不合理的插件中可能出现）。 4. 在不正确的 MemoryContext 分配了内存，导致内存泄漏或数据丢失。 5. 写内存越界，这是最难找的问题，很容易造成数据库崩溃。

针对内存泄漏，常用两种方法排查

1. valgrind 最常见的大杀器,开发人员都懂的。这里就不详细介绍了。

2.1 这是一段脚本，我们把它保存成文本文件(pg_debug_cmd)

2.2 获得疑似内存泄漏的进程PID，定时触发执行下面的 shell

2.3 分析日志文件

日志文件以 MemoryContext 树的形式展示了一个时间点该进程的内存分配情况。根据时间的积累，可以很容易判断出哪一些 MemoryContext 可能存在异常，从而为内存泄漏指明一个方向。

最后，文章的参考资料中也提供了一种类似的方法，供各位参考。

PostgreSQL 内存管理机制的实现比较复杂，但用起来确却很简单，有一种特别的美感，推荐大家了解一下。