第一百篇 白话操作系统内存管理与调度：大数据工程师必须懂的那些“底层内功”
今天我们以停车场、餐厅后厨和银行柜台为引子，拆解了虚拟内存、页表、页面置换和进程调度这些 OS 基石。更重要的是，把它们映射到了天天接触的 Spark、YARN 上，让你在遇到时，能穿透日志看到本质。动手扩展：用vmstat和sar -B观察你线上集群的缺页和换页情况，然后回去调整看溢写指标变化，评论区告诉我你的发现！如果你在实战中遇到调度或内存的坑，也欢迎交流，我们一起把“底层内功”练扎实。
“Spark 又 OOM 了？”“YARN Container 被 kill 得莫名其妙？”“明明内存够为什么疯狂写磁盘？”
这些问题看似是大数据框架的锅，根源却在今天我们要聊的两个老朋友——内存管理与调度。
本文不堆 OS 教科书，而是带你从工程落地的视角，把操作系统里那些看着“虚”的概念，一把拽进你的spark-submit里。
目录
为什么大数据开发者要学 OS 内存管理和调度
做大数据的人常有一种错觉：我写个 df.groupBy().agg()，底层都是 Spark、Flink 在管，我关心操作系统干嘛？
直到某一天——
- 场景一：你给 Executor 分配了 8G 堆内存，跑着跑着 YARN 直接杀 Container，日志写着
Exit code 143，物理内存超限。可 JVM 不是只用了堆么？ - 场景二：Shuffle 阶段大量
Spill to disk，监控上看磁盘 IO 打满，CPU 却在发呆。明明内存还剩一截，为什么非要写磁盘？ - 场景三：任务多了以后，所有 Job 都在抢资源，调度延迟忽高忽低，简单聚合半天调度不上。
这些坑，本质上都是操作系统内存管理和调度策略在分布式框架里的“投胎转世”。
当你理解了虚拟内存、页面置换、OOM Killer、时间片调度，再去调 spark.memory.fraction、memory.offHeap.size、YARN 调度器，就像给裸机装上了仪表盘——看得清，控得住。
本文约定：用“银行 + 停车场 + 餐厅后厨”三件套比喻贯穿，让你看完就能给同事讲明白为什么 Spark 会 OOM。
核心概念拆解
咱们先把操作系统里最让人头疼的几个词翻译成人话。
1. 虚拟内存
- 一句话直白解释：每个进程都以为自己独享一整块超大内存，其实是 OS 在背后玩“拼图游戏”。
- 生活例子：你去银行办了一张无限额信用卡，每次消费都以为卡里有无穷额度。实际上银行后台实时把你的消费映射到真实账户、活期、定期甚至理财里拆借。进程就是那个持卡人，操作系统是银行后台。
- 开发实例：在 Spark 里，JVM 的堆内存就是虚拟内存中的一个区域，
Xmx只限制堆的上限，但 JVM 除了堆还会用 Metaspace、线程栈、直接内存，这些东西加起来才对应 OS 的真实物理分配。所以 YARN 容器 OOM 往往不是因为堆满了，而是堆外内存把物理内存吃爆了。
2. 分页与页框
- 一句话直白解释：把虚拟内存和物理内存都切成固定大小的块，虚拟的叫“页”，物理的叫“页框”，映射起来方便管理。
- 生活例子：停车场把所有车位画成标准 2.5m×5m 的格子，不管来的是摩托还是 SUV，都按格子分配，这就是“页框”。你手里的停车券上写的“A区 3号”是虚拟地址，实际车停哪个位子是物理地址。
- 开发实例：Linux 默认页大小 4KB，Spark 在堆外内存里分配
MemoryBlock时，底层也是跟 OS 申请连续物理页框。如果页太小，页表条目爆炸，TLB 命中率下降，性能就下来了。
3. 页表 & TLB
- 一句话直白解释：页表是“虚拟页号→物理页框号”的对照表；TLB 是这个对照表的快速缓存，存在 CPU 里。
- 生活例子：页表是电话黄页，TLB 是通讯录置顶常用联系人。查黄页得翻半天，查置顶联系人瞬间拨号。
- 开发实例：大数据进程频繁随机访问内存（如 HashAggregate 的哈希表探测），TLB miss 过多会导致 CPU 停顿等内存翻译。这就是为什么有人建议 Spark 开启
Transparent Huge Pages使用 2MB 大页，从而减少 TLB 条目数。
4. 页面置换算法
- 一句话直白解释：物理内存满了又要加载新页，就必须挑一个“倒霉”的老页踢出去，这个挑选策略就是页面置换算法。
- 生活例子：餐厅后厨只有 10 个灶台（物理页框），菜单上 100 道菜（虚拟页）。来一道新菜，必须端走一个已经做好的菜腾地方。LRU 就是把最久没被客人点的菜端走。
- 开发实例：Spark 的
StorageMemory和ExecutionMemory互相借用时，会淘汰缓存 RDD 的 Block，淘汰策略本质就是一种“类 LRU”。
5. 进程调度
- 一句话直白解释：CPU 只有一个或几个核，几十个进程排队等执行，OS 决定现在让谁跑、跑多久。
- 生活例子：银行柜台一天接待 200 个客户，柜员采用叫号时间片轮转，每个人服务 5 分钟，没办完就重新排队；VIP 客户可以抢占插队（优先级调度）。
- 开发实例：YARN 的 Capacity/Fair Scheduler 就是分布式版的进程调度：队列（Queue）对应优先级，Container 分配对应 CPU 时间片，抢占机制对应优先级调度。
原理深度解析
下面我们用虚拟地址翻译和页面置换+调度联动两条主线，把 OS 的决策逻辑和大数据框架的实现串起来。
虚拟地址翻译：从 Spark 一条数据说起
假设 Spark 在执行 groupBy key 的哈希聚合，一个 Long 类型的 key 读进了堆外内存的 MemoryBlock。CPU 要访问它时，给出的是一个 64 位虚拟地址。翻译流程如下：
- 虚拟地址拆成虚拟页号 VPN 和页内偏移。
- CPU 先查 TLB：
- 命中 → 直接得到物理页框号，加上偏移，完事。
- 未命中 → 去查页表（多级页表，在内存里）。
- 如果页表里发现该页不在物理内存（缺页中断），OS 找个空闲页框，没有就页面置换，从磁盘换入数据。
- 更新页表和 TLB。
为什么大数据框架关心这个？
因为一条 groupBy 要访问亿级 key 的哈希表，工作集远大于 TLB 能覆盖的范围（通常 64 条目覆盖 4KB×64=256KB）。TLB miss 率极高，导致每条 key 的处理都伴随多次内存访问。启用透明大页后，单页 2MB，同样数量条目可覆盖 128MB，大幅降低 miss。
工程陷阱 ①：透明大页不是银弹。THP 启用后，OS 会后台尝试合并小页成大页，这个过程本身消耗 CPU 并可能造成内存碎片。很多大数据平台推荐
echo never > /sys/kernel/mm/transparent_hugepage/enabled，改用显式大页（Hugetlbfs）分配。
页面置换算法对比
| 算法 | 策略 | 优点 | 缺点 | 大数据影子 |
|---|---|---|---|---|
| FIFO | 先入先出 | 实现简单 | Belady 异常，老常驻页被无故踢出 | Spark 早期 BlockManager 简单 FIFO 淘汰会丢热数据 |
| LRU | 踢走最久未使用的页 | 贴合局部性原理 | 实现成本高，需要硬件支持或链表 | 现代 Spark 用改进 LRU 管理缓存 RDD |
| Clock (NRU) | 循环扫描，给页一次“改过”机会 | 性能接近 LRU，开销低 | 对扫描型负载可能误伤 | Linux 内核默认用类似 Clock 的算法 |
| LFU | 踢使用频率最低的 | 适合热点保护 | 历史高频页不再访问仍占据内存 | 近似于 Spark 中 RDD 被多次引用则不淘汰 |
餐厅比喻：
- FIFO：按上菜顺序，最先上的菜端走。
- LRU：哪个菜最久没被客人碰，端走它。
- Clock：服务员循环走，每看到一盘菜问“刚才有人动过吗？”，有人动过就给一次免死金牌，没动就端走。
- LFU：统计每个菜被点次数，最低的端走。
调度器如何影响大数据任务
进程调度决定了 CPU 时间的分配。Linux 的 CFS（完全公平调度）保证所有进程公平获得 CPU 时间，并通过 vruntime 衡量。当大数据场景中 Executor 是多线程模型，一个 Executor 容器内部有大量 task 线程，实际上这些线程被 CFS 调度，任务计算密集时，会发生频繁的抢占和上下文切换。
可以执行
vmstat 1观察cs列，即每秒上下文切换次数。如果数万甚至十万以上，说明调度开销巨大，可能导致 CPUsy系统态占比飙升，真正干活的us占比反而低。这就是你任务变慢的隐形杀手。
对比分布式资源调度器：
| 维度 | OS 进程调度 | YARN/Fair Scheduler |
|---|---|---|
| 调度对象 | 线程/进程 | Container/App |
| 时间片 | CPU 时间片 | 资源量 (内存+CPU) 的容量份额 |
| 抢占策略 | 优先级+CFS 带宽控制 | 队列最小份额抢占 |
| 饥饿预防 | vruntime 保证 | 最小资源保证 + 抢占超发 |
你在 YARN 上看到队列的资源使用率忽高忽低，本质和 CPU 利用率曲线是一个道理。
实战：用代码复刻内存管理和调度
光说不练假把式。下面我们用 Python 写一个简单的虚拟内存页面置换模拟器，模拟 FIFO、LRU、Clock 三种算法，再结合一个迷你任务调度器来感受决策过程。
你可以直接拷贝运行，观察不同算法在同样访存序列下的缺页次数。
实战 1：页面置换算法模拟器
# page_replacement_sim.py
# 模拟页大小为 4KB，进程访问 20 个逻辑页号序列
# 物理页框仅 4 个，记录缺页中断次数
def simulate(access_sequence, frames, algorithm="FIFO"):
"""
access_sequence: list of page numbers (logical pages)
frames: int, 物理页框数
algorithm: "FIFO", "LRU", "Clock"
返回缺页次数
"""
page_faults = 0
memory = [] # 当前在物理内存的页
# 用于 Clock 算法的引用位和指针
ref_bits = {}
clock_hand = 0
for page in access_sequence:
if page in memory:
# 命中，LRU 和 Clock 需要更新信息
if algorithm == "LRU":
# 将该页移到最近使用位置（放到末尾）
memory.remove(page)
memory.append(page)
elif algorithm == "Clock":
ref_bits[page] = 1
else:
page_faults += 1
if len(memory) < frames:
# 还有空闲页框
memory.append(page)
if algorithm == "Clock":
ref_bits[page] = 1
else:
# 需要淘汰
if algorithm == "FIFO":
evicted = memory.pop(0)
elif algorithm == "LRU":
evicted = memory.pop(0) # 最久未使用在队头
elif algorithm == "Clock":
# 循环扫描，找引用位为 0 的页
while True:
victim = memory[clock_hand]
if ref_bits.get(victim, 0) == 0:
evicted = victim
memory[clock_hand] = page # 替换该位置
ref_bits[page] = 1
if evicted in ref_bits:
del ref_bits[evicted]
clock_hand = (clock_hand + 1) % frames
break
else:
# 给一次机会，清引用位
ref_bits[victim] = 0
clock_hand = (clock_hand + 1) % frames
# 注意此时 memory 已更新，不需再 append
continue # 避免重复添加
# FIFO/LRU 淘汰后要添加新页
if algorithm != "Clock":
memory.append(page)
if algorithm == "LRU":
pass # 已在队尾
if algorithm == "Clock":
pass # Clock 已在循环中更新 memory
return page_faults
if __name__ == "__main__":
# 模拟访存序列：程序先后访问这些逻辑页
# 这里模拟一个大小超过缓存的工作集，比如对 6 个 key 反复哈希聚合
seq = [1,2,3,4,1,2,5,1,2,3,4,5,6,1,2,3,4,5,6,6] # 长度20
frames = 4
for algo in ["FIFO", "LRU", "Clock"]:
faults = simulate(seq, frames, algo)
print(f"算法 {algo}: 缺页次数={faults}, 命中率={(len(seq)-faults)/len(seq):.2%}")
# 思考：当 frames 增大到 5 会发生什么？试试 Belady 异常
print("\n===== Belady 异常测试（FIFO 下增加页框可能增加缺页）=====")
for f in [3,4,5]:
print(f"frames={f}, FIFO缺页={simulate(seq, f, 'FIFO')}")
运行效果（示例）：
算法 FIFO: 缺页次数=13, 命中率=35.00%
算法 LRU: 缺页次数=12, 命中率=40.00%
算法 Clock: 缺页次数=11, 命中率=45.00%
===== Belady 异常测试 =====
frames=3, FIFO缺页=14
frames=4, FIFO缺页=13
frames=5, FIFO缺页=14 ← 页框多了反而缺页上升！
你会发现，FIFO 在特定序列下会出现 Belady 异常。这个现象在大数据里也有映射：盲目增加 Shuffle 内存，如果缓存淘汰策略设计不佳，可能导致更多磁盘溢写。
实战 2：迷你任务调度器 —— 体验时间片与饥饿
用 Python 模拟三个队列（实时、批处理、后台），加权公平调度。观察任务完成时间。
# scheduler_sim.py
import heapq
from collections import deque
class Task:
def __init__(self, name, priority, burst_time):
self.name = name
self.priority = priority # 越小越高优
self.burst_time = burst_time
self.remaining_time = burst_time
def weighted_fair_scheduling(tasks, time_slice=10, weights={1:5, 2:3, 3:1}):
"""
简单加权公平调度：按优先级分配时间片比例。
weights: priority -> 权重
返回每个任务的周转时间
"""
time = 0
queue = deque(tasks) # 按到达顺序排列，假设同时到达
finish_time = {}
while queue:
task = queue.popleft()
# 分配时间片 = 基础时间片 * (权重/总权重) 简化：直接按权重给时间
weight = weights.get(task.priority, 1)
real_slice = time_slice * weight / sum(weights.values())
exec_time = min(task.remaining_time, real_slice)
time += exec_time
task.remaining_time -= exec_time
if task.remaining_time > 0:
queue.append(task) # 回队尾
else:
finish_time[task.name] = time
print(f"任务 {task.name} 完成于时刻 {time:.2f}")
return finish_time
if __name__ == "__main__":
tasks = [
Task("实时计算", 1, 30),
Task("批处理ETL", 2, 50),
Task("后台归档", 3, 80),
]
ft = weighted_fair_scheduling(tasks)
print("周转时间:", ft)
延展思考：如果把后台归档的权重调成和实时计算一样，会发生什么？你会立刻看到实时任务被拖慢——这就是为什么要给 YARN 队列设置不同权重和抢占策略。
高级用法与避坑指南
1. 大数据内存调优的“OS 映射”
大数据框架的内存配置必须对齐 OS 层面的限制：
- 物理内存硬上限：
yarn.nodemanager.resource.memory-mb不能超过节点实际物理内存，预留部分给 OS 和守护进程。 - 虚拟内存比率：YARN 默认
yarn.nodemanager.vmem-pmem-ratio=2.1，如果 JVM 堆外+线程栈等导致虚拟内存超出，会直接杀容器。曾经踩过坑：一个 Executor 开了 2000 个线程，每个线程栈默认 1MB，光线程栈就 2GB 虚拟内存，瞬间被杀。 - 透明大页陷阱：如前所述，很多大数据发行版建议关闭 THP，使用
echo never或配置thp_swappiness。
2. Shuffle 磁盘溢写与页面抖动
当 Shuffle 数据量超过 spark.memory.fraction 中 Execution 内存时，Spark 必须将数据溢写到磁盘，这就相当于操作系统发生“缺页”时换出到交换区。如果溢写过于频繁，就和系统“颠簸”（thrashing）一样，CPU 全花在 I/O 上。
调优手法：
- 增大
spark.memory.offHeap.size，让排序/聚合直接在堆外进行，减少 GC 和溢写。 - 调整
spark.sql.shuffle.partitions，让每个分区的数据量适中，避免单分区内存撑爆。
工程陷阱 ②：过度依赖堆外内存会绕过 JVM 的 GC 管理，但堆外内存分配释放代价高，且如果程序泄漏堆外内存，OS 物理内存会一直不释放，最终导致节点僵死。务必搭配
-XX:MaxDirectMemorySize限制。
3. 调度延迟与 CPU 窃取
在 Spark on YARN 中，如果开启了 Cgroup 严格 CPU 限制，每个 Container 只能使用限定核数。但 JVM 内部 GC 线程、编译线程等会争抢这些 CPU 时间，相当于多个进程抢一个柜台的“时间片”。如果 CPU 限制过死（如 yarn.nodemanager.resource.cpu-vcores 设得太小），会导致 GC 停顿变长，任务执行时间雪崩。
建议：为每个 Executor 分配至少 2~3 个 vcore，给 GC 和后台线程留足喘息空间。
学习建议与进阶资源
- 书籍：《现代操作系统》（Tanenbaum）讲透底层，《深入理解计算机系统》（CSAPP）的虚拟内存章节必读。
- 源码：Linux 内核
mm/memory.c缺页中断处理，mm/page_alloc.c伙伴分配器。Spark 的MemoryManager.scala、UnifiedMemoryManager是极好的工程借鉴。 - 动手实验：在测试机用
stress -m 1 --vm-bytes 2G触发 OOM，观察dmesg中 OOM Killer 的决策日志，理解系统如何选择杀进程。
互动习题
习题 1：LRU 缓存在高并发下如何优化？
上文模拟的 LRU 是单线程链表实现，如果每次访问都要移动元素，并发下加全局锁性能极差。请思考至少两种优化方案，并描述其优缺点。（参见解析）
习题 2：为什么 Spark 增加 Executor 内存后，Shuffle 溢写没减少反而频繁 Full GC？
结合页面置换的“Belady 异常”和 JVM 堆管理特性给出分析。（参见解析）
总结与扩展
今天我们以停车场、餐厅后厨和银行柜台为引子，拆解了虚拟内存、页表、页面置换和进程调度这些 OS 基石。更重要的是，把它们映射到了天天接触的 Spark、YARN 上，让你在遇到 Shuffle Spill、Container OOM 时，能穿透日志看到本质。
动手扩展：用 vmstat 和 sar -B 观察你线上集群的缺页和换页情况，然后回去调整 spark.memory.fraction 看溢写指标变化，评论区告诉我你的发现！
如果你在实战中遇到调度或内存的坑，也欢迎交流，我们一起把“底层内功”练扎实。
习题解析
习题 1 解析：
- 方案 A：分段锁（Striped Lock）——将缓存分成多个段，每段各自维护一个 LRU 链表，通过 key 的 hash 决定进哪个段。ConcurrentHashMap 早期版本就类似设计。优点是减少锁竞争，缺点是可能不够公平，某些段热点。
- 方案 B：使用
ConcurrentLinkedHashMap或者Caffeine这种基于Window TinyLFU的现代缓存库，它们通过异步任务批量处理淘汰，避免每次访问都操作链表，并发性能极高，且命中率高于纯 LRU。
习题 2 解析：
增加 Executor 内存后，JVM 堆变大，年轻代也可能随之扩大，导致一次 Minor GC 需要扫描的对象增多，停顿变长。同时，Spark 的 UnifiedMemoryManager 在堆内动态借用时，如果 Storage 和 Execution 争抢，可能引发 RDD 缓存频繁淘汰（类似于 Belady 异常——空间大了但淘汰策略不当反而命中率下降）。此外，大堆意味着 Full GC 时标记清除更慢，如果同时 Shuffle 数据量超过 Execution 内存，依旧会溢写。本质上类似操作系统中物理内存大了但页面置换算法的全局性缺陷暴露。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
7
0- 0
已为社区贡献2条内容
所有评论(0)