Del*_*lta 2 python numpy memory-mapped-files memory-mapping numpy-memmap
我正在尝试处理一个大约 50 GB 的大文件。我正在尝试使用 numpy 内存映射访问该文件。我看到用于内存映射的文件大小有限制，32 位系统为 2GB。这是链接：https : //docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.memmap.html
我想知道使用 numpy 内存映射对文件大小是否有硬限制以获得良好的性能。
您通常不需要担心 64-bit 的限制mmap，但我会解释原因。
首先，32 位平台理论上最多可以支持2**32, 或 4GB。但是操作系统为自己保留了一部分。在 Windows 上，默认情况下这个块是整整 2GB（您可以将其配置为更低，但某些软件可能会损坏，因为它假定使用“签名指针”是安全的），而在其他平台上，它通常更像是 512MB。
同样，64 位平台理论上最多可以支持2**64, 或 16EB。在这里，操作系统是否保留 512MB 或 2GB 不会产生重大影响。
但是，您的硬件可能会将内容限制在 44 到 56 位之间（大多数当前系统是 48 位），而 44 位只有 256TB。
而且您的操作系统可能会限制更多。IIRC，最早的64位linux内核只使用了40位（因为当时没有硬件可以使用更多），只有1TB。
最后，在 Windows 上，如果您使用的是“基本”或“入门”版本，对于 Windows 8 家庭基本版，它可能会进一步限制到低至 8GB。这是唯一可能影响您的文件的方法。
但是，与后来的 32 位情况不同，2018 年几乎没有人拥有比他们的操作系统可以一次全部页面更多的物理 RAM。很多人在内存超过 4GB 的机器上运行 32 位 Windows（或 64 位 Windows 上的 32 位 Python），但几乎不可能加载具有 40 位限制的操作系统的 64 位系统具有超过 1TB 的 RAM。
因此，无论您拥有多少 RAM，您都应该能够将其中的大部分用于mmap.
有时，您想要mmap一个实际上不适合您的 RAM 的文件。然后您将依赖于操作系统的页面交换，这当然比窗口化文件的较小地图效率低，但可能足够有效，并且可能更简单。
在这种情况下，它可能会在您的系统上运行，但是如果不知道比您告诉我们的更多，就无法确定。最简单的答案（与 Python 一样）是 EAFP：尝试它，并准备在失败时处理异常（无论是通过编程方式，还是通过读取堆栈跟踪并搜索 StackOverflow 以寻找解决方案）。