在 PyCharm 上使用 Optuna 运行研究优化时获得 SIGKILL答案

【问题标题】：Getting SIGKILL when running study optimization with Optuna on PyCharm在 PyCharm 上使用 Optuna 运行研究优化时获得 SIGKILL
【发布时间】：2020-07-29 14:32:10
【问题描述】：

我正在尝试运行一项研究，将优化功能与默认采样器和中值修剪器一起使用。每次运行都会崩溃，有时在 1 次成功试验后有时没有完成。崩溃消息是：进程以退出代码 137 完成（被信号 9 中断：SIGKILL）

预期行为

进行研究

环境

Optuna 版本： 2.0.0
Python 版本：3.8
操作系统：带有 debian 10 虚拟机的 QubeOS
（可选）其他库及其版本： Pytorch '1.5.0+cpu'

错误消息、堆栈跟踪或日志

进程以退出代码 137 结束（被信号 9：SIGKILL 中断）

是什么导致了这样的错误？

【问题讨论】：

如何执行命令？对我来说，这似乎是 C 库上的错误（异常，例如访问无效内存），这会导致内核终止进程，因此无需打印 python 异常堆栈。或者它也可能是python中的一个错误，或者只是硬件问题（内存过热也是已知的原因）

标签： python pycharm pytorch optuna

【解决方案1】：

一种可能的情况是您的进程消耗了大量内存并被操作系统的 OOM 杀手杀死。您可以使用top 之类的工具监控进程的内存消耗，看看它是否使用了大量内存。

您还可以在控制台中运行dmesg 并在输出中查找来自OOM 杀手的消息。 OOM 杀手通常会在那里打印它杀死的进程。检查进程 ID 是否是您的进程之一。

如果进程确实被 OOM 杀手杀死，那么唯一的补救措施可能是减少程序的内存消耗（或获得更大的机器）。

【讨论】：

感谢您的评论！我实际上做到了，内存消耗是合理的〜50％..我现在一无所知。在查看 dmesg 时，它确实显示了 OOM kill process...，为什么顶部没有显示此内存峰值？
这可能是程序在某些时候尝试了一个非常大的分配，这就是导致 OOM 杀手发挥作用的原因。另一种选择是通过 gdb 之类的调试器运行您的程序，然后查看何时程序获得 SIGKILL。还有一个名为 mtrace 的工具（请参阅man mtrace），它可以在 C 级别跟踪内存分配。我不是这个OOM杀手业务的专家。您可能需要阅读此内容。一个好的开始是 Linux 手册页中malloc 的 NOTES 部分

【解决方案2】：

你可以放心使用

gc_after_trial=True

有 study.optimize(timeout=300) 但我没能让它工作如果您在 HyperbandPruner 中使用 tpesampler，还可以设置超时和 n_trial 限制。最后，对我有用的是较低的 n_jobs（我设置为 -1，并且倾向于将我的所有核心都飙升到 100%，最后只是崩溃）。

【讨论】：