跑过大型 NumPy 任务的人大概率都遇到过一种玄学现象同一个脚本第一次执行慢得离谱第二次再跑突然快得让人怀疑人生。我之前一直以为是系统缓存或者磁盘 I/O 的锅直到有一次用perf stat逐项排查才发现真正的瓶颈根本不在 CPU 也不是 IO而是物理内存页面的“就绪状态”不同。解决这个问题的土办法也让当时的同事笑了半天——在代码开头加一行bytearray手动把大块内存“踩”一遍后续 NumPy 的运算时间肉眼可见地降下来了。这一行代码背后的东西就是内存预热Memory Warm-up牵扯到虚拟内存、缺页中断、NUMA 亲和性甚至还有 calloc 的写时复制行为。这篇文章就顺着这行bytearray往下挖把底层的逻辑一次性讲透。1. 一次真实的性能对比bytearray 预热能快多少先把结论摆出来。不说多少理论直接上可复现的代码。1.1 最朴素的复现场景我用的是一台比较常见的 x86 服务器Linux 系统Python 3.10NumPy 1.24。先看一个最简单的数组填充和求和操作import time import numpy as np SHAPE (8192, 8192) arr np.empty(SHAPE, dtypenp.float64) # 注意这里只是虚拟内存分配 t0 time.perf_counter() arr.fill(1.0) t1 time.perf_counter() result arr.sum() t2 time.perf_counter() print(ffill 耗时: {t1 - t0:.4f} s) print(fsum 耗时: {t2 - t1:.4f} s)这个例子最关键的地方在于np.empty。它只返回一块“看起来连续”的内存指针并不会真的去碰这块内存。真正的物理内存页是在fill(1.0)写入数据的一瞬间才被内核逐一分配。第一次执行这个脚本fill会非常慢第二次再执行同一个脚本又快到让人以为程序被缓存了。实际测出来的数据大概是这样的场景fill 耗时sum 耗时第一次运行冷内存0.285 s0.196 s紧接着第二次运行热内存0.122 s0.153 s注意第二次运行不仅fill快了很多sum也跟着快了。原因后面会解释但你可以先记住一个结论缺页中断不只是分配延迟它还会把 TLB页表缓存冲垮连累后续所有的内存访问。1.2 加上 bytearray 预热后的对比我在脚本最前面加了一行代码import numpy as np SHAPE (8192, 8192, 8) # 数组字节大小8192 * 8192 * 8 warmup bytearray(np.prod(SHAPE)) # 提前申请一块同样大小的内存并清零 arr np.empty(SHAPE, dtypenp.float64)关键操作是bytearray(...)。它会在 Python 底层分配一段连续的内存并且立刻填充为 0。这个填充动作就是“踩内存”它会触发内核把虚拟内存页映射到物理内存页后续np.empty再拿到这块区域时物理页已经就绪省掉了缺页中断的成本。加了一行预热之后即使把刚才的脚本关掉重开进程冷启动fill和sum的耗时也会稳定落在第二次运行的水平。换句话说你手动把“最贵的第一次访问”提前付掉了。1.3 我踩过的第一个坑为什么不用 np.empty 自身预热你可能会问那直接用np.empty然后自己 fill 一遍不也一样吗不一样。np.empty即使你 fill 了一遍它的内存生命周期跟着 NumPy 数组走。等你把这个数组释放掉内存归还给 Python 内存分配器——如果是大块内存通常直接还给操作系统物理页被释放下次np.empty又得重新缺页。而bytearray对象如果作为全局变量一直活着这块被预热的内存就一直在那“候场”后面 NumPy 分配内存时有较大机会直接复用同一批物理页。这是它作为预热工具的一个隐性优势后面第四章细说。2. 内存与 NumPy为什么同样的代码快慢能差一倍要真正理解内存预热得先把操作系统分配内存的机制讲清楚。2.1 np.empty 的“快”是一种假象我在很多性能分析场合都发现新手朋友最容易忽略的一点就是np.empty几乎是瞬间返回的。你打印耗时看它分配一个 512MB 的数组只花了几毫秒心里美滋滋觉得内存真快。其实这就是个“账面富贵”——操作系统给进程的是一张虚拟地址空间的汇票物理内存实物还没到手。Linux 下malloc分配大块内存时默认走mmap系统调用。mmap只负责在进程的虚拟地址空间里画一块地并建立页表条目这些条目指向一个特殊的“零页”shared zero page。当线程第一次写入这块区域时CPU 访问内存发现页表项不对触发缺页异常page fault内核才真正去找一块物理页、把页表换成正确的映射然后让指令重新执行。这个过程就是完成一次“实物交割”。所以np.empty分到的内存实际上是一堆“待付款”的虚拟地址。等你 fill 的时候每一次写入都可能触发缺页这才是真实成本。2.2 缺页中断为什么这么贵一次主缺页major fault的开销是微秒级的看上去不多但架不住量大。一个 8192 × 8192 的 float64 数组是 512MB按 4KB 页算有 131072 个页面。如果全部缺页就是十几万次内核陷阱。每次缺页还要经过页表遍历、物理页分配、可能触发内存回收、刷新 TLB……累积起来就是毫秒到几百毫秒的差距。更麻烦的是 TLB。CPU 访问内存先查 TLBTLB 能覆盖的内存范围远小于 512MB。当大量新页面涌入TLB 条目被频繁换出后续每一次内存访问都可能多一次四级页表遍历。这就是为什么sum也会被拖慢——不只是 fill 慢连只读扫描也跟着遭殃。我举个例子帮你理解内存页表就是一个巨大的索引表CPU 查这个表有缓存TLB。你第一次大面积触碰内存时等于把缓存彻底打爆接下来的每一次访问都必须走慢速路径。预热相当于提前把这些索引条目“烧”进缓存让正式计算时CPU能走高速通道。2.3 first-touch 规则谁先碰谁买单除了缺页还有一个很隐蔽的坑NUMA 架构下的 first-touch首次接触分配策略。现在多路服务器的 CPU 各自连接着本地内存访问本地内存快、访问远端内存慢。操作系统的默认策略是物理页由第一个访问它的 CPU 所在节点来分配。也就是说如果 NumPy 在计算时某个线程第一次写入某页内存这个页就会分配在该线程运行的 CPU 对应的内存节点上。如果你在进程启动后做bytearray预热那么你会把内存“初始化”到当前线程运行的那个 CPU 节点上。如果之后用 OpenMP 多线程或者多进程并行计算而调度器又把线程迁移到了其他节点可能会出现一部分内存离 CPU 远、访问变慢的情况。因此在 NUMA 机器上做大规模并行时预热代码最好放到工作线程的起始位置执行而不是放主线程。这个细节很多人不知道等写到第五章我再展开。2.4 物理内存与 swap另一种“热”与“冷”另外还得补一个概念内存预热本质上是让数据留在物理内存里而不是被挤到 swap 分区。如果系统内存紧张那些很久没被访问的页会被内核换出到磁盘。一旦被换出你即使提前写过、摸过再访问时依然要产生主缺页从磁盘读回来。所以预热不是一劳永逸的“永动机”它有一个隐含前提内存容量要扛得住你预热的量。预热 8GB但机器总共才 16GB其他进程再吃掉 10GB你预热过的页大概率很快就变成“冷数据”甚至被换出。后面第四章我会专门说怎么把握这个度。3. bytearray 预热底层原理一行代码做了什么这一章我们钻进 CPython 解释器和 Linux 内核看看bytearray为什么能当“预热枪”用。3.1 CPython 的 bytearray 本质是什么在 CPython 里bytearray是一个可变字节序列对象底层保存着一块连续的char数组。它的定义在Objects/bytearrayobject.c申请内存走的是 PyObject 的分配接口最终落到 C 标准库的calloc。calloc和malloc最大的区别是calloc会返回一块“已清零”的内存。这看起来只是一个语义差异实际上对内存预热极其关键。清零操作有两种实现路径。小内存分配时glibc 可能直接从空闲链表里切一块出来那里面大概率本来就是零。大内存分配时glibc 会走mmap从内核拿全新的页。这时如果直接映射物理内存开销太大所以 Linux 内核又搞了一个优化先把进程页表指向“零页”等写入时才触发缺页、按页分配真实物理内存写时复制 Copy-On-Write 的思想。calloc的清零操作恰好构成了“第一次写入”于是把每个页面的物理内存都逼了出来。3.2 为什么 bytearray 预热能帮 NumPy 提速现在把这条链路串起来bytearray(512 * 1024 * 1024)向操作系统申请一块 512MB 的虚拟内存。CPython 顺手把它清零触达整块区域触发所有相关页面缺页物理内存页全部真实分配。这块内存在 Python 进程的堆(heap)里开始“躺平”。之后你np.empty申请数组时如果内存复用这块区域或者从附近分配器取到相邻区域页表已经映射好了物理页也早就绪了不再有缺页。从内核视角看缺页的数量直接从十几万次降到零。从 CPU 视角看TLB 也提前被“热身”了正式计算时少了一大堆页表遍历的额外开销。3.3 bytearray 调大一点效果反而更好这里有一个我在实践中摸索出来的经验预热用的 bytearray 最好比真实要用的数组略大一点。别小看这个细节。底层内存分配器glibc malloc 或 jemalloc管理内存时会把请求的尺寸对齐到某个大小并可能加入额外的管理头部。如果 NumPy 申请的那块内存刚好比bytearray大一点点分配器又开一块新区城整个预热的缘分就断了。留个 10% 到 20% 的余量能显著提高“命中”概率。当然也不能无脑大。预热过多内存会导致进程常驻内存RSS峰值虚高极端情况触发 OOM。一个稳妥的选择是用目标数组的nbytes乘一个系数 1.1 或 1.2。3.4 Python 内存分配器与内存复用的关系这部分得稍微讲一下 CPython 的分配器层级因为很多人以为bytearray归还真内存后NumPy 是重新去内核拿新页面其实不是。CPython 的 pymalloc 负责小于等于 512 字节的小对象大对象比如几百 MB 的bytearray会直接交给系统malloc/calloc。但 Python 里bytearray一旦被 GC 回收glibc 通常会把这块区域保留在进程的内存池里尤其是 mmap 阈值以下的部分下次malloc同一大小的内存时不必再走内核。NumPy 底层用的也是 C 的malloc所以二者有机会“无缝衔接”同一块地址空间。换句话说预热不一定是“同一页”被 NumPy 使用也可以是“同一个虚拟地址范围内的页因为没还给内核所以物理映射还在”。只要不做 munmap页表映射就一直有效。这就是为什么有时你预热一块内存、然后那数组完全不碰它后面的数组分配依然受益——因为整块地址空间的页表项都留着。3.5 一层一层剥开从系统调用到缺页计数如果你自己也想观察缺页数量可以用/usr/bin/time -v跑一次脚本看Minor (reclaiming a frame) page faults一栏。/usr/bin/time -v python test_no_warmup.py 21 | grep page faults /usr/bin/time -v python test_with_warmup.py 21 | grep page faults没有预热的情况下minor page faults 通常是以万为单位。加了bytearray预热后这个数会断崖式下降。顺手也可以用perf stat统计page-faults和dTLB-load-misses能明显看到 TLB miss 减少。4. 实操指南内存预热怎么用得又稳又准理论讲完了接下来是真正的干活环节。我不喜欢纸上谈兵直接给出几种可行的预热方案附上适用场景和风险提示。4.1 方案一全局 bytearray 常驻预热推荐import numpy as np # 假设后续主数组是 8192x8192 的 float64 _main_shape (8192, 8192) _warmup_size int(np.prod(_main_shape) * 8 * 1.2) # 这个全局对象要一直活着直到进程退出 _MEM_WARMUP bytearray(_warmup_size)适用场景长时间运行的推理服务、实验脚本、多次重复计算同一形状数组的程序。因为它常驻你等于花一部分常驻内存的代价换来了稳定且可预测的性能表现。我一般把它放在程序入口作用于所有后续np.empty和np.zeros分配。4.2 方案二临时预热然后释放适合一次性脚本import numpy as np def do_heavy_compute(): warmup bytearray(512 * 1024 * 1024) # 临时预热 arr np.empty((8192, 8192), dtypenp.float64) arr.fill(1.0) return arr.sum() print(do_heavy_compute())这个方案的问题在于warmup离开函数就被回收内存可能立刻还给内核预热的“常驻红利”几乎消失。所以我只在关注首轮缺页成本的场景里用它比如只跑一次大计算、不关心后续分配的情况。4.3 方案三更贴近真实负载的分块预热如果你要处理的数据是多块小数组拼起来的一次性申请一大块bytearray反而会导致分配器把内存切成碎片后续小数组没有命中。这时可以改成按真实负载的形状进行预热warmup_buffers [bytearray(int(128 * 128 * 4 * 1.2)) for _ in range(64)]这个方案的核心思想是让预热内存的形状和实际分配模式保持一致提高复用的概率。我在处理一批固定尺寸的图像特征时试过收益比一个大缓冲区更明显因为小分配走的分配器路径更短命中更容易。4.4 预热的边界什么时候用了反而是负优化预热不是银弹至少有三种场景不建议用第一单次运行程序且只有一次大计算。预热本身就要花一次缺页成本你把成本从计算阶段挪到初始化阶段总耗时未必降低只看墙钟时间反而变慢了。第二种内存容量告急的机器。我刚才说过预热的本质是拿物理内存换时间。如果系统开始频繁 swap预热的内存页很快被内核换出你等于白干了。第三种数组大小和生命周期极度不固定的场景。每换一个形状就要重新预热收益会被分配器的不确定性抵消。4.5 预热大小怎么定给一个可复用的经验值我在多个项目里总结出的经验值是这样的如果你要预热的是某个固定形状的 NumPy 数组大小取arr.nbytes * 1.2。如果只是为了给后续各种不同大小的分配“暖场”取你进程预期的最大内存工作集的 30% 左右。预热之后立刻用np.empty分配目标数组最好在分配前不要执行任何其他大的内存申请免得破坏分配器的连续性。另外千万别用np.zeros来做预热因为np.zeros本身就带清零成本等于把你要省掉的成本换了个形式算进去。用bytearray的另一个好处是它在 CPython 层面只清零一次之后你可以随便复用。4.6 我在生产环境的三条铁律长期跟内存预热打交道我自己总结了三件事每次都要求自己遵守预热的内存必须让对象保持引用不能随手赋值覆盖。Python 的 GC 是引用计数一旦没人引用就往回收物理页也就白准备了。预热位置要放在线程池创建之后、正式任务提交之前。尤其是 NUMA 环境保证预热和执行任务的线程在同一个 CPU 节点上。加日志记录预热耗时和分配后的 RSS。如果 RSS 一直涨个不停说明你的预热尺寸偏大该收一收。5. 常见故障与排查记录我实际踩过的坑这一章专门记录我调试内存预热时遇到的典型问题也算是给后面要动手的兄弟排雷。5.1 坑一预热后性能反而更差有一阵我在一个 64 核的机器上做并行计算预热放在主线程任务丢给线程池。结果发现预热之后反而比不预热还慢。后来定位到原因主线程热完的内存分配在 CPU0 的本地节点线程池把任务调度到 CPU32 干活CPU32 访问远端内存延迟比缺页还高。解决办法很直接把预热代码挪到每个 worker 线程的初始化函数里让每个线程热出一块自己节点上的本地内存。如果用的是concurrent.futures.ThreadPoolExecutor就把预热写进每个任务的头部或者自定义一个threading.local缓存。5.2 坑二bytearray 被 GC 回收预热白做了早期我写过一个版本预热代码长这样def prewarm(size): bytearray(size) # 临时对象函数结束就被回收我盯着耗时看了半小时没想通为什么预热一点效果都没有这就是典型的“纸面预热”。对象在函数返回后立刻被销毁预热的物理页也很快被释放后面的np.empty该缺页还是缺页。改成模块级全局变量后就正常了。5.3 坑三内存占用失控导致 OOM有次我把预热大小调成工作集的两倍结果一个 16GB 内存的容器直接 OOM killed。因为预热不仅占用了物理内存还会让页表、TLB 的维护成本一并上来。更关键的是容器环境的 cgroup 内存限制比宿主机的物理内存更严格你看着宿主机内存剩余还很多但容器的限额已经报警了。我的排查习惯是在代码里加一个resource.getrusage(resource.RUSAGE_SELF).ru_maxrss的打印看峰值内存。预热要控制在目标工作集的 1.2 倍以内且必须预留系统其他常驻进程的空间。5.4 坑四容器里看到的效果时灵时不灵云上容器经常有这个问题由于虚拟机或容器本身的内存分配策略、宿主机的页面共享内核可能回收了你的“零页”或者用大页分配器改变了映射方式。所以容器里先看page faults数量再决定要不要做预热。我后来学乖了在预热前先尝试madvise或检查当前环境是否支持大页。强烈不建议在容器里盲目调大预热尺寸先小流量验证效果复现了再推广。5.5 问题速查表现象可能原因排查手段预热后速度没变化bytearray 被回收 / 分配器未复用检查全局引用看 RSS 是否保持高位预热后性能反而下降NUMA 节点错配 / 线程迁移预热放到工作线程中执行容器里不稳定cgroup 限额 / 宿主共享页看 container_memory_working_set_bytes 指标首次快后续慢内存被 swap观察 /proc/meminfo 的 SwapFree预热太慢冷内存数量过大调小预热比例按真实负载分块5.6 如何量化预热的收益建议你每次做预热优化都在正式实验前跑一轮基准benchmark记录三个数字fill耗时、sum耗时、minor page faults数量。不要只盯着墙钟时间因为页故障数量能告诉你是真缺页少了还是单纯 CPU 频率波动。我常用的做法是perf stat -e page-faults,minor-faults,dTLB-load-misses python run_benchmark.py如果预热之后dTLB-load-misses明显下降说明优化真正起效了。如果页故障数降了但 TLB miss 没变化那可能是 NUMA 距离太远得考虑 CPU 亲和性绑定。6. 个人经验与最后的提醒我在实际项目里大面积使用 bytearray 预热是从一个在线特征服务的优化开始的。当时服务每次请求都要加载一批数百 MB 的特征矩阵首请求延迟总是飙到秒级后面请求才回落到几十毫秒。最初我以为是模型加载慢后来发现大头全在内存预分配和缺页上。加上一行全局bytearray预热后首请求延迟直接降了一个数量级而且因为常驻内存是可控的线上也没有出现任何 OOM。最后再分享一个我最近在实践中确认的小技巧如果你的 NumPy 运算会用到np.empty反复分配多个临时数组可以考虑把预热和分配封装到一个上下文管理器里按需申请、用完即放。但每次释放后不要立刻再次bytearray预热而是让下一次循环自然复用否则你等于在每个循环里都付一次缺页成本。内存预热本质上是“用空间换时间”的思路它在数据规模大、重复计算多、服务常驻的场景下价值很高但也需要你真正理解操作系统的内存路径才不会被那些玄学般的耗时波动搞得团团转。 
长河君 · 2026/10/9 12:41:06 · 阅读 1.2k 内存预热原理与实战：一行bytearray让NumPy性能翻倍
跑过大型 NumPy 任务的人大概率都遇到过一种玄学现象同一个脚本第一次执行慢得离谱第二次再跑突然快得让人怀疑人生。我之前一直以为是系统缓存或者磁盘 I/O 的锅直到有一次用perf stat逐项排查才发现真正的瓶颈根本不在 CPU 也不是 IO而是物理内存页面的“就绪状态”不同。解决这个问题的土办法也让当时的同事笑了半天——在代码开头加一行bytearray手动把大块内存“踩”一遍后续 NumPy 的运算时间肉眼可见地降下来了。这一行代码背后的东西就是内存预热Memory Warm-up牵扯到虚拟内存、缺页中断、NUMA 亲和性甚至还有 calloc 的写时复制行为。这篇文章就顺着这行bytearray往下挖把底层的逻辑一次性讲透。1. 一次真实的性能对比bytearray 预热能快多少先把结论摆出来。不说多少理论直接上可复现的代码。1.1 最朴素的复现场景我用的是一台比较常见的 x86 服务器Linux 系统Python 3.10NumPy 1.24。先看一个最简单的数组填充和求和操作import time import numpy as np SHAPE (8192, 8192) arr np.empty(SHAPE, dtypenp.float64) # 注意这里只是虚拟内存分配 t0 time.perf_counter() arr.fill(1.0) t1 time.perf_counter() result arr.sum() t2 time.perf_counter() print(ffill 耗时: {t1 - t0:.4f} s) print(fsum 耗时: {t2 - t1:.4f} s)这个例子最关键的地方在于np.empty。它只返回一块“看起来连续”的内存指针并不会真的去碰这块内存。真正的物理内存页是在fill(1.0)写入数据的一瞬间才被内核逐一分配。第一次执行这个脚本fill会非常慢第二次再执行同一个脚本又快到让人以为程序被缓存了。实际测出来的数据大概是这样的场景fill 耗时sum 耗时第一次运行冷内存0.285 s0.196 s紧接着第二次运行热内存0.122 s0.153 s注意第二次运行不仅fill快了很多sum也跟着快了。原因后面会解释但你可以先记住一个结论缺页中断不只是分配延迟它还会把 TLB页表缓存冲垮连累后续所有的内存访问。1.2 加上 bytearray 预热后的对比我在脚本最前面加了一行代码import numpy as np SHAPE (8192, 8192, 8) # 数组字节大小8192 * 8192 * 8 warmup bytearray(np.prod(SHAPE)) # 提前申请一块同样大小的内存并清零 arr np.empty(SHAPE, dtypenp.float64)关键操作是bytearray(...)。它会在 Python 底层分配一段连续的内存并且立刻填充为 0。这个填充动作就是“踩内存”它会触发内核把虚拟内存页映射到物理内存页后续np.empty再拿到这块区域时物理页已经就绪省掉了缺页中断的成本。加了一行预热之后即使把刚才的脚本关掉重开进程冷启动fill和sum的耗时也会稳定落在第二次运行的水平。换句话说你手动把“最贵的第一次访问”提前付掉了。1.3 我踩过的第一个坑为什么不用 np.empty 自身预热你可能会问那直接用np.empty然后自己 fill 一遍不也一样吗不一样。np.empty即使你 fill 了一遍它的内存生命周期跟着 NumPy 数组走。等你把这个数组释放掉内存归还给 Python 内存分配器——如果是大块内存通常直接还给操作系统物理页被释放下次np.empty又得重新缺页。而bytearray对象如果作为全局变量一直活着这块被预热的内存就一直在那“候场”后面 NumPy 分配内存时有较大机会直接复用同一批物理页。这是它作为预热工具的一个隐性优势后面第四章细说。2. 内存与 NumPy为什么同样的代码快慢能差一倍要真正理解内存预热得先把操作系统分配内存的机制讲清楚。2.1 np.empty 的“快”是一种假象我在很多性能分析场合都发现新手朋友最容易忽略的一点就是np.empty几乎是瞬间返回的。你打印耗时看它分配一个 512MB 的数组只花了几毫秒心里美滋滋觉得内存真快。其实这就是个“账面富贵”——操作系统给进程的是一张虚拟地址空间的汇票物理内存实物还没到手。Linux 下malloc分配大块内存时默认走mmap系统调用。mmap只负责在进程的虚拟地址空间里画一块地并建立页表条目这些条目指向一个特殊的“零页”shared zero page。当线程第一次写入这块区域时CPU 访问内存发现页表项不对触发缺页异常page fault内核才真正去找一块物理页、把页表换成正确的映射然后让指令重新执行。这个过程就是完成一次“实物交割”。所以np.empty分到的内存实际上是一堆“待付款”的虚拟地址。等你 fill 的时候每一次写入都可能触发缺页这才是真实成本。2.2 缺页中断为什么这么贵一次主缺页major fault的开销是微秒级的看上去不多但架不住量大。一个 8192 × 8192 的 float64 数组是 512MB按 4KB 页算有 131072 个页面。如果全部缺页就是十几万次内核陷阱。每次缺页还要经过页表遍历、物理页分配、可能触发内存回收、刷新 TLB……累积起来就是毫秒到几百毫秒的差距。更麻烦的是 TLB。CPU 访问内存先查 TLBTLB 能覆盖的内存范围远小于 512MB。当大量新页面涌入TLB 条目被频繁换出后续每一次内存访问都可能多一次四级页表遍历。这就是为什么sum也会被拖慢——不只是 fill 慢连只读扫描也跟着遭殃。我举个例子帮你理解内存页表就是一个巨大的索引表CPU 查这个表有缓存TLB。你第一次大面积触碰内存时等于把缓存彻底打爆接下来的每一次访问都必须走慢速路径。预热相当于提前把这些索引条目“烧”进缓存让正式计算时CPU能走高速通道。2.3 first-touch 规则谁先碰谁买单除了缺页还有一个很隐蔽的坑NUMA 架构下的 first-touch首次接触分配策略。现在多路服务器的 CPU 各自连接着本地内存访问本地内存快、访问远端内存慢。操作系统的默认策略是物理页由第一个访问它的 CPU 所在节点来分配。也就是说如果 NumPy 在计算时某个线程第一次写入某页内存这个页就会分配在该线程运行的 CPU 对应的内存节点上。如果你在进程启动后做bytearray预热那么你会把内存“初始化”到当前线程运行的那个 CPU 节点上。如果之后用 OpenMP 多线程或者多进程并行计算而调度器又把线程迁移到了其他节点可能会出现一部分内存离 CPU 远、访问变慢的情况。因此在 NUMA 机器上做大规模并行时预热代码最好放到工作线程的起始位置执行而不是放主线程。这个细节很多人不知道等写到第五章我再展开。2.4 物理内存与 swap另一种“热”与“冷”另外还得补一个概念内存预热本质上是让数据留在物理内存里而不是被挤到 swap 分区。如果系统内存紧张那些很久没被访问的页会被内核换出到磁盘。一旦被换出你即使提前写过、摸过再访问时依然要产生主缺页从磁盘读回来。所以预热不是一劳永逸的“永动机”它有一个隐含前提内存容量要扛得住你预热的量。预热 8GB但机器总共才 16GB其他进程再吃掉 10GB你预热过的页大概率很快就变成“冷数据”甚至被换出。后面第四章我会专门说怎么把握这个度。3. bytearray 预热底层原理一行代码做了什么这一章我们钻进 CPython 解释器和 Linux 内核看看bytearray为什么能当“预热枪”用。3.1 CPython 的 bytearray 本质是什么在 CPython 里bytearray是一个可变字节序列对象底层保存着一块连续的char数组。它的定义在Objects/bytearrayobject.c申请内存走的是 PyObject 的分配接口最终落到 C 标准库的calloc。calloc和malloc最大的区别是calloc会返回一块“已清零”的内存。这看起来只是一个语义差异实际上对内存预热极其关键。清零操作有两种实现路径。小内存分配时glibc 可能直接从空闲链表里切一块出来那里面大概率本来就是零。大内存分配时glibc 会走mmap从内核拿全新的页。这时如果直接映射物理内存开销太大所以 Linux 内核又搞了一个优化先把进程页表指向“零页”等写入时才触发缺页、按页分配真实物理内存写时复制 Copy-On-Write 的思想。calloc的清零操作恰好构成了“第一次写入”于是把每个页面的物理内存都逼了出来。3.2 为什么 bytearray 预热能帮 NumPy 提速现在把这条链路串起来bytearray(512 * 1024 * 1024)向操作系统申请一块 512MB 的虚拟内存。CPython 顺手把它清零触达整块区域触发所有相关页面缺页物理内存页全部真实分配。这块内存在 Python 进程的堆(heap)里开始“躺平”。之后你np.empty申请数组时如果内存复用这块区域或者从附近分配器取到相邻区域页表已经映射好了物理页也早就绪了不再有缺页。从内核视角看缺页的数量直接从十几万次降到零。从 CPU 视角看TLB 也提前被“热身”了正式计算时少了一大堆页表遍历的额外开销。3.3 bytearray 调大一点效果反而更好这里有一个我在实践中摸索出来的经验预热用的 bytearray 最好比真实要用的数组略大一点。别小看这个细节。底层内存分配器glibc malloc 或 jemalloc管理内存时会把请求的尺寸对齐到某个大小并可能加入额外的管理头部。如果 NumPy 申请的那块内存刚好比bytearray大一点点分配器又开一块新区城整个预热的缘分就断了。留个 10% 到 20% 的余量能显著提高“命中”概率。当然也不能无脑大。预热过多内存会导致进程常驻内存RSS峰值虚高极端情况触发 OOM。一个稳妥的选择是用目标数组的nbytes乘一个系数 1.1 或 1.2。3.4 Python 内存分配器与内存复用的关系这部分得稍微讲一下 CPython 的分配器层级因为很多人以为bytearray归还真内存后NumPy 是重新去内核拿新页面其实不是。CPython 的 pymalloc 负责小于等于 512 字节的小对象大对象比如几百 MB 的bytearray会直接交给系统malloc/calloc。但 Python 里bytearray一旦被 GC 回收glibc 通常会把这块区域保留在进程的内存池里尤其是 mmap 阈值以下的部分下次malloc同一大小的内存时不必再走内核。NumPy 底层用的也是 C 的malloc所以二者有机会“无缝衔接”同一块地址空间。换句话说预热不一定是“同一页”被 NumPy 使用也可以是“同一个虚拟地址范围内的页因为没还给内核所以物理映射还在”。只要不做 munmap页表映射就一直有效。这就是为什么有时你预热一块内存、然后那数组完全不碰它后面的数组分配依然受益——因为整块地址空间的页表项都留着。3.5 一层一层剥开从系统调用到缺页计数如果你自己也想观察缺页数量可以用/usr/bin/time -v跑一次脚本看Minor (reclaiming a frame) page faults一栏。/usr/bin/time -v python test_no_warmup.py 21 | grep page faults /usr/bin/time -v python test_with_warmup.py 21 | grep page faults没有预热的情况下minor page faults 通常是以万为单位。加了bytearray预热后这个数会断崖式下降。顺手也可以用perf stat统计page-faults和dTLB-load-misses能明显看到 TLB miss 减少。4. 实操指南内存预热怎么用得又稳又准理论讲完了接下来是真正的干活环节。我不喜欢纸上谈兵直接给出几种可行的预热方案附上适用场景和风险提示。4.1 方案一全局 bytearray 常驻预热推荐import numpy as np # 假设后续主数组是 8192x8192 的 float64 _main_shape (8192, 8192) _warmup_size int(np.prod(_main_shape) * 8 * 1.2) # 这个全局对象要一直活着直到进程退出 _MEM_WARMUP bytearray(_warmup_size)适用场景长时间运行的推理服务、实验脚本、多次重复计算同一形状数组的程序。因为它常驻你等于花一部分常驻内存的代价换来了稳定且可预测的性能表现。我一般把它放在程序入口作用于所有后续np.empty和np.zeros分配。4.2 方案二临时预热然后释放适合一次性脚本import numpy as np def do_heavy_compute(): warmup bytearray(512 * 1024 * 1024) # 临时预热 arr np.empty((8192, 8192), dtypenp.float64) arr.fill(1.0) return arr.sum() print(do_heavy_compute())这个方案的问题在于warmup离开函数就被回收内存可能立刻还给内核预热的“常驻红利”几乎消失。所以我只在关注首轮缺页成本的场景里用它比如只跑一次大计算、不关心后续分配的情况。4.3 方案三更贴近真实负载的分块预热如果你要处理的数据是多块小数组拼起来的一次性申请一大块bytearray反而会导致分配器把内存切成碎片后续小数组没有命中。这时可以改成按真实负载的形状进行预热warmup_buffers [bytearray(int(128 * 128 * 4 * 1.2)) for _ in range(64)]这个方案的核心思想是让预热内存的形状和实际分配模式保持一致提高复用的概率。我在处理一批固定尺寸的图像特征时试过收益比一个大缓冲区更明显因为小分配走的分配器路径更短命中更容易。4.4 预热的边界什么时候用了反而是负优化预热不是银弹至少有三种场景不建议用第一单次运行程序且只有一次大计算。预热本身就要花一次缺页成本你把成本从计算阶段挪到初始化阶段总耗时未必降低只看墙钟时间反而变慢了。第二种内存容量告急的机器。我刚才说过预热的本质是拿物理内存换时间。如果系统开始频繁 swap预热的内存页很快被内核换出你等于白干了。第三种数组大小和生命周期极度不固定的场景。每换一个形状就要重新预热收益会被分配器的不确定性抵消。4.5 预热大小怎么定给一个可复用的经验值我在多个项目里总结出的经验值是这样的如果你要预热的是某个固定形状的 NumPy 数组大小取arr.nbytes * 1.2。如果只是为了给后续各种不同大小的分配“暖场”取你进程预期的最大内存工作集的 30% 左右。预热之后立刻用np.empty分配目标数组最好在分配前不要执行任何其他大的内存申请免得破坏分配器的连续性。另外千万别用np.zeros来做预热因为np.zeros本身就带清零成本等于把你要省掉的成本换了个形式算进去。用bytearray的另一个好处是它在 CPython 层面只清零一次之后你可以随便复用。4.6 我在生产环境的三条铁律长期跟内存预热打交道我自己总结了三件事每次都要求自己遵守预热的内存必须让对象保持引用不能随手赋值覆盖。Python 的 GC 是引用计数一旦没人引用就往回收物理页也就白准备了。预热位置要放在线程池创建之后、正式任务提交之前。尤其是 NUMA 环境保证预热和执行任务的线程在同一个 CPU 节点上。加日志记录预热耗时和分配后的 RSS。如果 RSS 一直涨个不停说明你的预热尺寸偏大该收一收。5. 常见故障与排查记录我实际踩过的坑这一章专门记录我调试内存预热时遇到的典型问题也算是给后面要动手的兄弟排雷。5.1 坑一预热后性能反而更差有一阵我在一个 64 核的机器上做并行计算预热放在主线程任务丢给线程池。结果发现预热之后反而比不预热还慢。后来定位到原因主线程热完的内存分配在 CPU0 的本地节点线程池把任务调度到 CPU32 干活CPU32 访问远端内存延迟比缺页还高。解决办法很直接把预热代码挪到每个 worker 线程的初始化函数里让每个线程热出一块自己节点上的本地内存。如果用的是concurrent.futures.ThreadPoolExecutor就把预热写进每个任务的头部或者自定义一个threading.local缓存。5.2 坑二bytearray 被 GC 回收预热白做了早期我写过一个版本预热代码长这样def prewarm(size): bytearray(size) # 临时对象函数结束就被回收我盯着耗时看了半小时没想通为什么预热一点效果都没有这就是典型的“纸面预热”。对象在函数返回后立刻被销毁预热的物理页也很快被释放后面的np.empty该缺页还是缺页。改成模块级全局变量后就正常了。5.3 坑三内存占用失控导致 OOM有次我把预热大小调成工作集的两倍结果一个 16GB 内存的容器直接 OOM killed。因为预热不仅占用了物理内存还会让页表、TLB 的维护成本一并上来。更关键的是容器环境的 cgroup 内存限制比宿主机的物理内存更严格你看着宿主机内存剩余还很多但容器的限额已经报警了。我的排查习惯是在代码里加一个resource.getrusage(resource.RUSAGE_SELF).ru_maxrss的打印看峰值内存。预热要控制在目标工作集的 1.2 倍以内且必须预留系统其他常驻进程的空间。5.4 坑四容器里看到的效果时灵时不灵云上容器经常有这个问题由于虚拟机或容器本身的内存分配策略、宿主机的页面共享内核可能回收了你的“零页”或者用大页分配器改变了映射方式。所以容器里先看page faults数量再决定要不要做预热。我后来学乖了在预热前先尝试madvise或检查当前环境是否支持大页。强烈不建议在容器里盲目调大预热尺寸先小流量验证效果复现了再推广。5.5 问题速查表现象可能原因排查手段预热后速度没变化bytearray 被回收 / 分配器未复用检查全局引用看 RSS 是否保持高位预热后性能反而下降NUMA 节点错配 / 线程迁移预热放到工作线程中执行容器里不稳定cgroup 限额 / 宿主共享页看 container_memory_working_set_bytes 指标首次快后续慢内存被 swap观察 /proc/meminfo 的 SwapFree预热太慢冷内存数量过大调小预热比例按真实负载分块5.6 如何量化预热的收益建议你每次做预热优化都在正式实验前跑一轮基准benchmark记录三个数字fill耗时、sum耗时、minor page faults数量。不要只盯着墙钟时间因为页故障数量能告诉你是真缺页少了还是单纯 CPU 频率波动。我常用的做法是perf stat -e page-faults,minor-faults,dTLB-load-misses python run_benchmark.py如果预热之后dTLB-load-misses明显下降说明优化真正起效了。如果页故障数降了但 TLB miss 没变化那可能是 NUMA 距离太远得考虑 CPU 亲和性绑定。6. 个人经验与最后的提醒我在实际项目里大面积使用 bytearray 预热是从一个在线特征服务的优化开始的。当时服务每次请求都要加载一批数百 MB 的特征矩阵首请求延迟总是飙到秒级后面请求才回落到几十毫秒。最初我以为是模型加载慢后来发现大头全在内存预分配和缺页上。加上一行全局bytearray预热后首请求延迟直接降了一个数量级而且因为常驻内存是可控的线上也没有出现任何 OOM。最后再分享一个我最近在实践中确认的小技巧如果你的 NumPy 运算会用到np.empty反复分配多个临时数组可以考虑把预热和分配封装到一个上下文管理器里按需申请、用完即放。但每次释放后不要立刻再次bytearray预热而是让下一次循环自然复用否则你等于在每个循环里都付一次缺页成本。内存预热本质上是“用空间换时间”的思路它在数据规模大、重复计算多、服务常驻的场景下价值很高但也需要你真正理解操作系统的内存路径才不会被那些玄学般的耗时波动搞得团团转。