如何调试垂死的 Jupyter Python3 内核？
How to debug dying Jupyter Python3 kernel?
我在使用 Python 3 内核的 Jupyter 笔记本上 运行 使用 scipy 和 scikits.learn 的一些代码。在计算期间，内核将重新启动，并显示一条消息对话框，提示“内核似乎已死亡。它将自动重新启动。”。底层 Jupyter 进程的 stderr 只记录内核死掉并且将在没有任何有用消息的情况下重新启动的事实。
有没有办法检查潜在的错误？这可能是来自某些 C++ 代码的段错误，但我只能猜测。我在服务器上搜索了任何相关日志，但没有找到任何有用的信息。
在机器学习项目中，在 8 GB RAM 笔记本电脑中读取近 5000 张图像作为 numpy 数组时遇到了完全相同的问题。在对我的图像分辨率、相应 numpy 数组的大小进行了一些计算之后，我认为 8 GB 的 RAM 不足以处理图像。
在网上进行大量研究后，其中涉及更新 CUDA、cuDNN、降级 TensorFlow（他们在导入相关 modules/packages 时遇到相同错误）等建议，将 numpy 更新到最新版本并更新 intel Math Kernel 版本（命令："conda install -c intel mkl"）（一整天的研究）。
对我有用的解决方案是 运行 Google colab 上的模型训练过程。
现在，回到你的问题：
显示的对话：“内核似乎已经死了。它会自动重启。”本身不是 "error"。通过清除所有变量并重新启动内核，它更像是 "Jupyter Notebook helping itself"。它是 Jupyter Notebook 发送 SOS 信号，并从自身获得帮助，这样它就不会崩溃。否则会导致重新启动的 Jupyter Notebook 没有未保存的更改。 （好吧，它会自动保存，但不会 "auto checkpoint"）
Jupyter Notebook 的 "response" 仅仅是因为达到了笔记本电脑的最大 RAM 容量。 - 这是 "underlying error"（响应）。这将释放资源，使您能够重新启动程序。
还记得当你打开太多 chrome 的标签时你的电脑挂了吗？或者 运行 一个程序有太多的变量值要存储（比如我的 5000 张图像）？这可能是 Jupyter Notebook 在 RAM 容量被充分利用时的替代响应。绞刑。或崩溃。
但是，开发人员非常友善，让它能够自我照顾。
注意1：运行与.py脚本相同的代码，错误会更详细。
注意 2：如果您正在使用 CUDA，请记住即使会话终止，Jupyter Notebook 也无法释放 CUDA 资源。所以这可能是它重新启动的原因。
添加到确认解释列表（第 2 点）：
- 需要太多内存
- 堆栈溢出 - 递归步骤太多
在我的例子中，当我 运行 它作为 Python 脚本时，我得到了这个：
Fatal Python error: Cannot recover from stack overflow.
...
Aborted (core dumped)
我在使用 Python 3 内核的 Jupyter 笔记本上 运行 使用 scipy 和 scikits.learn 的一些代码。在计算期间，内核将重新启动，并显示一条消息对话框，提示“内核似乎已死亡。它将自动重新启动。”。底层 Jupyter 进程的 stderr 只记录内核死掉并且将在没有任何有用消息的情况下重新启动的事实。 有没有办法检查潜在的错误？这可能是来自某些 C++ 代码的段错误，但我只能猜测。我在服务器上搜索了任何相关日志，但没有找到任何有用的信息。
在机器学习项目中，在 8 GB RAM 笔记本电脑中读取近 5000 张图像作为 numpy 数组时遇到了完全相同的问题。在对我的图像分辨率、相应 numpy 数组的大小进行了一些计算之后，我认为 8 GB 的 RAM 不足以处理图像。 在网上进行大量研究后，其中涉及更新 CUDA、cuDNN、降级 TensorFlow（他们在导入相关 modules/packages 时遇到相同错误）等建议，将 numpy 更新到最新版本并更新 intel Math Kernel 版本（命令："conda install -c intel mkl"）（一整天的研究）。 对我有用的解决方案是 运行 Google colab 上的模型训练过程。
现在，回到你的问题： 显示的对话：“内核似乎已经死了。它会自动重启。”本身不是 "error"。通过清除所有变量并重新启动内核，它更像是 "Jupyter Notebook helping itself"。它是 Jupyter Notebook 发送 SOS 信号，并从自身获得帮助，这样它就不会崩溃。否则会导致重新启动的 Jupyter Notebook 没有未保存的更改。 （好吧，它会自动保存，但不会 "auto checkpoint"）
Jupyter Notebook 的 "response" 仅仅是因为达到了笔记本电脑的最大 RAM 容量。 - 这是 "underlying error"（响应）。这将释放资源，使您能够重新启动程序。 还记得当你打开太多 chrome 的标签时你的电脑挂了吗？或者 运行 一个程序有太多的变量值要存储（比如我的 5000 张图像）？这可能是 Jupyter Notebook 在 RAM 容量被充分利用时的替代响应。绞刑。或崩溃。
但是，开发人员非常友善，让它能够自我照顾。
注意1：运行与.py脚本相同的代码，错误会更详细。
注意 2：如果您正在使用 CUDA，请记住即使会话终止，Jupyter Notebook 也无法释放 CUDA 资源。所以这可能是它重新启动的原因。
添加到确认解释列表（第 2 点）：
- 需要太多内存
- 堆栈溢出 - 递归步骤太多
在我的例子中，当我 运行 它作为 Python 脚本时，我得到了这个：
Fatal Python error: Cannot recover from stack overflow. ... Aborted (core dumped)