java: 如何在 32 位 JVM 中使用超过 4 GB 内存的堆
我们的产品当前在 32 位 1.6 JRE 上运行。我们使用 Berkeley DB，它消耗 4 GB 地址空间中的大约 2.5 GB RAM。这为 JVM 地址空间留下了大约 750 MB 的内存。
我们当前的设置遇到了内存不足问题。如果将 JVM 堆大小增加到 1.5 GB，同时仍然保留 Berkeley DB 的 2.5 GB 空间，那就太好了。有没有办法在 32 位 JVM 中访问超过 4 GB RAM/堆？我正在考虑以下解决方案
1) 使用 GC 性能更好的 JVM —— 这会给我带来边际结果 —— 我可以获得大约 50-100 MB 的工作内存
2）像memcached或“进程外ehcache”之类的东西——这可以让我在硬件允许的情况下获得尽可能多的IPC/序列化开销。
是否有其他解决方案来增加应用程序的可寻址内存？
该解决方案应该适用于运行 sparc 的 solaris 10。
*更新：由于使用本机共享库，目前我们无法切换到 64 位 JVM，即使操作系统是 64 位 *
谢谢，
We have a product that runs currently on a 32 bit 1.6 JRE. We're using Berkeley DB which consumes about 2.5 GB RAM of the 4 GB address space. That leaves us about 750 MB of memory for the JVM address space.
We're currently hitting OutOfMemory issues with the current setup. It would be nice to increase our JVM heap size to 1.5 GB while still retaining Berkeley DB's 2.5 GB space. Is there any way to access more than 4 GB RAM/heap in a 32-bit JVM ? I've considering the following solutions
1) use a JVM which does better GC -- this will give me marginal results -- I could get about 50-100 MB working memory
2) something like memcached or "out of process ehcache " -- this can get me as much as the hardware allows with the overhead of IPC/serialization.
Are there other solutions to increasing an application's addressable memory ?
The solution should work on solaris 10 running sparc.
*UPDATE : Because of using native shared libraries, right now, we're unable to switch to a 64-bit JVM even though the OS is 64-bit *
thank you,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
此外，每个真正的 SPARC（不是古老的 SuperSparc 或可怜的 LION）实际上都是 64 位的。因此，可以更轻松地切换到 64 位版本的操作系统。我不了解 Solaris，但在 linux 中可以在 64 位操作系统上运行 32 位应用程序。 64 位操作系统将允许您运行 64 位 JVM。
更新：Solaris 中有 ramdisk http: //wikis.sun.com/display/BigAdmin/Talking+about+RAM+disks+in+the+Solaris+OS 我认为您应该尝试使用它们来存储数据库（或数据库的临时文件）。
不会有像情况（1）那样的额外序列化/IPC；仅额外读/写或 mmap/munmap。但 Ramdisk 比 SSD 快一个数量级，比 HDD 快 3-4 个数量级。
Also, every real SPARC (not ancient SuperSparc or poor-man LION) is 64-bit really. So, it can be easier to switch to 64-bit version of OS. I don't know about Solaris, but in linux there is possible to run 32-bit applications on top of 64-bit OS. And 64bit OS will allow you to run 64-bit JVM.
UPDATE: There are ramdisks in Solaris http://wikis.sun.com/display/BigAdmin/Talking+about+RAM+disks+in+the+Solaris+OS and I think you should try them for storing database (or temporary files of DB).
There will be no extra serialization/IPC like in case (1); only extra read/write or mmap/munmap. But Ramdisk is order faster than SSD and 3-4 orders faster than HDD.
32 位程序无法处理超过 4GB 的内存地址。它们只是没有足够的位来表示更多的内存。
您最好的选择是升级到 64 位 JRE。
32-bit programs are incapable of handling more than 4GB of memory addresses. They just don't have enough bits to represent more memory.
Your best bet would be to upgrade to a 64-bit JRE.
我建议您在 32 位 JVM 中运行 32 位共享本机库，并在 64 位 JVM 中运行其他所有内容。您可以让 64 位 JVM 调用 32 位 JVM 来执行它所做的任何操作。我假设您的大部分数据/内存需求可以转移到 64 位 JVM。
I suggest you run your 32-bit shared native libraries in a 32-bit JVM and run everything else in a 64-bit JVM. You can have the 64-bit JVM call the 32-bit JVM to do whatever it does. I assume the bulk of your data/memory requirement can be moved to a 64-bit JVM.