Python进程触发Swap而非OOM Killer，是因为内核优先换出匿名页（如堆内存），尤其当vm.swappiness>0且物理内存未耗尽时；其渐进式内存增长易被判定为“可换出”，导致I/O卡顿而非报错。
为什么Python进程会触发Swap而不是OOM Killer
Linux内核在内存不足时，优先把匿名页（如Python堆内存）换出到Swap，而不是直接杀进程——尤其当vm.swappiness > 0 且物理内存未彻底耗尽时。Python本身不感知Swap，但频繁页换入换出会导致CPU等待I/O，表现为“卡死”而非报错。关键点在于：Python的内存增长是渐进的、碎片化的，容易被内核判定为“可换出”，而malloc分配失败前，Swap早已成为性能瓶颈。
用psutil实时监控RSS并主动限流
不能等MemoryError才反应——那时Swap已深度介入。必须在RSS接近物理内存阈值前干预：
- 用
psutil.Process().memory_info().rss每秒采样，不是靠sys.getsizeof()（它只算对象头，不算引用链） - 设置软上限（如总内存的75%），超过后暂停数据读取、清空缓存、强制
gc.collect(2) - 避免在循环中高频调用
psutil——开销大，建议每100–500次迭代检查一次
import psutil, gc
proc = psutil.Process()
limit_bytes = int(0.75 * psutil.virtual_memory().total)
while data_stream:
chunk = next(data_stream)
process(chunk)
if proc.memory_info().rss > limit_bytes:
gc.collect(2) # 清第2代，扫循环引用
time.sleep(0.1) # 让OS回收页面
禁用Swap或调低swappiness的实操边界
完全禁用Swap（swapoff -a）在生产环境风险高：可能触发OOM Killer杀关键进程。更稳妥的是控制水位：
-
echo 1 | sudo tee /proc/sys/vm/swappiness—— 仅在极端缺内存时换出，日常几乎不触发 - 对单进程临时压测：启动前
sudo prlimit --as=8G python script.py，硬限制虚拟内存，让malloc提前失败 - 容器场景：Docker加
--memory=8g --memory-swap=8g，等于禁用Swap但保留OOM容错
生成器+显式del是防Swap最有效的组合
Swap多由“隐式持有”引发：比如读CSV后存成全局list，或中间结果没释放。生成器本身不解决问题，必须配合显式清理：
立即学习“Python免费学习笔记（深入）”；
- 用
yield产出数据后，立刻del掉上游大对象（如pandas.DataFrame） - 避免闭包捕获大数据：函数内定义的
lambda或嵌套函数若引用了大数组，该数组生命周期会延长 - 处理完一块数据后，调用
del big_obj+gc.collect()，不要依赖自动回收
真正卡住Swap的，往往不是峰值内存，而是“不该驻留却一直驻留”的那部分——比如日志缓存、未清理的__dict__引用、或threading.local()里堆积的线程局部变量。
