32 位 FreeBSD 7.2 和 1GB mmap
我在使用 FreeBSD 和大型 mmap 时遇到了一些问题。 Linux 不会出现同样的问题。
在程序启动时，它总是可以获得 1 GB 的地图。但是，有一个重新加载操作，其中文件被替换并重新映射。新地图通常每次都会大一点，因此它不能完全适合旧的 mmap 位置。这种重映射在 FreeBSD 上经常失败，但在 Linux 上几乎不会失败。 （在使用 ASLR 的 Linux 上，它更常失败。FreeBSD 使用 ASLR 吗？）
我认为这是因为库加载了其他库以及在程序运行期间完成的内存分配导致虚拟内存空间碎片化。 FreeBSD 的 malloc 实现或库加载可能有一些特殊性导致了这种情况。
我正在寻找一些我可以做的事情来使其更有可能发挥作用。
我正在考虑的一件事是始终映射完整的 1 GB 空间，即使文件大小实际上可能为 890 MB。如果我能做到这一点，那么我将始终拥有 1 GB 插槽来将新的 895 MB 文件重新映射到其中。
I've been having some trouble with FreeBSD and large mmaps. Linux does not show the same problems.
On program startup it can always get the 1 GB map. However, there's a reload operation where the file is replaced and remapped. The new map is usually just a little bigger each time so it doesn't fit neatly into the old mmap location. This remap often fails on FreeBSD but hardly ever on Linux. (It fails more often on Linuxes using ASLR. Does FreeBSD use ASLR?)
I think this is because of libraries loading other libraries and also memory allocations done during the program run that fragment the virtual memory space. There is probably some peculiarity of FreeBSD's malloc implementation or library loading that causes this.
I'm looking for some things I can do to make it more likely to work.
One thing I am considering is to just always mmap a full 1 GB of space even if the file size might actually be 890 MB. If I can make that work then I will always have a 1 GB slot to remap the new 895 MB file into.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
该问题可能是由于没有足够大的连续地址空间块引起的。它很可能出现在具有 1Gb mmap 的 32 位系统上。
考虑专门使用 64 位系统（现在大多数公司都在生产服务器上使用），或者使用 mmap() 处理几个较小的区域。
你无法回避这个问题。
The problem is probably caused by not having a big enough contigous block of address space. It's very likely on a 32-bit system with a 1Gb mmap.
Consider using 64-bit systems exclusively (most companies do for production servers now), or mmap()ing several smaller areas instead.
You aren't going to get around this.