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

Question

我遇到了一个我似乎无法理解的记忆问题。我在Windows 7 64位机器上运行8GB内存并运行32位python程序。这些程序读取了5,118个压缩的numpy文件（npz）。Windows报告磁盘上的文件占用1.98 GB每个npz文件包含两个数据：'arr_0'的类型为np.float32，'arr_1'的类型为np.uint8python脚本读取每个文件将其数据附加到两个列表中，然后关闭该文件。在文件4284/5118周围，程序抛出一个MemoryException但是，任务管理器说发生错误时python.exe * 32的内存使用量是1,854,848K~ = 1.8GB。远低于我的8 GB限制，或者假定的32位程序的4GB限制。在程序中我捕获内存错误并报告：每个列表的长度为4285.第一个列表包含总共1,928,588,480个float32的〜= 229.9 MB的数据。第二个列表包含12,342,966,272 uint8的〜= 1,471.3MB数据。所以，一切似乎都在检查。除了我得到内存错误的部分。我绝对有更多的内存，它崩溃的文件大约是800KB，所以它不会在读取一个巨大的文件时失败。此外，该文件未损坏。如果我事先没有耗尽所有的记忆，我可以读得很好。为了让事情变得更加混乱，所有这一切似乎在我的Linux机器上运行良好（虽然它确实有16GB的内存，而不是我的Windows机器上的8GB），但是，它似乎并不是机器的RAM。造成这个问题。为什么Python会抛出内存错误，当我预计它应该能够分配另外2GB的数据？

Answer 1

我不知道为什么你认为你的进程应该能够访问4GB。根据MSDN上Windows版本的内存限制，在64位Windows 7上，默认的32位进程获得2GB。*这正是它用完的地方。

那么，有没有办法解决这个问题呢？

好吧，你可以自定义构建32位Python，它使用IMAGE_FILE_LARGE_ADDRESS_AWARE标志，重建numpy和所有其他扩展模块。我不能保证使用大地址识别标志运行所有相关代码都是安全的; 这是一个很好的机会，但除非有人已经完成并进行了测试，“一个好机会”是任何人都可能知道的最好的机会。

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

---

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

---

那么，为什么这可以在您的Linux机箱上运行？

因为你的linux盒子被配置为32位进程提供3.5GB的虚拟地址空间，或者3.99GB，或者......好吧，我不能告诉你确切的数字，但是我已经看到多年的每个发行版都已配置好了至少3.25GB。

---

*另请注意，您甚至没有真正获得2GB的数据; 你的计划。操作系统及其驱动程序可以访问代码的大部分内容位于另一半，但有些位于您的一半，以及您加载的每个DLL以及它们需要的任何空间以及其他各种内容。它并没有太多，但它不是零。

Answer 2

你实际上没有必要在windows上编译exe，这IMAGE_FILE_LARGE_ADDRESS_AWARE只是图像标题中的一个标志（并不是说这将得到官方支持，但是我们没有评判;））。dll在这件事上也没有发言权，所以不管怎么说都不需要改变。

Answer 3

我完全不知道Python或者OP所依赖的任何Python模块是否做了这样的事情。我认为不太可能，但我无法保证。显然有一些原因它不是IMAGE_FILE_LARGE_ADDRESS_AWARE开箱即用的; 我的猜测是，到目前为止，没有一个开发人员发现它值得测试和/或擦除源代码，因为如果他们真的需要超过2GB，他们只需要使用64位版本。但这只是一个猜测，这就是为什么我的回答说它很有可能会起作用，但我不能保证。