64位窗口上的Python 32位内存限制

我的记忆有点问题，我好像不明白

我在一台Windows7 64位机器上，内存为8GB，运行一个32位python程序

程序读取5118压缩的numpy文件（npz）。 Windows报告文件在磁盘上占用1.98 GB

每个npz文件包含两段数据： “arr_0”的类型为np.32和 “arr_1”属于np.uint8类型

python脚本读取每个文件并将其数据附加到两个列表中，然后关闭该文件

在文件4284/5118周围，程序抛出一个MemoryException

但是，任务管理器表示，发生错误时python.exe*32的内存使用量为18548k~=1.8GB。远低于我的8GB限制，或者32位程序的4GB限制

在程序中，我捕获内存错误并报告： 每个列表的长度为4285。 第一个列表包含总计1928588480个float32~=229.9 MB的数据。 第二个列表包含12342966272 uint8的~=1471.3MB数据

所以，一切似乎都在检验中。除了我得到一个内存错误的部分。 我绝对有更多的内存，它崩溃的文件约为800KB，因此读取大文件时不会失败

此外，文件没有损坏。如果我事先不把所有的记忆都用光的话，我可以很好地读懂它

更让人困惑的是，所有这些在我的Linux机器上似乎都可以正常工作（虽然它有16GB的内存，而在我的Windows机器上则是8GB），但似乎并不是机器的RAM造成了这个问题

---

为什么Python会抛出内存错误，而我认为它应该能够再分配2GB的数据

我不知道为什么您认为您的进程应该能够访问4GB。根据MSDN的说法，在64位Windows 7上，默认32位进程的内存为2GB.*这正是它的内存不足之处

那么，有办法解决这个问题吗

好的，您可以使用

IMAGE\u FILE\u LARGE\u ADDRESS\u AWARE

标志定制32位Python，并重建

numpy

和所有其他扩展模块。我不能保证所有相关的代码都可以安全地使用大地址识别标志运行；这是一个很好的机会，但除非有人已经做过并测试过，“一个好机会”是所有人都可能知道的最好的机会

或者，更明显的是，只需使用64位Python即可

---

物理RAM的数量是完全无关的。你似乎认为你有 8GB内存的“8GB限制”，但它不是这样工作的。你的系统占用你所有的RAM加上它需要的任何交换空间，并在应用程序之间进行分配；即使在8GB的机器上，应用程序也可以获得20GB的虚拟内存，而不会出现内存错误。同时，32位应用程序无法访问超过4GB的地址空间，操作系统将占用部分地址空间（默认情况下，在Windows上占一半），因此即使在不运行任何其他功能的8GB计算机上，也只能获得2GB的地址空间。（这并不是说在现代操作系统上“不运行任何其他东西”是可能的，但你知道我的意思。）

---

那么，为什么这在您的linux机器上起作用呢

因为您的linux机箱配置为为32位进程提供3.5GB的虚拟地址空间，或者3.99GB，或者……好吧，我不能告诉您确切的数字，但是我多年来看到的每个发行版都配置了至少3.25GB的虚拟地址空间

---

---

*还要注意的是，您的数据甚至没有得到完整的2GB；你的节目。操作系统及其驱动程序使代码可以访问的大部分内容位于另一半，但有些位位于另一半，以及加载的每个DLL和它们所需的任何空间，以及各种其他内容。它加起来不算太多，但也不是零。

您拥有的物理RAM的数量无关紧要。在Windows上，无论您是否愿意，您总是可以进行交换。您可以发布用于加载

.npz

文件的代码吗？如果使用

np.load（file，mmap_mode='r+'）

它将使用更少的内存，因为使用此参数将打开一个…问题不在于python本身，而在于numpy和scipy，这需要64位fortran编译器。如果我没记错的话，唯一现存的是英特尔的，而且不是免费的。我知道你可以使用，所以这是可能的。不过，您必须使用非官方的二进制文件，这些二进制文件来自一个不隶属于python.org的网站。@Erotemic：是什么让您认为32位python更稳定？如今，大多数核心开发人员都在64位Unix设备上。有很多bug和性能问题，其中一个更改使32位的情况变得更糟，几个月来没有人注意到，很少有其他方面的问题。我可以理解存在构建/工具链问题，但如果你的理由真的是认为Python本身在64位中不稳定，那你就大错特错了。@J.Martinot-Lagarde:一年多以前，有两个问题。首先，gfortran还没有为MinGW64的黄金时间做好准备，但今天不是这样；它现在是完全受支持的平台之一，就像MinGW32（以及本机Win32、cygwin和所有*nixes）一样。另一方面，Christoph Gohkle的Win64 binary scipy软件包可能有一些不明确的许可证，这给想要分发使用它们的二进制软件包的人带来了问题，这与许多人无关，尤其是那些不想使用“非python.org附属网站的非官方二进制文件”的人。实际上，您不必在windows上编译exe，

IMAGE\u FILE\u LARGE\u ADDRESS\u AWARE

只是图像头中的一个标志（这不是官方支持的，但我们不作判断）。而且DLL在这件事上没有发言权，所以这些代码无论如何都不必更改。@Voo:但是您的所有代码，包括DLL，都必须在打开标志的情况下安全使用。比方说，如果Python及其标准扩展模块在构建时检查您是否需要大地址感知支持，并生成不同的c