使用 np.zeros 时在 Windows 上出现 MemoryError，但在 MacOS 上则不然 [重复]

我想构建一个 numpy 数组，但在具有 16 GB RAM 的 Windows 中出现 MemoryError。为了提供更多信息，详细信息如下：

Python 2.7.13 |Anaconda custom (64-bit)| (default, May 11 2017, 13:17:26) [MSCv.1500 64 bit (AMD64)] on win32

xx = np.zeros((110000,80000,3))

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
MemoryError

然而，完全相同的代码在具有 8 GB RAM 的 Mac 计算机上运行。详细信息是：

Python 2.7.12 |Anaconda 4.2.0 (x86_64) [GCC 4.2.1 (LLVM build ... )on darwin)]

xx = np.zeros((1100000,8000000,3)) doesn't give error. 

当我最后增加大小时，我在 Mac 上收到错误，但错误有所不同，如下所示：

xx = np.zeros((1100000,80000000,3))
python(713,0x7fffa76b33c0) malloc: *** mach_vm_map(size=211200000000000) 
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
MemoryError

我该如何处理这个问题？

您的阵列太大，无法容纳两个系统上的物理 RAM：

110000 * 80000 * 3 * 8 / 1024 / 1024 / 1024 = 196.[69] GB

然而，这取决于您的系统如何处理内存请求以及如何“存储”内存。例如，系统可以简单地为您的进程“保留”内存，但推迟实际分配，直到读取/修改内存为止。即使分配了内存，内存也可以被压缩（如评论中所述，感谢@Martijn Pieters），并且有很多零可以很好地压缩 - 但是，一旦修改内存，压缩效率就会降低，并且使用更多的“真实内存”。

这意味着失败时由系统决定（如果您实际对数组执行某些操作，两者最终都会失败）。在您的情况下，当您请求的物理内存多于实际内存时，Windows 选择立即失败。在 Mac 上，似乎您必须修改“足够”的值（另请参阅这个答案关于“为什么 352GB NumPy ndarray 可以在 8GB 内存 macOS 计算机上使用？” https://stackoverflow.com/q/54961554/5393381）直到失败。

import numpy as np
arr = np.zeros((110000,80000,3))  # MemoryError on Windows
arr += 10                         # MemoryError on Mac

你可以使用例如psutil检查使用的内存量（物理和虚拟）：

import psutil
print(psutil.virtual_memory())  
# svmem(total=4170924032, available=1666629632, percent=60.0, used=2504294400, free=1666629632)
arr = np.zeros((10000, 10000))
print(psutil.virtual_memory())
# svmem(total=4170924032, available=1664675840, percent=60.1, used=2506248192, free=1664675840)
arr += 10
print(psutil.virtual_memory())
# svmem(total=4170924032, available=864059392, percent=79.3, used=3306864640, free=864059392)

所以即使在 Windows 上np.zeros直到需要时才立即“使用”物理内存。

我该如何处理这个问题？

最简单（但可能最昂贵）的选择是购买（大量）更多内存。但您也可以尝试使用适合您的物理内存的块大小来“分块”处理。最终，最好的解决方案是重新考虑您的方法/算法，这样您就不需要那么多内存。