我遇到了一個我似乎無法理解的記憶問題。我在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的數據？
3 回答
翻翻過去那場雪
TA貢獻2065條經驗 獲得超14個贊
我不知道為什么你認為你的進程應該能夠訪問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以及它們需要的任何空間以及其他各種內容。它并沒有太多，但它不是零。
MM們
TA貢獻1886條經驗 獲得超2個贊
你實際上沒有必要在windows上編譯exe，這IMAGE_FILE_LARGE_ADDRESS_AWARE只是圖像標題中的一個標志（并不是說這將得到官方支持，但是我們沒有評判;））。dll在這件事上也沒有發言權，所以不管怎么說都不需要改變。
Helenr
TA貢獻1780條經驗 獲得超4個贊
我完全不知道Python或者OP所依賴的任何Python模塊是否做了這樣的事情。我認為不太可能，但我無法保證。顯然有一些原因它不是IMAGE_FILE_LARGE_ADDRESS_AWARE開箱即用的; 我的猜測是，到目前為止，沒有一個開發人員發現它值得測試和/或擦除源代碼，因為如果他們真的需要超過2GB，他們只需要使用64位版本。但這只是一個猜測，這就是為什么我的回答說它很有可能會起作用，但我不能保證。
添加回答
舉報
0/150
提交
取消