Jupyter Notebook运行数小时自动停止 单元格显示[ ]而非[*]无报错

• 长耗时（6-7小时）单元格运行过程中无人工干预自动中止
• 原本显示[*]的运行中未完成单元格，异常后回到无编号的[ ]待执行状态
• 全程无主动停止操作、无键鼠交互、前端页面无任何报错提示

• 内核被系统OOM机制杀掉：这是无报错长任务中断的最高发原因。如果任务存在内存泄漏、或者计算过程中内存占用超过系统/容器给Jupyter内核分配的阈值，系统会直接向内核进程发送SIGKILL信号强制终止，这个层级的终止不会触发Python的异常捕获逻辑，前端拿不到报错信息，只会因为内核断连把单元格状态重置为待运行。
• 环境自动回收机制误杀：如果是跑在远程服务器、Docker容器、JupyterHub、云厂商托管Notebook上的任务，多数环境默认配置了空闲进程/空闲实例回收规则，部分配置有缺陷的回收逻辑会把“长时间无前端输出的运行中任务”误判为空闲，直接回收内核甚至关停实例。
• 本地系统休眠/电源策略中断：本地启动Notebook时，Windows/macOS默认电源计划会在一段时间无键鼠操作后自动进入睡眠/休眠状态，系统挂起时会终止所有运行中的用户进程，唤醒后前端和内核断连，不会留存运行报错。
• 浏览器后台进程回收：如果Notebook页面长时间放在后台，Chrome、Edge等Chromium内核浏览器开启内存节省模式后，会自动冻结甚至回收后台标签页的进程，导致前端和Jupyter服务端的websocket连接断开，触发运行中断。
• 原生扩展导致内核崩溃：代码里调用的numpy、pandas、PyTorch等带C/C++编译逻辑的第三方库如果触发段错误、非法内存访问，会直接让整个Python内核进程崩溃退出，这类崩溃发生在Python解释器层之外，前端不会显示常规的Python报错栈。

• 第一步先定位根因，优先查日志
  • 如果你是在本地终端敲jupyter notebook启动的服务，直接翻终端里任务中止时间点附近的输出，出现Killed字样基本就是OOM，出现segmentation fault就是底层库触发的内核崩溃，出现Kernel disconnected就是前端连接断了。
  • 远程/云环境直接看实例监控，查异常时间点的内存使用率曲线，如果内存瞬间打满后直接掉到0，可直接确认是OOM；Linux环境可执行dmesg -T | grep -i oom查看系统OOM杀进程的记录。
  • 本地Windows环境去事件查看器翻系统日志，看异常时间点有没有进程被强制终止、系统进入休眠的记录。
• OOM问题针对性修复
  • 用memory_profiler工具逐行统计代码内存占用，排查循环里不断往全局变量追加数据、大对象用完不释放这类内存泄漏问题。
  • 大数据计算改成分块加载、分批处理，不要一次性把全量数据集读进内存；硬件内存不足时可临时加swap分区兜底，长期还是建议优化代码逻辑或者升级内存。
• 自动回收/休眠问题针对性修复
  • 本地运行先改系统电源计划，关闭自动休眠、自动睡眠、硬盘自动断电的选项；浏览器关闭后台标签页内存节省功能，把Notebook标签页加入白名单始终保持活动。
  • 远程/JupyterHub环境修改Notebook配置，编辑jupyter_notebook_config.py文件，设置c.MappingKernelManager.cull_idle_timeout = 0关闭空闲内核自动回收；给长任务加定时进度打印（比如每10分钟输出一次当前计算进度），避免被回收机制误判为空闲。
• 内核崩溃问题针对性修复
  • 日志显示段错误的话，先把numpy、pandas、PyTorch这类带原生编译逻辑的依赖升级到官方稳定版，不要用来源不明的第三方编译包。
  • 超过2小时的长任务不建议直接在Notebook前端挂着跑，把代码抽成独立py脚本，用nohup python run_task.py > task.log 2>&1 &后台执行，或者用tmux/screen开持久会话跑，完全脱离浏览器前端依赖，跑完再回Notebook做结果分析即可，能避免90%的前端断连导致的中断问题。

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