再次更新
我尝试创建一些简单的方法来重现此问题,但没有成功。
到目前为止,我已经尝试了各种简单的数组分配和操作,但它们都会抛出 MemoryError 而不仅仅是 SIGKILL 崩溃。
例如:
x =np.asarray(range(999999999))
或:
x = np.empty([100,100,100,100,7])
只需抛出 MemoryErrors 即可。
我希望有一种简单的方法可以在某个时候重新创建它。
结束更新
我有一个运行 numpy/scipy 的 python 脚本和一些自定义 C 扩展。
在我的 Virtual Box 下的 Ubuntu 14.04 上,它运行得很好。
在 Amazon EC2 T2 微实例上,它终止(运行一段时间后)并输出:
被杀
在python调试器下运行,信号没有被捕获,调试器也退出。
在 strace 下运行,我得到:
munmap(0x7fa5b7fa6000, 67112960) = 0
mmap(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5b7fa6000
mmap(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5affa4000
mmap(NULL, 67112960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5abfa3000
mmap(NULL, 67637248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5a7f22000
mmap(NULL, 67637248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa5a3ea1000
mmap(NULL, 67637248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa59fe20000
gettimeofday({1406518336, 306209}, NULL) = 0
gettimeofday({1406518336, 580022}, NULL) = 0
+++ killed by SIGKILL +++
在 gdb 下运行,同时尝试捕捉“SIGKILL”,我得到:
[Thread 0x7fffe7148700 (LWP 28022) exited]
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) where
No stack.
运行 python 的跟踪模块(python -m trace --trace ),我得到:
defmatrix.py(292): if (isinstance(obj, matrix) and obj._getitem): return
defmatrix.py(293): ndim = self.ndim
defmatrix.py(294): if (ndim == 2):
defmatrix.py(295): return
defmatrix.py(336): return out
--- modulename: linalg, funcname: norm
linalg.py(2052): x = asarray(x)
--- modulename: numeric, funcname: asarray
numeric.py(460): return array(a, dtype, copy=False, order=order)
我现在想不出其他任何事情来弄清楚发生了什么事。
我怀疑它可能会耗尽内存(它是一个AWS Micro实例),但我不知道如何确认或否认这一点。
是否有其他工具可以帮助我准确地确定程序停止的位置? (或者我以错误的方式运行上述工具之一来解决这个问题?)
Amazon EC2 T2 微型实例默认没有定义交换空间,因此我添加了一个 4GB 交换文件,并且能够运行程序完成。
但是,我仍然对运行程序的方式非常感兴趣,以便它以一些更接近“内存不足”而不是“已杀死”的消息终止
如果有人有任何建议,我们将不胜感激。
听起来您已经遇到了可怕的 Linux OOM Killer。当系统完全耗尽内存并且内核绝对需要分配内存时,它会杀死一个进程而不是使整个系统崩溃。
查看系统日志以确认这一点。类似于以下内容的行:
kernel: [884145.344240] mysqld invoked oom-killer:
稍后跟随:
kernel: [884145.344399] Out of memory: Kill process 3318
应该存在(在这个例子中,它特别提到了mysql)
您可以将这些行添加到您的
/etc/sysctl.conf
文件中以有效禁用 OOM 杀手:
vm.overcommit_memory = 2
vm.overcommit_ratio = 100
然后重新启动。现在,原来的、内存匮乏的进程应该无法分配内存,并且希望抛出正确的异常。
设置
overcommit_memory
意味着 Linux 不会过度提交内存,这意味着如果没有足够的内存,内存分配将会失败。有关 overcommit_ratio
的影响的详细信息,请参阅此答案:https://serverfault.com/a/510857
[您的口译员会话被信号 SIGKILL 终止。]