0

我遇到了一个问题，即 R 函数（NbCluster）使 R 崩溃，但在不同运行的不同点使用相同的数据。根据 journalctl 的说法，崩溃都是因为内存问题。例如：

Sep 04 02:00:56 Q35 kernel: [   7608]  1000  7608 11071962 10836497 87408640        0             0 rsession
Sep 04 02:00:56 Q35 kernel: Out of memory: Kill process 7608 (rsession) score 655 or sacrifice child
Sep 04 02:00:56 Q35 kernel: Killed process 7608 (rsession) total-vm:44287848kB, anon-rss:43345988kB, file-rss:0kB, shmem-rss:0kB
Sep 04 02:00:56 Q35 kernel: oom_reaper: reaped process 7608 (rsession), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

我一直在测试我的代码以找出导致内存错误的行，结果发现它会有所不同，即使使用相同的数据也是如此。除了想要解决它之外，我对为什么这是一个间歇性问题感到困惑。如果一个对象太大而无法放入内存，那么每次我在相同资源的情况下运行它时都会出现问题，对吧？

其他进程使用的内存量在运行之间没有显着差异，我总是从干净的环境开始。当我查看时，top我总是有多余的记忆（尽管我很少看到崩溃的确切时刻）。我尝试通过删除不需要的对象和定期垃圾收集来减少内存负载，但这没有明显的效果。

例如，在运行 NbClust 时，有时会在运行时发生崩溃，有时 length(eigen(TT)$value) 会在调用hclust. 有时它不会崩溃并以相对优雅的“无法分配向量大小”退出除了有关减少内存负载的任何建议之外，我想知道为什么我有时会耗尽内存，但有时却没有。

hclust编辑：更改to的所有用途后hclust.vector，在层次聚类步骤中我没有再发生崩溃。但是，仍然在不同的地方发生崩溃（通常在调用 时eigen()）。如果我能可靠地预测（在误差范围内）每行代码将使用多少内存，那就太好了。

4

1 回答 1

1

到目前为止，现代内存管理并不像您想象的那样具有确定性。

如果您想要更多可重现的结果，请确保摆脱任何垃圾收集、任何并行性（特别是与您的程序并行运行的垃圾收集！）并确保进程在内存中的限制值远小于您的空闲系统内存。

当内核过度使用内存（您可能想了解这意味着什么）、完全没有交换存储并且无法履行其承诺时，内核 OOM 杀手是最后的手段。

内核可以分配在第一次访问之前不需要存在的内存。因此，OOM 杀手可能不会在分配时发生，而是在实际使用页面时发生。

于 2019-09-05T14:05:36.647 回答