程序员对内存的误解：深入Linux内核内存管理，提高SRE系统可靠性

USENIX

总结：

• 程序员对内存管理存在普遍误解，例如malloc和free并非立即分配或释放物理内存。
• Linux内存管理旨在最大化资源利用、确保安全、最小化开销，并对应用程序透明。
• 超额分配、按需分页和虚拟内存是Linux提高内存利用率的关键技术，允许系统仅在需要时分配物理内存。
• 物理RAM并非真正“随机访问”，其DRAM组织结构和CPU缓存机制使得顺序访问性能远优于随机访问。
• RSS（Resident Set Size）是衡量进程内存使用的误导性指标，因为它未能涵盖缓存和缓冲区等对应用性能至关重要的内存类型。
• Linux Cgroup v2通过memory.low和memory.high等文件提供了更全面、更细致的内存资源控制和保护，旨在维护核心服务的稳定性。
• Swap分区并非仅用于紧急情况，而是通过允许回收匿名页和维持轻微的内存压力，来提升系统整体的内存公平性和可靠性。
• senpai工具利用PSI（Pressure Stall Information）动态评估应用程序的真实内存工作集，帮助SREs准确识别内存需求、发现泄漏并优化资源配置。

引言：内存管理的常见误解 [00:00:16]

• Chris Down的背景 [00:00:16]
  • Chris Down是Meta公司的Linux内核工程师，主要从事内核内存管理子系统、资源控制和隔离方面的工作。
  • 他也是systemd项目的维护者，负责cgroups及其他资源控制管理。
  • 其日常工作是提升Linux的可靠性和可扩展性。
• 内存是普遍存在误解的话题 [00:00:44]
  • 内存是SRE和软件工程师工作中被认为理所当然的话题，但其中存在大量误解。
  • 许多人认为自己已经了解内存管理，但实际工作方式和原因往往超出预期。
  • 本演讲旨在更新概念，提供新思路，以帮助SREs在生产环境中构建更可靠的系统。
• 一个简单的C语言malloc/free示例 [00:01:20]
  • 示例代码演示了分配1MB内存、写入字符串并释放内存的C程序。
  • malloc并不立即分配物理内存 [00:01:51]
    • 一个普遍的误解是malloc会立即分配物理内存。
    • 实际上，malloc与实际的内存分配没有任何直接关系，它只是提供了一个“选择”去使用内存。

Linux内存管理的高级目标 [00:02:06]

• 最大限度利用可用内存 [00:02:21]
  • 确保内存不仅可访问，而且应用程序可以通过系统调用和操作系统支持有效利用。
  • 尽可能让所有系统内存被使用，例如通过磁盘缓冲区、文件系统缓存等填充空闲空间。
• 确保内存访问安全 [00:02:52]
  • 防止程序非法访问其他进程的内存。
  • 大部分安全检查由CPU完成，内核根据CPU的错误报告采取行动。
  • CPU的错误报告也可用于提高效率。
• 使用最少资源进行管理 [00:03:18]
  • 内存管理本身不应成为系统瓶颈，即使牺牲一些精确性，也要保证快速执行。
  • Linux内核的内存管理代码为了速度会采用近似算法和权衡。
• 对应用程序透明 [00:03:47]
  • 大多数内存管理活动应在应用程序不知情的情况下透明地进行。
  • 这要求重新思考应用程序如何看待内存，以实现高效管理。

内存超额分配与虚拟内存 [00:04:10]

• 超额分配（Overcommit）机制 [00:04:10]
  • 像信用卡一样，先授予请求，后按需分配 [00:04:15]
    • Linux会乐观地为应用程序分配请求的内存，甚至超出系统实际可用的物理内存总量。
  • 基于按需分页和交换 [00:04:30]
    • 按需分页（Demand Paging）：不预先分配物理内存，只在应用程序实际访问内存时才保留物理内存。
    • 交换（Swapping）：允许将已加载的内存卸载到较慢的存储（如磁盘）。
  • 程序申请的内存大部分未实际使用 [00:04:56]
    • 大量程序申请的内存从未被使用或很少使用，将其常驻物理内存是浪费。
    • 目标是通过解耦内存请求与物理分配，提高系统范围内的内存利用率。
  • 由操作系统而非开发者管理内存 [00:05:26]
    • 历史证明，应用程序开发者管理内存容易出错（如安全漏洞、缓冲区溢出）。
    • 现代语言（如Rust、C++、解释型语言）提供更抽象的内存访问，降低了开发者直接管理内存的复杂性。
    • 虽然超额分配有风险（如果所有程序都实际使用其分配的内存，系统将崩溃），但可以通过内核和用户空间机制缓解。
• 虚拟内存的工作原理 [00:06:33]

  

  • 虚拟内存是内核和CPU共同实现的多层内存抽象。
  • 每个进程拥有独立的虚拟地址空间（VMA） [00:06:52]
    • 对程序来说，虚拟地址空间就像普通内存，但它只是一种映射，不包含实际内存。
  • 虚拟地址不一定由RAM支持，可由Swap支持 [00:07:11]
    • 虚拟内存地址可以由RAM、Swap甚至未映射（如按需分页）支持。
    • 访问Swap支持的内存时，需要将其提升到主内存。
• 页错误（Page Fault）与按需分页 [00:07:59]
  • CPU向内核发出的内存访问请求 [00:08:11]
    • 当CPU尝试访问一个未映射到物理RAM的虚拟页面时，会产生页错误。
    • 页错误是CPU告诉内核“我不知道这个内存地址是什么”的信息。
  • 内核将虚拟地址映射到物理地址或从磁盘加载数据 [00:09:59]
    • 内核判断页错误是由于非法访问还是页面尚未加载。
    • 如果是有效访问但未加载，内核会分配新的物理页帧，建立映射。
    • 如果需要，还会从后端设备（如Swap）加载数据到内存。
    • 这个过程对应用程序是透明的，应用程序感受不到中断。
  • malloc与实际内存分配的解耦是关键。程序调用malloc只是获得了使用内存的“选择权”，而非立即分配物理内存。

free操作的“谎言”：内存回收的复杂性 [00:11:10]

• free并不立即释放物理内存 [00:11:22]
  • 与malloc类似，free也并非如程序员想象的那样立即将内存返回给操作系统。
  • 执行简单的“分配1MB，填充，释放，然后等待”的C程序后，RSS（Resident Set Size，常驻内存集）可能不会如预期降至零。
• 三种可能的free结果 [00:11:41]
  1. 内存保持不变（分配器放入空闲列表） [00:11:50]
     • 分配器（如Google的TC Malloc）将内存放入内部空闲列表，以便快速重用，不返回给操作系统。
     • 这导致程序认为内存已释放，但内核仍认为它被占用。
  2. RSS部分下降（分配器返还部分页面给OS） [00:12:30]
     • 分配器（如glibc或jemalloc）可能将部分页面返回给操作系统，但保留一部分以备将来使用。
  3. RSS反而增加（分配器进行内部维护操作） [00:12:52]
     • free操作本身可能需要分配内部元数据或重组内存池，导致短暂的内存使用量增加。
     • 在生产环境中，这可能发生在解决内存碎片或对齐等复杂场景中。
• free只是给分配器的信号，不是给操作系统的信号 [00:13:33]
  • free只是告诉内存分配器“我不再需要这块内存了”，而不是“请立即将其返回给操作系统”。
  • 分配器根据其内部策略决定如何处理这块内存。
  • 这解释了为什么在生产环境中监控内存泄漏如此困难，因为即使程序正确调用free，内存也可能不被实际释放。
  • RSS作为衡量指标，在现代系统中变得非常不可靠。

随机访问内存并非“随机”：DRAM与缓存 [00:14:21]

• 为什么顺序访问比随机访问快50倍 [00:15:27]
  • 尽管“随机访问内存”（RAM）这个名字，但它在随机访问方面表现不佳。
  • 一个二维数组的遍历示例显示，行优先（顺序）遍历比列优先（随机）遍历快50倍。
• DRAM的RAS/CAS/PRE操作周期 [00:15:56]
  • DRAM（动态随机存取存储器）按行组织，其操作受RAS/CAS/PRE周期控制：
    • RAS (Row Address Strobe) [00:16:07]：激活DRAM中的特定行。
    • CAS (Column Address Strobe) [00:16:15]：在已激活的行中选择特定列来存取数据。
    • PRE (Precharge) [00:16:24]：对行进行预充电，准备访问不同的行。
  • 关键：单次激活行可执行多次列操作 [00:16:49]
    • RAS和PRE操作非常耗时，而CAS操作相对快速。
    • 顺序访问允许在一次RAS后进行多次CAS操作，从而减少RAS/PRE的开销，显著提高性能。
• 缓存（Cache）利用率 [00:17:52]
  • 缓存行（Cache Line）是最小数据传输单位 [00:17:55]
    • CPU和内存之间的数据传输以缓存行为单位（通常为64字节）。
    • 随机访问可能导致每次只使用缓存行中的一小部分数据，然后整个缓存行被丢弃，造成带宽浪费。
    • 顺序访问能充分利用整个缓存行，提高效率。
• TLB（Translation Lookaside Buffer） [00:18:21]
  • 虚拟到物理地址的转换缓存 [00:18:31]
    • TLB缓存了虚拟地址到物理地址的转换，容量有限。
    • 随机访问会频繁导致TLB未命中，需要重新查找页表，增加开销。
    • 顺序访问可以保持相关转换常驻TLB，减少未命中。
• SIMD（Single Instruction Multiple Data）矢量化 [00:18:58]
  • 现代编译器会自动对顺序访问进行矢量化优化，使用SIMD指令集让CPU单条指令处理多个数据元素。
  • 尽管SIMD有帮助，但DRAM的物理架构（RAS/CAS/PRE）对性能提升的贡献更为巨大。
  • 编写代码时，应牢记RAM和CPU在本质上并不擅长随机访问。

Linux内存类型与RSS的误导性 [00:19:56]

• Linux区分多种内存类型 [00:19:59]
  • 从CPU角度看，内存类型差异不大，但Linux在语义上区分不同类型的页面：
    • 匿名内存（Anonymous memory） [00:20:11]：不依赖任何后端存储，通常由malloc分配。
    • 缓存和缓冲区（Caches and Buffers） [00:20:22]：文件系统缓存、磁盘缓冲区等，现在通常统一为统一页面缓存（unified page cache）。
  • "可回收"不等于立即回收 [00:20:36]
    • 许多管理员认为页面缓存和缓冲区是“可回收”的，意味着可以随时释放。
    • 然而，“可回收”仅表示在特定条件下（例如系统轻微压力下）可能被回收，并不意味着在紧急情况下会立即释放。
    • 例如，如果应用程序频繁访问某个文件，该文件对应的缓存页面不太可能被随意释放。
• RSS（Resident Set Size）是糟糕的衡量指标 [00:21:27]
  • RSS只关注匿名内存和映射文件内存 [00:21:39]
    • RSS是广泛使用的内存指标，但它过于关注匿名内存和映射文件内存，忽略了缓存和缓冲区等同样重要的内存类型。
  • 许多工作负载无法缺少缓存和缓冲区 [00:21:48]
    • 许多复杂的应用程序和工作负载（如Chrome的代码段）的运行离不开大量的缓冲区和缓存。
    • 这些缓存并非“可选”内存，而是执行程序所必需的。
  • Facebook的例子：应用实际内存用量远超RSS显示 [00:22:11]
    • Facebook曾有一个团队，多年来一直认为他们的服务内存占用为100-150MB，但通过更准确的度量发现，实际每台机器占用高达2GB。
    • 这凸显了RSS的误导性，以及仅限制RSS会导致应用程序突破系统资源限制。
    • 因此，现代资源控制通常会统一限制所有类型的内存。

Cgroups v2：更全面的内存资源控制 [00:22:41]

• Cgroups作为内核机制 [00:22:43]
  • Cgroups（Control Groups）是Linux内核提供的一种机制，用于平衡和控制机器上的共享资源，如内存、CPU、IO。
  • 它们是用户定义的进程组，具有一组资源限制。
  • 容器运行时（Docker, Kubernetes等）底层使用Cgroups [00:23:07]
    • 所有现代容器运行时，如Docker、CoreOS、Kubernetes、SystemD Nspawn等，都使用Cgroups作为底层资源隔离技术。
    • Cgroups解决了传统Unix内存管理（如ulimits）的许多长期存在的问题和局限性。
  • Cgroup v2作为新一代控制组系统，在内存管理方面有显著改进。
• Cgroup v2统一内存限制 [00:23:52]
  • 在Cgroup v2中，memory.max文件用于限制cgroup可以使用的最大内存量。
  • memory.max文件限制所有内存类型（缓存、缓冲区、socket内存、内核内存等） [00:23:58]
    • 这与旧的按进程限制或Cgroup v1的限制方式不同，后者通常只限制内存类型的子集。
    • 这种统一限制能够更有效地防止滥用系统范围的资源。
• 内存限制的挑战 [00:24:26]
  • 虽然memory.max直接有效，但如何用它来构建可靠的系统是一个挑战。
  • 设置过多细粒度限制导致系统难以理解和管理 [00:25:17]
    • 管理员倾向于对每个应用程序设置内存限制，以防止内存泄漏或oom（Out Of Memory）崩溃。
    • 例如，对“best-effort”服务（如配置管理、指标收集）和“workload”服务（核心业务应用）分别设置限制，会形成复杂的层级。
    • 在大型公司（如Facebook、Google），成千上万的服务和开发团队之间的协调使得内存限制的设置变得极其困难。
• memory.low：内存保护 [00:26:50]
  • memory.low是对Unix内存控制方式的根本性改变。
  • 设定最低内存保障，避免被过度回收 [00:27:07]
    • 它不是设定上限，而是设定一个保护线：只要cgroup的内存使用量低于memory.low，通常就不会被回收内存。
    • 这意味着在系统内存紧张时，内核会优先从其他cgroup（未受保护的或超出保护线的cgroup）回收内存。
  • 比硬性限制更具工作效率（work-conserving） [00:28:22]
    • memory.low不是内存预留。它不会预先从其他cgroup那里“拿走”内存。
    • 只要不影响其他cgroup，受保护的cgroup可以使用超出memory.low的内存。
    • 只有当受保护的应用程序需要使用它时，才会真正动用这些内存。
  • 能够更好地应对内存使用量的临时波动 [00:28:47]
    • 这使得系统对内存使用量的临时峰值和变化具有更强的容忍度。
    • Meta公司已主要依赖memory.low和memory.min进行内存保护，减少了对硬性memory.max的依赖。

Swap分区的真正价值 [00:29:08]

• Swap并非紧急内存 [00:29:56]
  • 许多人认为Swap是当物理内存不足时的“紧急内存”或“备用RAM”，这是一种误解，甚至可能是有害的。
  • 现代系统拥有大量内存，因此很多人认为Swap已不重要。然而，Swap和物理内存并非可互换的概念。
• 避免Swap不代表避免磁盘IO [00:30:10]
  • 无Swap时，操作系统会回收文件缓存，同样导致磁盘IO [00:30:26]
    • 如果系统没有Swap，当物理内存不足时，操作系统无法回收匿名页（只能通过Swap），就会转而频繁回收文件缓存。
    • 这会导致对文件缓存的访问也变成磁盘IO，甚至可能因为可回收页面池变小而变得更糟。
  • 关于Swap的误解导致其声誉受损，认为在内存充足时无用。
• Swap的核心作用 [00:30:49]
  • 允许回收匿名内存，增加可回收内存类型 [00:30:49]
    • Swap提供了一个后端存储，使得那些原本在RAM中“锁定”的匿名页变得可回收。
  • 平缓内存竞争的上升曲线，避免系统突然停滞 [00:30:58]
    • 有了Swap，内存竞争可以更平缓地增加，而不是突然从“最佳利用”变成“完全死锁”。
    • 这防止了内存耗尽时系统迅速进入无法挽回的僵局。
  • 维持“正向压力”，确保系统充分利用所有内存 [00:31:35]
    • 就像make -j+1（编译时使用比CPU核心数多1的并行度），Swap通过维持轻微的内存正向压力，促使操作系统优化内存使用，确保所有内存资源都被充分利用。
    • 这能在不显著影响系统延迟的情况下，实现内存的最有效利用。
    • 没有Swap，内存竞争的增加会非常迅速且难以管理，系统一旦超出临界点就会陷入“回收页面循环”，无法有效向前推进。

准确测量进程内存使用：PSI与senpai [00:32:20]

• 传统工具（top, free）的局限性 [00:32:39]
  • 主要显示RSS，忽视缓存等非可选内存 [00:32:51]
    • top等工具主要显示RSS（或PSS），它们不了解进程正在使用的缓存。
    • 对于许多复杂的应用程序，缓存并非可选，而是维持其运行的关键。
  • Chrome二进制文件案例说明缓存的重要性 [00:33:14]
    • Chrome的二进制代码段超过130MB，这些代码在执行时必须加载到内存（作为页面缓存），并非随时可回收。
    • 忽略这部分内存会导致对应用程序真实内存需求的严重低估。
• Cgroup v2的memory.current [00:33:48]
  • memory.current文件测量cgroup当前的内存使用量，包括缓存、缓冲区、socket内存等所有类型。
  • 包含所有内存类型，但测量值会充满“填充”数据 [00:34:07]
    • memory.current提供了更全面的内存真相，但这个真相有时复杂难懂。
  • 在无内存压力时，memory.current会增长至cgroup上限 [00:35:14]
    • 如果没有全局内存压力，应用程序会消耗其cgroup限制内的所有可用内存，包括被操作系统填充的缓冲区和缓存，使得memory.current显示的值可能远高于应用程序实际运行所需的最小内存。
• memory.high与性能的关系 [00:35:54]
  • memory.high是Cgroup v2中的一个可调参数，它会在cgroup内存使用超过阈值时触发内存回收，直到使用量回到阈值之下。
  • 通过逐步降低memory.high并观察应用程序性能（例如内核编译时间），可以找到一个性能开始显著下降的内存使用拐点。
  • 例如，一个内核编译过程在无限制时消耗约800MB内存，耗时约4分钟。
    • 设置为600MB限制时，性能几乎不变，内存减少25%。
    • 设置为400MB限制时，性能略有下降（多3秒），内存减少50%。
    • 设置为300MB时，任务无法完成。
  • 这表明该进程需要300-400MB内存才能合理运行。但这种试错方法耗时且不适用于Web服务器等非均匀工作负载。
• senpai工具与PSI (Pressure Stall Information) [00:36:45]
  • senpai是一个利用Cgroup v2的PSI（Pressure Stall Information）系统来找出应用程序实际所需内存的工具。
  • PSI是内核开发的新技术，用于判断特定资源（如内存）是否过度订阅。
  • PSI衡量线程在内存操作上等待的时间 [00:37:19]
    • PSI指标衡量系统线程因内存相关操作而停滞的时间比例（例如，等待内核内存锁、被节流、等待回收完成、内存相关IO）。
    • 它本质上表示“如果我有更多内存，我可以运行得更快”。
  • senpai通过memory.high结合PSI动态调整内存限制 [00:38:00]
    • senpai利用PSI作为反馈机制，动态地对cgroup施加足够的内存压力（通过memory.high），以回收对工作负载性能非必需的“冷”页面。
    • 它是一个积分控制器，能动态适应内存使用量的峰值和低谷。
  • 提供应用程序随时间变化的内存工作集概况 [00:38:19]
    • senpai通过不断调低应用程序的内存限制，直到检测到性能问题（PSI压力增加），然后适度回退，从而得到一个准确的内存工作集大小。
    • 例如，它发现内核编译需要大约340MB内存。
• senpai的价值 [00:38:40]
  • 提升可观察性，发现隐藏的内存泄漏和回归 [00:38:45]
    • 帮助团队发现之前低估的内存使用量（如Facebook的2GB案例）。
    • 它能以RSS无法做到的方式，发现内存泄漏和性能退化。
  • 提前缓解内存短缺，优化工作负载堆叠 [00:39:05]
    • 在系统资源充足时进行内存压力测试，避免在机器已高度竞争时才处理内存短缺问题。
    • senpai是Meta工作负载堆叠（workload stacking）的关键部分，它提供准确的工作负载内存需求，并允许随着时间推移调整堆叠限制。

总结 [00:39:36]

• 一个简单的程序背后蕴含的复杂内存管理 [00:39:36]
  • 即使是最初那个简单的C语言malloc/free程序，也涉及页错误、缓存、缓冲区、库slab等众多复杂机制。
  • 理解这些机制对于分析和调试生产环境中的复杂服务至关重要。
• 理解这些复杂性对设计和调试服务的意义 [00:40:08]
  • 掌握这些工具和技术，可以帮助SREs和开发者更好地理解内存管理带来的复杂性，从而设计和调试更可靠的服务和应用程序。