内存 · XB 现场笔记

PostgreSQL 使用两层数据缓存

Thu, 27 Jan 2028 00:00:00 +0000

普通缓冲式关系文件读写中，PostgreSQL 的共享缓冲位于操作系统文件缓存之上。命中共享缓冲时，不需要再次通过下面的文件读取路径；没有命中时，也可能由操作系统直接从内存提供数据。同一文件内容可以在两层各有副本，所以这里并不承诺数据库与内核共用同一份物理内存，更不能把两层缓存理解为完全没有重复占用。

坏掉的样子

执行计划里的共享读取计数，表示块被读入 PostgreSQL 缓冲池，不证明存储设备实际执行了一次物理读取。如果把每次共享读取都算成磁盘未命中，已经温热的操作系统缓存也会被误认为冰冷，从而引出错误的内存配置判断。同样，第二次查询更快，也不能独自说明究竟是哪一层缓存发生了变化，或是否只是其他执行条件改变。

缓存驻留是临时状态。其他查询可能挤走页面，工作集超过容量时，也不能指望所有页永久留在内存里；关系扫描采用的缓冲策略还可能影响复用方式。因此应使用已知大小的工作集、检查实际访问路径，并把耗时结论与真正观察到的缓存层事实分开。没有设备层测量，就不能仅凭一个计划字段宣布磁盘速度发生了变化。

快速验证

使用 PostgreSQL 18 可丢弃实例和超级用户，确保附带的缓冲观察与预热扩展可安装、且尚未安装。本轮在 PostgreSQL 18.6 单用户后端重跑 SQL，使用一百二十八兆字节共享缓冲；未测试 psql 传输与并发活动。下面的数据可以轻松放下。通过一个全新的 psql -X -v ON_ERROR_STOP=1 会话按顺序执行。关系驱逐函数用于开发测试，这里只针对隔离实验创建的对象操作：

CREATE SCHEMA cache_layer_demo;
CREATE EXTENSION pg_buffercache WITH SCHEMA cache_layer_demo;
CREATE EXTENSION pg_prewarm WITH SCHEMA cache_layer_demo;
CREATE TABLE cache_layer_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO cache_layer_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,12000) AS g;
VACUUM (ANALYZE) cache_layer_demo.items;
CREATE VIEW cache_layer_demo.residency AS
SELECT count(*) AS heap_buffers FROM cache_layer_demo.pg_buffercache
WHERE reldatabase=(SELECT oid FROM pg_database WHERE datname=current_database())
 AND relfilenode=pg_relation_filenode('cache_layer_demo.items')
 AND relforknumber=0;
SET max_parallel_workers_per_gather=0;
SELECT pg_relation_size('cache_layer_demo.items')/current_setting('block_size')::int AS heap_blocks;
SELECT heap_buffers>0 AS initially_buffered FROM cache_layer_demo.residency;

本次构建的主堆有五百四十六个块，初始缓存比较返回真。观察视图限制数据库、文件标识与主分支，并假定这个新建实验只使用默认表空间。通用监控还必须区分表空间，因为文件编号不是数据库内跨表空间唯一的物理身份。每个缓冲条目的观察是一致的，但整个视图并不是同一瞬间的原子缓存快照。接着，仅驱逐这个关系的共享缓冲：

SELECT * FROM cache_layer_demo.pg_buffercache_evict_relation('cache_layer_demo.items'::regclass);
SELECT heap_buffers=0 AS no_shared_heap_buffers FROM cache_layer_demo.residency;

函数返回驱逐、刷出和未能驱逐的数量，本次分别为五百五十、五百五十和零。总数包含辅助分支，所以比只统计主堆的块数更大。后面的比较确认主堆共享缓冲已为空，但这个结果没有回答操作系统里是否仍然缓存着同一批文件页面。两层的状态需要分别观察，不能从一层为空推断另一层也为空。

通过操作系统同步读取主堆，但不把内容加载进数据库共享缓冲：

SELECT cache_layer_demo.pg_prewarm('cache_layer_demo.items','read','main');
SELECT heap_buffers=0 AS still_no_shared_heap_buffers FROM cache_layer_demo.residency;

预热函数处理了五百四十六个块，共享缓冲数量仍是零。这里选择的是同步读取模式；若改用缓冲模式，就会把页加载到数据库缓冲池。现在执行一个需要访问全部载荷的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

顺序扫描报告五百四十六次共享读取，共享命中为零。这与操作系统缓存已经温热完全相容，不能把它翻译成五百四十六次设备读操作。再执行同样的查询：

EXPLAIN (ANALYZE,BUFFERS,COSTS OFF,TIMING OFF,SUMMARY OFF,FORMAT JSON)
SELECT sum(length(payload)) FROM cache_layer_demo.items;

第二次扫描共享读取为零，共享命中为五百四十六。两次都处理一万两千行，所以缓冲计数变化并不是因为查询少读了业务记录。最后核对驻留状态和聚合结果，再清理实验与扩展：

SELECT heap_buffers>0 AS now_shared FROM cache_layer_demo.residency;
SELECT sum(length(payload)) FROM cache_layer_demo.items;
RESET max_parallel_workers_per_gather;
DROP SCHEMA cache_layer_demo CASCADE;

载荷字符总数应为三百八十四万，共享驻留比较为真。精确块数取决于行布局和构建参数；关键观察是同步预热后共享缓冲仍为空，首次查询发生共享读取，再次查询转为命中。这些结果没有测量设备延迟，也不保证某个固定倍数的加速。用它们说明缓存层次是合适的，用来预测生产查询耗时则证据不足。

为整个服务器分配内存

资源配置文档对内存充足的专用服务器，给出了共享缓冲约占系统内存四分之一的起始建议，但这不是任何负载都最优的常数。连接本身、并发排序与哈希、维护任务，以及操作系统缓存，都在使用同一个主机预算。只增加一层的容量，可能把其他工作所需的余量挤掉，因此不能孤立地看共享命中率决定配置。

修改之前应测量有代表性的工作集与并发请求。全部缓存已经温热的微型测试会隐藏读写压力，完全冷启动测试又可能夸大平时高度复用页面的负载代价。把缓存层计数、设备层观察和查询结果结合起来，才能把配置调整的收益归到它实际改变的那一部分，而不是把所有内存读取都叫作磁盘优化。

来源

PostgreSQL 18 资源消耗，共享缓冲与操作系统缓存的内存预算，已核验 2026-10-15。
PostgreSQL 18 pg_prewarm，同步读取和数据库缓冲预热模式，已核验 2026-10-15。
PostgreSQL 18 pg_buffercache，缓冲身份及开发测试用的关系驱逐函数，已核验 2026-10-15。
PostgreSQL 文件布局，数据库、表空间与关系文件身份，已核验 2026-10-15。

Redis 的过期是截止时间，逐出是容量策略

Sun, 26 Dec 2027 00:00:00 +0000

过期与逐出都可能让一次成功查找变成未命中，但它们回答的是不同问题。过期服从键的截止时间，逐出则在内存压力下移除符合条件的键。延长 TTL 不能阻止容量驱动的逐出，扩大内存也不能纠正应用写错的截止时间。必须先确定实际发生了哪种变化，才能判断应该检查写入协议、调整容量，还是重新设计缓存用途。

时间与容量是两个独立维度

带有过期设置的键在 Redis 中称为 volatile。Redis 会在访问和主动清理过程中检查过期键，但这不承诺键一定存活到截止时间。显式删除、替换以及适用的逐出策略，都可能提前改变结果。因此，不管最初设定的期限还有多久，缓存客户端都必须能处理未命中，不能把较长 TTL 当作某条数据不会丢失的保证。

maxmemory 是 Redis 进行内存管理决策时使用的统计上限，不是操作系统 RSS 的硬上限。复制与追加日志缓冲区可能包含不计入逐出判断的内存，进程开销、分配器行为和持久化任务也需要容量余量。大型命令还可能短暂超过配置值。规划时既要考虑缓存预算，也要考虑运行整个进程的环境，不能把两者设成同一个数字就认为足够。

先确定候选范围，再讨论排序

allkeys 类策略不管键有没有 TTL，都会把它纳入候选；volatile 类策略则只考虑带过期设置的键。在各自候选范围内，LRU 偏向最久未访问的键，LFU 使用访问频率信息，random 类策略随机选择。Redis 的 LRU、LFU 是近似算法，不保证全局精确的受害键顺序。volatile-ttl 偏向剩余寿命较短的条目，也不是只清除已经到期的数据。

noeviction 在无法满足内存限制时拒绝增长内存的命令，而不是为了腾空间丢键；已有数据仍可能正常读取。但它不是持久性保证，普通过期、显式删除、进程故障和持久化配置仍然分别起作用。应检查当前实例实际配置，不能根据某种部署形式或集群名称，推断所有环境都使用相同默认策略。

volatile 策略如果找不到带 TTL 的候选键，在这种场景下就表现得像 noeviction。选了 volatile-lru，不会自动把持久键变成可丢弃数据。反过来，把会话或权威记录与可重建缓存混放在 allkeys 策略之下，它们也会成为候选。键名前缀只是命名约定，不会给逐出算法建立独立的数据保护边界。

坏掉的样子

未命中突然增加，可能来自过期、逐出、主动失效或键构造变化。需要把 expired_keys、evicted_keys 的增量，与同期请求负载和写命令结果一起看。这些是累计计数，应比较有限时间区间，并考虑重启或重置；仅看到逐出数上升，还不能知道哪个应用功能失去了哪些数据。

除了读取，也要监控被拒绝的写入。热缓存可能继续返回看似合理的值，而写入方已经不断收到内存错误。忽略这些错误，会把容量问题变成应用一致性缺陷。此时延长 TTL 可能只会让旧值保留更久，却不能恢复替换能力；重试策略也不能把内存压力进一步放大成无上限的请求风暴。

将权威状态和可丢弃缓存分开，是架构选择，不是事故中可以直接执行的数据迁移命令。改变现有实例策略之前，应确认可恢复性、持久化和数据归属。下面的实验只修改自己创建的进程，用三个独立候选策略验证行为，不切换生产实例的配置，也不操作现有键空间。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。本次在 macOS 上使用 Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0。使用 libc 编译 Redis 核心，在临时虚拟环境安装固定客户端；源码与依赖下载需要联网，不进行系统级安装，也不编译附带的可选模块。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

使用 "$redis_lab/venv/bin/python" 执行 Python 代码。每种策略都创建自己的 Unix socket、空数据集和进程，并关闭 TCP 及持久化。内存限制设置为测得的初始分配量再加两个 MiB，有限次写入使用六十四 KiB 的值，启用 TTL 的分支统一设置一小时。结束时关闭每个实验进程，仅清理自己的临时运行目录。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(policy="noeviction"):
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


for policy, expiring in [("allkeys-lru", True), ("noeviction", True),
 ("volatile-lru", False)]:
 with instance(policy) as client:
 baseline = client.info("memory")["used_memory"]
 client.config_set("maxmemory", baseline + 2 * 1024 * 1024)
 payload = "x" * 65536
 written, rejected = 0, False
 for index in range(128):
 try:
 client.set(f"item:{index}", payload, ex=3600 if expiring else None)
 except redis.exceptions.OutOfMemoryError:
 rejected = True
 break
 written += 1
 stats = client.info("stats")
 remaining = client.dbsize()
 assert stats["expired_keys"] == 0
 if policy == "allkeys-lru":
 assert written == 128 and not rejected
 assert stats["evicted_keys"] > 0 and remaining < written
 assert client.ttl("item:127") > 0
 else:
 assert rejected and 0 < written < 128
 assert stats["evicted_keys"] == 0 and remaining == written
 assert client.get("item:0") == payload
 if not expiring:
 assert client.ttl("item:0") == -1
 print(policy, {"written": written, "remaining": remaining,
 "evicted": stats["evicted_keys"],
 "expired": stats["expired_keys"], "rejected": rejected})

本次 allkeys-lru 接受一百二十八次写入，留下二十三个键，报告一百零五次逐出和零次过期；最新保留键仍有正的 TTL。这说明丢失发生在期限到来之前，原因是容量逐出，但不把这次观察夸大成对精确 LRU 受害顺序的证明，也不要求另一台机器得到相同的键数。

noeviction 接受二十三次写入后拒绝下一次分配，原有键仍能读取，逐出计数保持为零。没有任何带期限键的 volatile-lru 也出现同类拒绝。实际数量受分配开销和构建影响，因此断言检查的是关系，不是强制匹配这组数字。它不是吞吐基准，也不覆盖复制、故障切换、持久化峰值或操作系统级内存限制。

来源

Redis 键逐出，maxmemory 统计、候选策略与近似排序，已核验 2026-09-08。
Redis EXPIRE，键级截止时间及过期行为，已核验 2026-09-08。
Redis INFO，内存统计及逐出、过期计数，已核验 2026-09-08。
Redis 8.10.1 编译说明，独立核心构建与分配器选择，已核验 2026-09-08。

巨型页在分配灵活性与翻译覆盖之间取舍

Tue, 21 Dec 2027 00:00:00 +0000

巨型页可以增加每条地址翻译缓存能够覆盖的内存范围，在合适负载下减少翻译开销。但效果取决于访问模式和硬件，不能仅因为申请了很大一块内存，就断定程序频繁发生 TLB 缺失。描述工作集需要的页数减少，也不表示所有翻译能够同时装入处理器的 TLB；页数算术、硬件容量与真实性能是三个不同问题。

页大小是一项输入

x86 常见基准页为 4 KiB，但 Linux 的页大小依赖架构与配置，应读取运行系统而不是把四千多字节当作普遍常量。支持的巨型页尺寸同样会变化；2 MiB 与 1 GiB 是常见例子，不是所有处理器的完整列表。跨机器比较时，应先确认单位和实际尺寸，再比较统计数字。

对理想化的连续 8 GiB 范围，4 KiB 粒度需要 2,097,152 个页面，2 MiB 粒度只需 4,096 个。这只是映射覆盖率计算，没有测量硬件 TLB 容量、缺失率、页表遍历延迟，或同时驻留的翻译数量。不同页面大小对应的翻译缓存结构还可能具有不同容量，因此不能把两种页数之差直接称为实际节省的 TLB 项。

显式池与透明分配

Hugetlb 提供显式申请的大页，并由内核维护相应池。持久池中的页面不能同时用于普通分配，也不能在内存压力下换出。池可以在启动时准备，也能在运行中调整，还可能允许额外的 surplus 页面。启动较早时通常更容易获得连续内存，但这并不表示大页只能一次性在开机前决定数量，之后永远无法改变。

透明巨型页采用另一套机制。依内核支持和政策，较大的匿名内存分配既可能发生在缺页时，也可能由后续合并产生。THP 不只是后台线程，也不要求管理员先准备 hugetlb 池。现代内核还可以支持多种 THP 尺寸，不能把每次透明分配都等同于一个两兆字节映射，更不能用 hugetlb 总数代替 THP 使用量。

灵活性也不同。THP 可以退回较小页面，并可为回收等操作拆分。显式 hugetlb 映射不会自动变成普通页映射，但应用在自身配置允许时，可以在失败后另行选择普通页分配。应区分内核映射契约与应用的回退策略，否则会把“必须使用大页”的应用和“优先尝试大页”的应用误写成同一种启动行为。

分别预算容量与位置

在 /proc/meminfo 中，HugePages_Total 表示默认尺寸池的页数，HugePages_Free 是尚未分配的页数，HugePages_Rsvd 是已作出承诺但还没有在缺页时分配的页数。总页数乘页大小得到池容量，不是 Rsvd 所表达的已承诺容量。看起来空闲的池中可能已有一部分被预订，不能把 Free 全部当成任何新申请都能使用的余量。Hugetlb 则统计各种尺寸池占用的总内存，细节应查看分尺寸 sysfs 目录。

稀疏映射可能消耗超过有用数据的常驻内存，池也会与普通内存需求竞争。应按应用文档估算容量，核对实际映射，并给其他分配保留空间。收益需要通过代表性吞吐、延迟及翻译相关测量建立，不能因为配置的大页池足够大就宣布优化已经生效；申请、映射、使用与性能改善是不同阶段。

坏掉的样子

扩大池时，内核可能找不到足够连续的物理内存，因而失败。但已经存在的空闲巨型页本来就是连续页，Free 大于零本身并不是碎片证据。页尺寸不匹配、已有预订、权限、NUMA 位置或 cgroup 限制，也可能解释为什么某个应用用不到看似可用的容量。应按具体失败路径调查，而不是看到内存不足就统一建议重启或重复 mmap。

NUMA 政策可能使页面远离使用它们的 CPU，或者只允许从部分节点分配。应检查分节点分布和访问局部性，再判断是否为地址翻译瓶颈。TLB 改善可以与更差的内存访问延迟同时存在；全局空闲数正常、应用能够启动，都不能证明放置策略合适，也不能推导每次访问一定走本地内存。

THP 分配、合并、整理和拆分会以不同方式影响延迟。thp_collapse_alloc 是合并过程中成功分配的计数，不是停顿时间计数。应将合适的计数增量与延迟共同观察。选择 madvise、always 或当前内核支持的分尺寸政策，需要真实负载依据，不能给所有数据库套用同一个模式，再把模式名称当作性能保证。

快速验证

保存为 hugepage_check.py，运行 python3 hugepage_check.py。程序只读取计数和基准页大小，不创建大页工作负载，也不修改内核设置。缺少数据时明确打印跳过信息，并把假设值标成仅供算术演示。解析与边界断言使用合成字符串，既检查正常输入，也检查单位错误和零页大小，不会把无效数据悄悄解释为真实容量。

import os
import re
from pathlib import Path

WORKING_SET = 8 * 1024**3
FIELDS = ("HugePages_Total", "HugePages_Free", "HugePages_Rsvd",
 "HugePages_Surp", "Hugepagesize")


def parse_meminfo(text):
 values = {}
 for key in FIELDS:
 unit = r"\s+kB" if key == "Hugepagesize" else ""
 match = re.search(r"^" + key + r":\s+(\d+)" + unit + r"\s*$", text, re.M)
 if match:
 values[key] = int(match.group(1))
 return values


def pages_for(size, page):
 if size < 0 or page <= 0:
 raise ValueError("invalid byte count or page size")
 return (size + page - 1) // page


assert pages_for(4097, 4096) == 2
assert parse_meminfo("HugePages_Total: 8\nHugepagesize: 2048 kB\n")["Hugepagesize"] == 2048
assert parse_meminfo("HugePages_Total: bad\nHugepagesize: 2 MB\n") == {}
try:
 pages_for(1, 0)
except ValueError:
 pass
else:
 raise AssertionError("zero page size accepted")

try:
 values = parse_meminfo(Path("/proc/meminfo").read_text())
except OSError as error:
 values = {}
 print("SKIP live hugetlb counters:", type(error).__name__)
try:
 base = os.sysconf("SC_PAGE_SIZE")
 assert base > 0
 print("Observed base page size:", base, "bytes")
except (AttributeError, ValueError, OSError):
 base = 4096
 print("Assumed illustration base page size:", base, "bytes")

if all(key in values for key in FIELDS) and values["Hugepagesize"] > 0:
 huge = values["Hugepagesize"] * 1024
 print("Default-size hugetlb pool counters:", values)
 print("Total pool capacity:", values["HugePages_Total"] * huge, "bytes")
 print("Reserved but not allocated:", values["HugePages_Rsvd"] * huge, "bytes")
else:
 huge = 2 * 1024**2
 print("SKIP complete pool report; assuming 2 MiB for arithmetic only")
print("8 GiB page-count illustration:", pages_for(WORKING_SET, base),
 "base pages versus", pages_for(WORKING_SET, huge), "large pages")
print("No TLB miss rate, THP coverage, allocation success, or latency was measured")

若基准页为 4 KiB、默认大页为 2 MiB，预期看到前述两组页数。池总数为零是一种有效观察，不证明内核不支持大页。修订脚本已在 Linux、Python 3.12.14 下执行通过。它没有测量 THP 覆盖率、真实分配成功率或性能；这些结论需要另外设计与工作负载对应的实验，不能从一份只读容量报告直接推出。

来源

内核巨型页文档，定义 hugetlb 设置与行为，已核验 2026-06-01。
内核透明巨型页文档，定义 THP 模式与后台整理行为，已核验 2026-06-01。
proc_meminfo：大页计数，核对内存承诺、大页计数与单位，已核验 2026-10-15。

Linux overcommit 为虚拟内存承诺设定政策

Sat, 18 Dec 2027 00:00:00 +0000

Linux 的 overcommit 政策控制某些虚拟内存承诺是否可以获准，和分配常驻物理页、选择 OOM 牺牲进程、执行容器内存限制并不是同一件事。一次成功申请可能早于实际物理需求，但这不表示所有分配都没有成本，也不保证后续访问在任何资源约束下都能成功。分析时应把承诺、驻留和故障处理分别记录，而不是都称为“剩余内存”。

虚拟承诺不同于实际驻留

malloc 等分配器可能通过 brk 或 mmap 取得内存，也可能直接复用已有内存区，不发起新的系统调用。匿名页通常按需填入，但地址空间元数据、页表以及实际缺页过程仍然消耗资源。具体成本取决于应用申请什么、访问什么，不能把延迟分配简化成近乎免费地运行整个进程。

Committed_AS 是记账数量，不是所有进程常驻集之和，也不是当前内存压力读数。映射类型会影响成本：私有可写映射可能在页面尚未全部驻留时就形成承诺，普通共享或只读文件映射则采用不同规则。因此，虚拟大小很大的进程未必就是物理内存短缺的责任方，应同时查看实际使用和对应记账范围。

三种准入政策

模式零是默认启发式政策，拒绝明显超额的申请，同时允许超过简单常驻内存预算的分配。它的判断不等于为每个获准字节准备专属 RAM。模式一跳过 overcommit 准入检查，有助于某些稀疏工作负载，但地址空间上限、映射数量以及其他分配失败仍然存在，不能描述成任何荒谬请求都会被无条件接受。

模式二执行更严格的承诺记账。名义 CommitLimit 来自交换空间加上配置的内存额度：比例计算会扣除预留给 hugetlb 的内存，非零 overcommit_kbytes 则用绝对额度代替比例。内核保留量与调用上下文还会影响实际准入。因此，CommitLimit 与 Committed_AS 的差值是有用背景，不是保证任意调用者都能一次申请成功的最大值，也不是当前可用物理内存。

需要记账的分配如果无法纳入预算，可能立即返回 ENOMEM，使部分容量问题更早暴露，包括 fork 和后续改变映射权限所需的承诺。fork 记账与具体映射及写时复制义务有关，并不是简单把父进程常驻集乘二。有些应用有意保留稀疏地址空间，因此政策变化可能影响启动，即使它们预计不会触碰所有页面。

严格记账不是 OOM 免疫

模式二降低一类超额承诺风险，却不会覆盖 cgroup 内存限制、NUMA 约束、其他内核分配以及所有后续需求。任务仍可能遇到内存分配失败或 OOM 事件。不能承诺选了模式二，某个业务工作进程就绝不会被杀，更不能把这个模式当成服务可靠性的单一开关。

OOM 牺牲者选择属于另一套政策，要结合事件范围与候选资格理解，并非随机惩罚，也不是 CPU 调度器决定谁来买单。被杀进程不一定是最后申请内存的任务。判断原因之前，应查看事件属于宿主还是某个 cgroup，并结合相关压力与分配证据，不能只凭日志里的进程名称就完成责任归因。

容器共享宿主内核，不应假定每个容器都有自己独立的 vm.overcommit_memory 政策；容器内存控制又增加另一条边界。虚拟机有自己的客户机内核记账，但宿主后备内存和气球等机制还可能增加约束。比较预算前，应先标明每个读数属于哪一层，避免拿宿主 CommitLimit 去解释某个容器的完整可用额度。

坏掉的样子

工作负载可以成功保留内存，随后随着真实需求增长进入回收、交换或 OOM。模式零和模式一都不保证故障一定慢慢发生，不保证有交换空间，也不保证由某个固定进程被杀。应把业务需求和延迟与真实回收、内存压力证据对齐，而不是由模式编号直接猜测故障形态。

相反，模式二可能在物理内存看似仍有空闲时拒绝申请，因为承诺预算已经占满。这是 ENOMEM 的一个可能原因，不是仅凭错误就得出的诊断；进程资源限制、映射过多和应用配置也需要检查。一次启动失败与一次运行中被杀代表不同观察，不应混成同一条调参建议。

名义余量很大，不证明比例太保守；余量很小，也不自动意味着应增大额度。预算变大会放行更多未来可能竞争真实资源的需求。应根据业务要求与恢复余量做规划，保留配置上下文，并先在非生产环境验证变化。只读报告可以帮助提出问题，但不应擅自替操作者决定扩大或缩小系统承诺。

快速验证

保存为 overcommit_probe.py，运行 python3 overcommit_probe.py。程序只读取列出的 proc 文件，打印实际模式和记账字段，同时执行合成解析检查。它不保留巨大内存、不触发 OOM，也不自动建议修改参数。读不到必要文件时明确跳过，而不是把权限错误文本里的数字当作有效内存数据。

from pathlib import Path
import re


def read_value(path):
 try:
 return Path(path).read_text(encoding="utf-8").strip()
 except OSError as error:
 print("SKIP", path, type(error).__name__)
 return None


def meminfo_kb(text):
 return {name: int(value) for name, value in re.findall(
 r"^(MemTotal|SwapTotal|CommitLimit|Committed_AS):\s+(\d+)\s+kB\s*$",
 text, re.M)}


def report(mode, info):
 names = {"0": "heuristic", "1": "always overcommit", "2": "strict accounting"}
 lines = ["mode: " + names.get(mode, "unknown or unreadable")]
 limit, committed = info.get("CommitLimit"), info.get("Committed_AS")
 if limit is not None and committed is not None:
 lines.append("nominal commit headroom: %s kB" % (limit - committed))
 else:
 lines.append("commit headroom unavailable")
 if mode == "2":
 lines.append("Commit accounting can reject chargeable requests; other limits still apply")
 else:
 lines.append("CommitLimit is not the enforced mode-2 ceiling in this mode")
 lines.append("This snapshot is not available RAM, a cgroup budget, or OOM immunity")
 return lines


fixture = meminfo_kb("CommitLimit: 100 kB\nCommitted_AS: 0 kB\n")
assert "nominal commit headroom: 100 kB" in report("2", fixture)
assert meminfo_kb("CommitLimit: bad kB\nCommitted_AS: 7 MB\n") == {}
assert "commit headroom unavailable" in report("2", {})
assert report("9", {})[0] == "mode: unknown or unreadable"
for mode in ("0", "1", "2"):
 assert "OOM immunity" in report(mode, fixture)[-1]

mode = read_value("/proc/sys/vm/overcommit_memory")
ratio = read_value("/proc/sys/vm/overcommit_ratio")
kbytes = read_value("/proc/sys/vm/overcommit_kbytes")
text = read_value("/proc/meminfo")
if mode is None or text is None:
 print("SKIP live overcommit report; synthetic checks passed")
else:
 info = meminfo_kb(text)
 print("overcommit_memory=%s overcommit_ratio=%s overcommit_kbytes=%s" % (mode, ratio, kbytes))
 print("Observed kB fields:", info)
 for line in report(mode, info):
 print(line)

预期得到实时快照，或明确的 SKIP 信息；已提交量为零仍是有效值。修订后的示例已在 Linux、Python 3.12.14 下通过，合成断言覆盖错误格式、缺失字段和三种模式的解释。读取计数没有验证真实分配拒绝或恢复行为；这些仍需要另外设计受控实验，不能为了检查政策而在共享机器上制造内存耗尽。

来源

内核 vm 参数文档，定义 overcommit_memory 各模式与默认值，已核验 2026-06-01。
proc 手册页，记录 /proc/meminfo 中 CommitLimit 与 Committed_AS 的记账含义，已核验 2026-06-01。
内核 overcommit 记账规则，核对策略模式与纳入承诺记账的映射，已核验 2026-10-15。
proc_meminfo：CommitLimit 与 Committed_AS，核对内存承诺、大页计数与单位，已核验 2026-10-15。
内核 cgroup v2 内存控制，核对局部内存限制与 OOM 边界，已核验 2026-10-15。

缺页并不总是意味着存储读取

Sat, 13 Nov 2027 00:00:00 +0000

缺页表示处理器无法依据当前映射或权限完成一次访问。它不等于存储读取，有些缺页还代表非法访问，而不是可以恢复的按需分页。Linux 的次缺页与主缺页计数，区分处理过程中是否需要页面换入输入输出。解释时应结合映射类型与工作负载，不能把任意一个计数直接当作应用全部存储流量，更不能仅凭名字中的“主”“次”判断问题严重程度。

次缺页不代表没有成本

次缺页可能为已有文件缓存页建立映射，也可能为匿名内存分配并清零物理页，或在写时复制时复制一页内容。内核可能需要分配内存、维护页表、复制数据和同步。把它说成只增加一个指针，会遗漏这些真实成本。即使完全没有存储读取，密集次缺页仍然可以消耗可观处理器时间，影响请求延迟，不能因为分类是 minor 就无条件忽略。

应用第一次访问，并不保证每个基本页都产生一次新的缺页。预先建立映射、已存在的映射、预读相关处理和大页都可能改变计数。系统页大小也不是处处都等于四千零九十六字节。示例应读取本机值，不能从循环次数直接承诺精确缺页数量；否则换一台机器或启用不同内存策略，实验就可能因为错误前提而失败。

主缺页描述另一条处理路径

主缺页意味着处理涉及页面换入输入输出，常见于文件映射或已换出的内存。背后可能是存储设备，也可能是远程文件系统，因此这个分类不是物理磁盘延迟基准。一次缺页还可能触发预读，让后续访问直接获益，计数与页数或磁盘请求数并不一一对应。反过来，普通文件读取也可能产生输入输出，却不在应用里形成对应的主缺页。

文件页已经在主机缓存中时，新进程即使从未访问过它，也可能只产生次缺页。重启进程不等于清空整台机器的页缓存。匿名内存首次写入通常通过分配零填充页面完成，不必从存储读回旧载荷，但压力和同时发生的活动仍会影响测量。“匿名”不能保证整个进程的主缺页计数在任何环境都保持不变；应以本次实际计数为准。

坏掉的样子

冷启动延迟可能与主缺页同时出现，但在查清缺少什么之前，不应一律建议预热。提前触碰不需要的页面会消耗内存，甚至挤掉有用缓存。错开启动也许能缓解已确认的共享瓶颈，另一个负载却可能需要更小映射、不同访问模式或更多容量余量。单靠缺页数无法在这些方案之间作出可靠选择，需要把变化与业务延迟联系起来。

持续交换会让被逐出的页面反复进入工作集，并拉长等待。增加工作者可能扩大内存需求，使情况更差。应关联缺页、换入换出、回收、存储等待和请求延迟，而不是一看到主缺页上升就宣布存储设备损坏，或认定所有缓存缺失都本来可以避免。对顺序扫描和随机访问，也应分别理解预读与局部性的作用。

进程级计数还包含测量代码之外的工作。解释器、启动过程和其他线程都可能贡献变化。常驻情况查询只是一个时刻的快照，紧接着访问时状态可能已经改变。不要为了得到更明显的图表就清空全局缓存，或不断扩大分配直到影响其他任务。诊断实验应该有明确资源预算，并保留失败时的原始观察，而不是只保留符合预期的数字。

快速验证

保存为 fault_probe.py，在有足够空闲内存的 Linux 上使用 Python 3.9 或更新版本执行 python3 fault_probe.py。程序创建十六 MiB 的私有匿名映射，按本机页大小每页写一个字节，再重复一轮。结束时自动关闭映射，不操作文件、不修改全局缓存设置，也不改变任何内存限制。

import mmap
import resource
import sys
import time

if not sys.platform.startswith("linux"):
 raise SystemExit("This exercise requires Linux getrusage semantics")
PAGE = mmap.PAGESIZE
SIZE = 16 * 1024 * 1024

def counters():
 value = resource.getrusage(resource.RUSAGE_SELF)
 return value.ru_minflt, value.ru_majflt

def touch(region):
 for offset in range(0, len(region), PAGE):
 region[offset] = 1

with mmap.mmap(-1, SIZE, flags=mmap.MAP_PRIVATE | mmap.MAP_ANONYMOUS,
 prot=mmap.PROT_READ | mmap.PROT_WRITE) as region:
 before = counters()
 start = time.perf_counter()
 touch(region)
 first_seconds = time.perf_counter() - start
 middle = counters()
 start = time.perf_counter()
 touch(region)
 second_seconds = time.perf_counter() - start
 after = counters()
first = tuple(b - a for a, b in zip(before, middle))
second = tuple(b - a for a, b in zip(middle, after))
print(f"page_size={PAGE} mapping_bytes={SIZE}")
print(f"first: minor={first[0]} major={first[1]} seconds={first_seconds:.6f}")
print(f"second: minor={second[0]} major={second[1]} seconds={second_seconds:.6f}")
assert first[0] > 0, "expected demand-fault activity"
assert second[0] < first[0], "repeat pass did not show reduced minor faults"
assert first[1] == second[1] == 0, "observed major faults: this run is not a no-major example"
print("PASS: this run had fewer second-pass minor faults and no measured major faults")

本实验预期第一轮出现按需缺页，第二轮次缺页减少，并且这次运行没有测得主缺页。本轮两种语言的完整示例均通过这些断言。计数与耗时只是观察，不是固定目标。脚本没有断言第二轮一定更快，因为计时、调度和机器负载会变化。使用本机页大小，也避免把某种平台常见值误当成通用常量。

如果断言失败，说明当前运行没有建立预期对照，应检查内存条件和计数，不能悄悄删除检查。通过结果展示的是一个匿名内存案例：发生了缺页活动，却没有测得页面换入输入输出。它没有演示文件映射主缺页，没有给出通用缺页延迟，也不能替代真实应用在代表性压力下的测量。把这个局部结论保持在实验范围内，才不会从可重复现象跳到错误的生产诊断。

来源

Linux getrusage，次缺页和主缺页计数语义，已核验 2026-10-15。
Linux mmap，私有匿名映射与预先填充行为，已核验 2026-10-15。
Linux memory concepts，按需分页、页缓存、回收和大页，已核验 2026-10-15。
Linux process stat，进程缺页计数与范围，已核验 2026-10-15。

Redis 内存比率需要结合分配背景判断

Thu, 03 Jun 2027 00:00:00 +0000

即使应用键已经删除，Redis 进程仍可能保留较大的常驻内存。这个现象值得解释，但它本身既不能证明内存泄漏，也不能直接证明分配器碎片。真正要回答的是哪些字节仍被分配、哪些页面仍驻留，以及这种占用是否威胁实际容量预算。只看一个名字里带“碎片”的比率，很容易选错处理对象。

把不同测量对象分开

INFO memory 中的 used_memory 表示 Redis 统计的分配量，used_memory_rss 则是操作系统观察到的进程常驻内存。它们都不等于应用负载长度的简单相加，键、对象、元数据、客户端及其他开销也要占空间。MEMORY USAGE 可以估计单个键及其值的分配量，包括相关开销，但不测量这个键独立贡献了多少进程 RSS。

mem_fragmentation_ratio 大体比较常驻内存和 Redis 统计的分配量，两者差额还可能包括代码、共享库、栈以及分配器保留的页面。删除数据后分母下降，即使 RSS 几乎不变，比率也可能迅速升高。因此必须同时检查绝对字节数；一个很小的空实例出现较高比率，不等于它正在占用危险数量的内存，更不是必须立即重启的充分理由。

used_memory_peak 有助于解释此前负载峰值留下的占用。used_memory_dataset 是另一个统计视角，不承诺空键空间对应零进程分配。各项数据也并非全都在 INFO 执行的同一瞬间采样。写入活跃时，不应要求经过四舍五入的比率，精确等于独立读取的两个数字相除，否则可能把采样差异误当成实现错误。

先核实分配器和版本

分配器专用指标有助于区分碎片、保留页面和非堆开销，但含义取决于实际构建。Redis 8.10.1 源码通过小尺寸分配桶的碎片计数计算相关指标，并对 Lua 部分作调整。不能把所有版本的指标都简单重算成 active 除以 allocated；通用文档公式与实际行为不符时，应检查对应版本实现，而不是让旧解释覆盖当前事实。

本实验有意使用 libc 编译。该构建没有 jemalloc 的详细统计，Redis 会用其他测量值补算部分分配器字段，碎片计数则保持为零。因此 allocator_frag_ratio 等于一，不证明进程真的完全没有碎片。解释专门字段或选择处理方式之前，应先记录 mem_allocator，确认数字来自真实分配器统计，还是当前构建能够提供的有限信息。

坏掉的样子

RSS 上升的同时数据集也在增长，首先需要分析负载和容量，而不是自动诊断为碎片。数据集下降、RSS 稳定，提示常驻占用被保留，却仍不能识别每个保留页面的用途。同样，一次快照无法排除泄漏。应比较相同负载下的时间序列、值大小分布、历史峰值及进程限制，避免把相关现象直接当成唯一原因。

MEMORY PURGE 只在相应实现支持时尝试让分配器回收。Redis 明确说明，除 jemalloc 外的分配器执行它属于无害的空操作，因此成功回复不是内存已经回收的证据；它也不会删除应用键。主动碎片整理是另一种机制，需要构建支持，启用后还可能增加 CPU 与延迟，必须单独测量成本和收益。

为了降低比率而重启，可能带来停机、冷缓存负载，或者在持久化与恢复不足时丢失数据。应先证明存在实际容量问题，并准备演练过的恢复路径，再把重启纳入处理方案。maxmemory 不是 RSS 上限，键数减少也不保证页面立即归还操作系统；不能只看到键数归零，就宣布整个内存问题已经修复。

快速验证

原有实验记录使用 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新执行服务实验，下面的结果说明保留原有观察范围。准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。安装步骤仅用 libc 构建 Redis 核心，并把客户端装入临时虚拟环境。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

使用 "$redis_lab/venv/bin/python" 运行 Python 代码。程序在 /tmp 创建专用 Redis 进程和私有 Unix socket，关闭 TCP 与持久化，仅写入自己的三百二十个样本键。值大小交替为十六或六十四 KiB，短暂停顿让指标有机会刷新，但不假设采样恰好发生在某个时刻。结束后关闭自己的进程，移除临时运行目录。

from contextlib import contextmanager
import json
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(policy="noeviction"):
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


with instance() as client:
 def snapshot(stage):
 time.sleep(0.2)
 info = client.info("memory")
 fields = ["used_memory", "used_memory_dataset", "used_memory_rss",
 "used_memory_peak", "mem_fragmentation_ratio", "mem_allocator",
 "allocator_frag_ratio", "allocator_frag_bytes"]
 print(stage, json.dumps({"keys": client.dbsize(),
 **{name: info[name] for name in fields}}, sort_keys=True))
 return info

 empty = snapshot("empty")
 for index in range(320):
 client.set(f"sample:{index}", "x" * (16384 if index % 2 == 0 else 65536))
 assert client.dbsize() == 320
 assert client.memory_usage("sample:0") >= 16384
 loaded = snapshot("loaded")
 assert loaded["used_memory"] > empty["used_memory"] + 10 * 1024 * 1024
 for index in range(1, 320, 2):
 assert client.delete(f"sample:{index}") == 1
 assert client.dbsize() == 160
 half = snapshot("large values deleted")
 assert half["used_memory"] < loaded["used_memory"] - 8 * 1024 * 1024
 for index in range(0, 320, 2):
 assert client.delete(f"sample:{index}") == 1
 assert client.dbsize() == 0
 assert client.memory_usage("sample:0") is None
 cleared = snapshot("all values deleted")
 assert cleared["used_memory"] < half["used_memory"]
 assert cleared["used_memory_peak"] >= loaded["used_memory"]
 assert client.memory_purge()
 snapshot("after MEMORY PURGE")
 print("PASS: logical allocations fell; no RSS or purge-effect threshold is assumed")

原有运行记录在加载后报告 used_memory 约十六点七 MiB。删除所有键后，这个数值降到约一点零四 MiB，而 RSS 仍在二十点八 MiB 附近，于是整体比率升到约二十。MEMORY USAGE 同时确认指定键已不存在：逻辑分配确实减少，但常驻内存没有按同样比例下降，不能仅凭较高比率反推应用键没有删掉。

这次 libc 实验中，分配器专用碎片比率始终为一，MEMORY PURGE 也成功返回，却没有带来有意义的 RSS 下降。断言检查键数和逻辑分配量之间的关系，精确 RSS 仅作观察，不设为通过阈值。它证明统计对象存在差异及空操作限制，不证明 jemalloc 整理的效果、Linux 内存压力行为，也不构成对某个生产进程的泄漏诊断。

来源

Redis INFO，进程、分配、峰值与分配器内存字段，已核验 2026-09-08。
Redis MEMORY USAGE，单键分配估计及相关开销，已核验 2026-09-08。
Redis MEMORY PURGE，jemalloc 支持及其他分配器的空操作行为，已核验 2026-09-08。
Redis 8.10.1 对象统计，对应版本的碎片计算方式，已核验 2026-09-08。
Redis 8.10.1 内存采样，缓存测量结果及补算分配器字段，已核验 2026-09-08。
Redis 8.10.1 编译说明，核心构建与分配器选择，已核验 2026-09-08。

Swap 用回收成本换取驻留空间

Wed, 25 Nov 2026 00:00:00 +0000

Swap 为 Linux 中适合换出的页面提供后备存储，让暂时不需要驻留的数据离开物理内存，把 RAM 留给活跃工作。但它不会让超出容量的工作集继续拥有内存访问速度。真正要问的是：回收是否腾出了空间，同时没有反复阻塞重要任务。交换占用、交换流量与应用进展，分别回答这个问题的一部分，不能拿其中一个数字概括全部情况。

分清哪些页面可以移动

匿名内存经常使用交换，但并非唯一情况。配置允许时，tmpfs 和共享内存页面也能换出。普通文件支撑的干净页面通常可以丢弃，以后从原文件重读；脏文件页则需要适当写回。并非所有分配都可以回收，被锁定而禁止换页的内存还有另外约束。因此，“所有 malloc 分配的东西”不足以描述内核实际上能够移走哪些内容。

vm.swappiness 在零到二百的文档范围内，表达交换与文件系统换页之间的相对成本；它不是达到某个 RAM 使用百分比后才开启交换的阈值。设为零也不等于在所有情形下禁用交换。如果压缩交换或更快的交换设备比文件系统换页便宜，大于一百的值可能合理，但适当取值取决于工作负载与存储。解释图表之前，应先读取实际配置，而不是默认每台机器都采用相同策略。

zram 提供压缩内存块设备，可以配置为交换；zswap 则在交换页与后备交换设备之间提供压缩缓存。压缩本身消耗 RAM 和 CPU，效果也依赖数据内容。两者都没有通用的延迟、压缩比或安全超配比例。zswap 不是可以直接挂到 /tmp 的文件系统；tmpfs 挂载具有自己的存储语义和容量约束，不能把名称相近的内存机制当成同一项功能。

坏掉的样子

反复回收马上又要使用的页面，会造成严重停顿。原因可能涉及存储延迟与吞吐，也可能涉及回收工作、压缩开销、控制组限制和竞争 I/O。颠簸并不保证最终触发 OOM 杀进程，固定的交换速率也不是普遍适用的诊断线。应把内存压力与有效吞吐、响应时间放在同一个观察窗口比较，再决定主要瓶颈在哪里。

交换已用量很大，可能只是早先事件留下的冷页面，不证明当前正在发生故障。相反，交换流量很小也不证明内存足够：交换可能未启用，工作负载可能碰到控制组上限，或者回收主要发生在文件页。主缺页计数上升也包括文件支撑的缺页，不能直接重新命名成换入次数。把相关指标当成同一个计数器，会让排查走向相反结论。

计划中的交换文件可能因为布局或文件系统限制而无法启用。带空洞的文件不适用，但复制是否产生空洞，取决于具体工具、选项和源文件，不能一概而论。应检查已经激活的交换清单，不要假定配置文件里写过一行就已经生效。也不要仅为重现一篇诊断文章，就在活动机器上启停交换或调整容量。

快速验证

在安装了 util-linux 和 procps 的 Linux 环境运行这些只读命令。检查只观察当前环境的三个采样间隔，不制造内存压力，也不更改内核设置。机器没有启用交换也是有效观察结果，并不是实验失败；它只是告诉你不能依靠这些交换设备缓解未来的页面回收需求：

set -eu
swapon --show
free -h
vmstat -y 1 3
grep -E '^(pswpin|pswpout|pgmajfault) ' /proc/vmstat
if test -r /proc/pressure/memory; then
 cat /proc/pressure/memory
else
 printf '%s\n' 'memory PSI is unavailable in this environment'
fi

swapon --show 列出已经启用的交换区域，free 则分别报告内存与交换总量。vmstat -y 省去自开机以来的首份统计，因此输出的三行对应采样间隔。阅读显示单位，把换入换出与阻塞任务、CPU 时间一起比较。随后从 /proc/vmstat 读取的累计计数是另一份快照，不能直接当成前面每行对应的每秒速率。

如果环境提供内存 PSI，它报告因内存压力而停顿的时间。some 和 full 分别表示测量范围内至少部分任务停顿，以及所有非空闲任务同时停顿。短暂安静的样本不能排除之前发生过尖峰。容器可见性与控制组边界也很重要：宿主累计计数并不会自动说明某一个应用还能分配多少内存，分析必须匹配真正受限制的对象。

这项检查验证的是观察路径及解释方法，没有测量存储性能、决定安全交换容量，也没有验证 OOM 恢复。保留时间戳，用代表性的事故窗口对照应用延迟与资源限制。如果证据表明工作集持续挤压内存，应减少需求或提供适当容量。调整回收策略时要有可撤销方案，并衡量实际服务效果，不能把交换使用量永远为零当成独立目标。

来源

内核 VM sysctl，相对 I/O 成本与零值行为，已核验 2026-10-15。
内核 tmpfs，可换出的 tmpfs 与挂载限制，已核验 2026-10-15。
内核 zram，压缩块设备与存储统计，已核验 2026-10-15。
内核 zswap，压缩交换缓存及后备设备关系，已核验 2026-10-15。
内核 PSI，内存停顿范围与平均值，已核验 2026-10-15。
vmstat(8)，间隔报告与交换速率字段，已核验 2026-10-15。
proc_vmstat(5)，独立的交换与主缺页计数，已核验 2026-10-15。
swapon(8)，活动清单与交换文件约束，已核验 2026-10-15。

zram 用压缩的方式在内存里挤出交换空间

Tue, 24 Nov 2026 00:00:00 +0000

内存吃紧时，冷页面常被送去慢速磁盘；zram 则用压缩的内存替代这一步，用小部分 CPU 换取可观的内存空间。

内存里的压缩块设备

zram 是一块驻留在内存里的块设备,它不跟磁盘对话,而是先在内存里把换出的页压缩、保存起来。内核把一页换给它时,页先被压缩、留在内存中,于是内存方面的减压方式并不是「把页挪去磁盘」,而是「让这一页变小」。因为设备本身挂在内存上,读写它的速度远比磁盘后备 swap 快;可它的容量同样受制约——既取决于当前这页有多可压缩,也取决于你愿意拿多少真实内存去换这块 swap。

压缩就是这笔交易

「压缩」就是这笔交易赚头所在,也是「一台小机型显得能装下比物理内存更多内容」的根源。一页值不值得压要看内容:全零页、文本和有结构的数据都缩得不错,而图片、压缩包这类已经被压缩过的对象几乎缩不动。站在工程视角看,zram 等于把暂时闲置的 CPU 换算成「看似更多」的内存;当初工作负责多半是可压缩的、又特别想避开真实磁盘换页的延迟时,这笔交易才划算。

适合服务器与低端设备

它最合身的地方是那些内存不多、换页压力又不过度的机器:小 VPS、容器宿主机,以及手机、路由器这类如今要把袖珍机器安排得明明白白的角色。反过来,内存本来就充裕、或者本来就要换到冷冷盘上的服务器,同一笔钱买一张真实磁盘往往能装下更多,因此未必轮到 zram。实用的判断方法是盯住压缩率和 swap 使用量:当驻留数据始终很小、又够可压缩、且 CPU 相对空闲,才是让 zram 出场的时刻。

坏掉的样子

最常见的失望是压缩比根本没有到来。照片、视频、加密缓冲和已经压过的归档几乎压不动，mm_stat 里 orig_data_size 只比 compr_data_size 大一点，交换空间却照样被占满。内存池和元数据照样吃掉真实内存，腾出来的余量几乎为零，杀手来得和没开压缩交换一样快。压缩比是数据的属性，不是设备的属性，容量只能按实测值去估。

选错算法是死在处理器上，不是死在容量上。重型算法放在小内存虚拟机或旧手机上，每次换出都要烧大量周期，回收线程转个不停，系统态占用随压力一起涨，交换还没满，长尾延迟先垮了。交互型机器先选 lzo-rle、lz4 或低档 zstd 这类快速算法，换算法前一定要在真实负载下看占用和延迟。

同时打开 zswap 和压缩交换等于把同一页压两遍，白白浪费处理器。zswap 自己先留一块压缩池，再把已经压过的页交给压缩设备，后者几乎找不到可省的空间。两条路径一起烧处理器，交换看似用了不少，有效容量却没涨多少。一条交换路径只留一层压缩：要么把压缩设备当交换，要么让 zswap 走在磁盘交换前面，不要双开。

写死的容量是最安静的错配。某台机器从大内存规格缩到小规格，单元文件里写死的几吉字节不变，压缩池一下占掉近半内存，杀手来得更快；反过来从小规格升到大规格，旧的几吉字节又白白浪费了余量。容量在创建交换时就定死，不会跟着内存热插拔或实例变配走。应该在开机时按内存比例算出容量，变配后复查设备大小并记录在部署说明里。

快速验证

把下面这段存成 zram_ratio.py，放在临时目录里跑 python3 zram_ratio.py。它只用标准库，以只读方式打开 /sys/block/zram*/mm_stat，不需要特权，也不做任何写入。脚本解析每台设备原始字节与压缩后字节，用两者相除算出压缩比和节省比例。机器上没有压缩设备时打印 SKIP，转而用同一套公式给一组示例数字算一遍，保证在任何机器上都能跑通。

#!/usr/bin/env python3
"""只读的 zram 压缩比检查（仅标准库）。"""
import glob
from pathlib import Path


def parse_mm_stat(text):
 parts = text.split()
 if len(parts) < 2:
 raise ValueError("mm_stat 至少需要原始与压缩两个字段")
 orig = int(parts[0])
 compr = int(parts[1])
 rest = [int(x) for x in parts[2:]]
 return orig, compr, rest


def report(device, orig, compr):
 if compr <= 0:
 print("%s: orig=%d compr=%d ratio=n/a (empty)" % (device, orig, compr))
 return
 ratio = orig / compr
 saved = 100.0 * (1.0 - compr / orig) if orig > 0 else 0.0
 print("%s: orig=%d compr=%d ratio=%.2f saved=%.1f%%" % (device, orig, compr, ratio, saved))


def main():
 paths = sorted(glob.glob("/sys/block/zram*/mm_stat"))
 if not paths:
 print("SKIP: 找不到 /sys/block/zram*/mm_stat（无 zram？非 Linux？）")
 orig, compr = 300 * 1024 * 1024, 100 * 1024 * 1024
 print("用同一套公式给示例数字计算：")
 report("example/zram0", orig, compr)
 print("PASS: 比例公式可用；在 zram 主机上上面会换成实时行")
 return
 for path in paths:
 try:
 text = Path(path).read_text(encoding="utf-8")
 except OSError as exc:
 print("SKIP: 无法读取 %s（%s）" % (path, exc))
 continue
 try:
 orig, compr, _ = parse_mm_stat(text)
 except (ValueError, IndexError) as exc:
 print("SKIP: 无法解析 %s（%s）" % (path, exc))
 continue
 device = path.split("/mm_stat")[0]
 report(device, orig, compr)
 print("PASS: 已展示实时统计；比例走低加池满意味着改容量或换算法")


if __name__ == "__main__":
 main()

在打开压缩交换的机器上，它会逐台打印原始字节、压缩后字节、压缩比、内存占用和上限，压缩比一路走低或内存池打满都能在杀手到来前看到。在普通笔记本或没有设备的容器里，它先打印 SKIP 再展示示例计算，示例里三比一的比例对应节省约三分之二。它只验证统计口径和算术，不证明算法和容量选得对，调优前还要对照单元文件复查算法名和容量比例。

来源

kernel.org：zram 块设备，zram 的权威文档，已核验 2026-11-23。
Wikipedia：zram，zram 是什么、怎样运作，已核验 2026-11-23。
ArchWiki：Zram，实际配置与调优，已核验 2026-11-23。

排查 OOM 应先确认分配范围

Mon, 26 Oct 2026 00:00:00 +0000

当一次分配在相关限制范围内无法满足，适当的回收尝试也不能解决问题时，Linux 可能调用内存不足终止机制。它是最后阶段的恢复手段，不是理解业务重要性的调度器。有些分配会直接失败而不杀进程，配置也可能使系统进入恐慌处理。因此，排查应先识别分配范围与实际事件，不能一开始就认定整台机器的每一字节内存都已经用完。

先看范围，再看评分

全局内存短缺与内存控制组短缺是两回事。某个控制组可以在主机仍有可用内存时达到自身上限；它的 OOM 处理不能任意挑选组外进程来解决组内问题。允许使用的内存节点等其他限制也可能影响分配。因此，主机剩余内存图表不足以证明或否定某次失败，更不能在没有检查事件范围时，把所有容器异常都归类为全局容量不足。

在适用的选择规则内，内存占用与调整值会影响牺牲者选择。内核并不知道哪个进程商业价值高、哪个空闲服务可以丢弃，也不知道哪一个业务必须持续可用。一个体积很大的数据库可能被选中，即使压力也来自许多小工作者。procfs 中的 oom_score 是可观察数值，不是承诺把所有可见进程排序以后，就能准确预测任何内存域下一次会杀谁。

理解调整值，不许诺必然存活

oom_score_adj 的范围为负一千到正一千。正值增加被选中的倾向，负值降低它；负一千会把该任务排除在这项内核 OOM 选择之外。一般负值并不保证存活，这个设置也不能阻止显式信号、服务管理器或独立用户态内存压力策略终止任务。调整分值不会增加容量，也不会修复泄漏。把它解释成“重要进程已经免疫所有内存故障”，会造成危险的运维误判。

保护所有任务不是可行的容量方案。如果没有合适的牺牲者，不能假定内核会越过控制组边界，去杀一个无关的监管进程。整组终止与恐慌设置需要分别分析。调整值可以被子进程继承，而持久服务设置应归入监管器配置；修改之前需要明确授权并验证适用范围。下面实验不会改动这些值，也不制造内存压力，避免把接口学习变成真实故障。

坏掉的样子

反复重启可能掩盖持续泄漏。如果同一个工作负载不断增长直至失败，增加内存也许只是延长两次失败之间的间隔。应关联分配速度、常驻和记账内存、负载大小、回收及交换活动。单个进程的常驻大小不能完整表示控制组全部费用或共享内存关系。降低上限可以约束增长范围，却也可能让应用更早失败；不能只观察邻居未被终止，就认为业务恢复问题已经解决。

退出状态一百三十七与 SIGKILL 相符，但并不是 OOM 专属证据。应查看运行时的终止原因、控制组内存事件计数和操作员可见的内核记录。分配失败、进程被杀、内核 OOM 和用户态压力管理器终止，是需要分开的情况。看不到内核日志，也可能只是当前观察范围受限，不能直接证明没有事件发生。诊断必须说明证据来自哪里、有哪些缺口。

评分会随内存和范围变化。读取 procfs 的过程中进程可能退出，容器内的进程视图也可能隐藏主机的大部分任务。一次成功读取并不是原子的整机快照。分析真实失败时，应保留事件时间与受影响的控制组，然后比较相同范围内的观察，而不是拿事后另一个进程的分数去解释之前的牺牲者选择。

快速验证

保存为 oom_observe.py，使用 Python 3.9 或更新版本执行 python3 oom_observe.py。程序只读取自身进程的两个评分文件，不创建压力负载，不修改任何限制或策略。两条确定性断言仅对明确虚构的记录测试展示顺序，实时读取和模型检查会分别报告结果，避免把一种成功误当成另一种验证。

"""Read-only observations and a sorting test, not an OOM predictor."""
from pathlib import Path
import os

def snapshot(pid):
 base = Path('/proc') / str(pid)
 try:
 return (int(pid), int((base/'oom_score').read_text()),
 int((base/'oom_score_adj').read_text()))
 except (OSError, ValueError):
 return None

def ranked(rows):
 return sorted(rows, key=lambda row: (-row[1], row[0]))

fixtures = [(42, 700, 0), (17, 100, -500), (99, 700, 200)]
assert [row[0] for row in ranked(fixtures)] == [42, 99, 17]
assert ranked([]) == []
row = snapshot(os.getpid())
if row is None:
 print('SKIP: this process has no readable Linux OOM score files')
else:
 pid, score, adjustment = row
 assert -1000 <= adjustment <= 1000
 print(f'pid={pid} oom_score={score} oom_score_adj={adjustment}')
 print('Observed one process; no victim selection or memory pressure tested')
print('PASS: deterministic sorting checks; live observation is reported separately')

虚构记录按分数降序排列，同分时按数字进程号排序，低分记录排在最后。代码没有根据虚构调整值重新计算内核评分。Linux 分支单独打印当前进程的分数和调整值；文件不可读时报告 SKIP，但仍执行排序断言。因此，末尾 PASS 不意味着实际的 OOM 处理已经发生，更不是一次牺牲者选择实验。

本轮在 Linux 环境执行了两份完整示例，排序断言通过，并读到了各自的 procfs 文件。没有选中或终止任何牺牲者。这个小练习用于认识观察接口；真正的故障仍需使用范围一致的事件证据分析。无论排序如何变化，还是为重要进程设置了负值，都不能单独证明服务在内存压力下将持续可用。

来源

Linux memory concepts，分配、回收和内存不足边界，已核验 2026-10-15。
proc_pid_oom_score，进程评分接口，已核验 2026-10-15。
proc_pid_oom_score_adj，调整范围及受约束分配上下文，已核验 2026-10-15。
Linux cgroup v2，内存上限、整组终止与保护范围，已核验 2026-10-15。

内存 · XB 现场笔记

PostgreSQL 使用两层数据缓存

坏掉的样子

快速验证

为整个服务器分配内存

来源

Redis 的过期是截止时间，逐出是容量策略

时间与容量是两个独立维度

先确定候选范围，再讨论排序

坏掉的样子

快速验证

延伸阅读

来源

巨型页在分配灵活性与翻译覆盖之间取舍

页大小是一项输入

显式池与透明分配

分别预算容量与位置

坏掉的样子

快速验证

延伸阅读

来源

Linux overcommit 为虚拟内存承诺设定政策

虚拟承诺不同于实际驻留

三种准入政策

严格记账不是 OOM 免疫

坏掉的样子

快速验证

延伸阅读

来源

缺页并不总是意味着存储读取

次缺页不代表没有成本

主缺页描述另一条处理路径

坏掉的样子

快速验证

来源

Redis 内存比率需要结合分配背景判断

把不同测量对象分开

先核实分配器和版本

坏掉的样子

快速验证

延伸阅读

来源

Swap 用回收成本换取驻留空间

分清哪些页面可以移动

坏掉的样子

快速验证

来源

zram 用压缩的方式在内存里挤出交换空间

内存里的压缩块设备

压缩就是这笔交易

适合服务器与低端设备

坏掉的样子

快速验证

延伸阅读

来源

排查 OOM 应先确认分配范围

先看范围，再看评分

理解调整值，不许诺必然存活

坏掉的样子

快速验证

来源