如何避免Python进程因内存不足被OS/K8s终止

我太懂这种被OOM Killer突然搞崩的痛苦了——明明写了MemoryError捕获逻辑，结果进程直接被kill -9抬走，连日志都来不及打，更别说优雅处理任务了。结合你们用Pub/Sub任务队列+大模型缓存的场景，分享几个亲测有效的设计思路：

OOM Killer是系统级的最后手段，我们得抢在它动手前先察觉。可以用psutil库实时监控进程内存，设置一个合理的阈值（比如Pod内存限制的80%），一旦触发就主动停止接收新任务，把当前任务处理完（或者标记为失败后放回队列），然后优雅退出。这样既不会被硬杀，还能保留上下文，避免消息丢失。

• 具体操作：在进程启动后开一个后台线程，每隔1-5秒用psutil.Process().memory_info().rss获取当前内存占用，和预设阈值对比。
• 踩过的坑：阈值别设太满（比如别设到95%），给系统留够缓冲空间；退出前一定要向Pub/Sub发送确认（或者拒绝），不然消息会被重复分发。

如果单个任务内存占用太高，直接拆成多个小分片处理，每个分片只加载必要的数据，处理完就释放内存。比如处理大文本时，别一次性把整个文件读进内存，而是按行或按块流式读取；处理模型推理时，把大批量请求拆成小批量，每处理完一批就清理张量缓存。

• 适配Pub/Sub：把分片任务的元数据（比如总片数、当前片序号、任务唯一ID）放在消息属性里，处理完最后一片再标记整个任务完成；如果某一片失败，只需要重跑这一片，不用整个任务重来。

既然不想每个任务开单独进程（浪费模型加载时间），可以试试这两种方案：

• 线程级监控+限流：给每个任务线程设置内存监控，一旦超过阈值就强制终止线程（注意线程安全），但这种方式在Python里因为GIL的存在，内存隔离效果有限；
• 复用模型的进程池：用multiprocessing.Pool创建固定大小的进程池，每个子进程加载一次模型，然后循环处理多个任务；给每个子进程设置内存阈值，一旦超过就重启该子进程（重启时重新加载模型，虽然有开销，但比整个Pod被杀好太多）。
• 结合Pub/Sub：任务分发时，根据进程池的负载（每个进程当前处理的任务数、内存占用）动态分配任务，避免某一个进程被压爆。

模型加载开销大，那我们要最大化缓存利用率，同时主动回收闲置内存：

• 任务处理完后，主动调用gc.collect()触发垃圾回收；对于TensorFlow/PyTorch模型，还要调用model.zero_grad()（PyTorch）或者tf.keras.backend.clear_session()（TensorFlow）清理显存/内存；
• 给缓存的模型设置LRU（最近最少使用）策略，当内存不足时自动卸载最久未使用的模型，等需要时再重新加载（虽然有加载开销，但总比OOM被杀导致整个服务中断强）。

你们提到重启时处理重复消息效率低，那得做好消息幂等+快速恢复：

• 给每个消息分配唯一ID，进程本地维护一个处理中的任务ID集合（同时存内存+本地磁盘/Redis），重启时先加载这个集合，标记这些任务为待重试，避免重复处理；同时在Pub/Sub端设置消息的TTL（存活时间），防止旧消息一直被重复分发；
• 断点续传：每个任务处理到关键节点时，把进度保存到外部存储（比如Redis/数据库），重启时可以从断点继续处理，不用从头再来。

最后给K8s Pod做一些配置，让系统尽量不杀你的任务进程：

• 在Pod YAML里设置resources.limits.memory和resources.requests.memory，并且设置terminationGracePeriodSeconds给进程留足够的优雅退出时间；
• 给你的任务进程设置低OOM分数：启动时执行echo -1000 > /proc/self/oom_score_adj，让系统优先杀其他辅助进程（比如日志收集进程），而不是你的任务进程。

内容的提问来源于stack exchange，提问作者Sander