Java 内存消耗“最高” 和 HP-Ux
我们提供在 Linux、AIX 和 HP-Ux (PA-RISC) 上运行的 Java 应用程序。 我们似乎很难从在其他两种环境中运行良好的应用程序在 HP-Ux 上获得可接受的性能水平。 执行时间和内存消耗都是如此。
尽管我还没有找到关于“为什么”的明确文章，但我相信使用“top”测量内存消耗是一种粗略的方法，因为共享代码等会给出误导性的结果。 然而，这就是我们在客户站点上所要做的一切，其中 HP-Ux 上的内存消耗已成为一个问题。 这次当我们从 Java 1.4 迁移到 Java 1.5（在 HP-Ux 11.23 PA-RISC 上）时，它才成为一个问题。 我所说的“问题”是指机器停止创建新进程，因为我们已经耗尽了所有 16GB 物理内存。
通过测量“之前”和“之后”的总“可用内存”，我们试图衡量 Java 应用程序消耗了多少内存。 我编写了一个快速应用程序，在 ArrayList 中存储 10,000 个随机 64 位字符串，并尝试使用这种方法来测量 Java 1.4 和 Java 1.5 下 Linux 和 HP-Ux 上的消耗。
结果：
HP Java 1.4 ~60MB
HP Java 1.5 ~150MB
Linux Java 1.4 ~24MB
Linux Java 1.5 ~16MB
谁能解释为什么会出现这些结果？ 这是“top”测量可用内存的方式的特殊之处吗？ HP 上的 Java 1.5 真的比 Java 1.4 消耗的内存多 2.5 倍吗？
谢谢。
We ship Java applications that are run on Linux, AIX and HP-Ux (PA-RISC). We seem to struggle to get acceptable levels of performance on HP-Ux from applications that work just fine in the other two environments. This is true of both execution time and memory consumption.
Although I'm yet to find a definitive article on "why", I believe that measuring memory consumption using "top" is a crude approach due to things like the shared code giving misleading results. However, it's about all we have to go on with a customer site where memory consumption on HP-Ux has become an issue. It only became an issue this time when we moved from Java 1.4 to Java 1.5 (on HP-Ux 11.23 PA-RISC). By "an issue", I mean that the machine ceased to create new processes because we had exhausted all 16GB of physical memory.
By measuring "before" and "after" total "free memory" we are trying to gauge how much has been consumed by a Java application. I wrote a quick app that stores 10,000 random 64 bit strings in an ArrayList and tried this approach to measuring consumption on Linux and HP-Ux under Java 1.4 and Java 1.5.
The results:
HP Java 1.4 ~60MB
HP Java 1.5 ~150MB
Linux Java 1.4 ~24MB
Linux Java 1.5 ~16MB
Can anyone explain why these results might arise? Is this some idiosyncrasy of the way "top" measures free memory? Does Java 1.5 on HP really consume 2.5 times more memory than Java 1.4?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
JVM 可能只是有不同的默认参数。 堆将增长到您配置的大小。 Sun VM 上的默认值是机器中 RAM 的一定百分比 - 也就是说，如果您使用内存较多的机器，默认情况下 Java 将使用更多内存。
如果 HP-UX VM 没有对 HP 的此类事情进行大量调整，我会感到非常惊讶。 我建议您摆弄两者的参数 - 找出可以使用的最小最大堆大小，而不会损害性能或吞吐量。
The JVMs might just have different default parameters. The heap will grow to the size that you have configured to let it. The default on the Sun VM is a certain percentage of the RAM in the machine - that's to say that Java will, by default, use more memory if you use a machine with more memory on it.
I'd be really surprised if the HP-UX VM hadn't had lots of tuning for this sort of thing by HP. I'd suggest you fiddle with the parameters on both - figure out what the smallest max heap size you can use without hurting performance or throughput.
我现在没有惠普盒子来检验我的假设。 但是，如果我是你，我会使用 JConsole（JDK 附带）或 yourkit 之类的分析器来测量正在发生的情况。
然而，你似乎是在发现不对劲后才开始测量的； 所以，我并不是否认这种情况的发生——只是向你指出我在同样情况下会做的事情。
I don't have a HP box right now to test my hypothesis. However, if I were you, I would use a profiler like JConsole(comes with JDK) OR yourkit to measure what is happening.
However, it appears that you started measuring after you saw something amiss; So, I'm NOT discounting that it's happening -- just pointing you at something I'd have done in the same situation.
首先，不清楚你通过“10,000 个随机 64 位字符串”测试测量了什么。 您应该启动应用程序，测量它的引导内存占用量，然后运行测试。 Java 1.5 很可能在启动后立即获取更多堆（例如，由于堆管理器设置）。
其次，我们确实在 HP-UX 下运行 1.4、1.5 和 1.6 版本的 Java 应用程序，并且它们没有表现出任何特殊的内存要求。 不过，我们有安腾硬件。
三、为什么用top？ 为什么不直接打印 Runtime.getRuntime().totalMemory() 呢？
第四，通过向 ArrayList 添加值会产生内存碎片。 ArrayList 有时必须将其内部存储空间增加一倍。 根据 GC 设置和 ArrayList.ensureCapacity() 实现，未收集的内存量可能在 1.4 和 1.5 之间存在显着差异。
本质上，您没有找出问题的原因，而是运行了随机测试，但没有提供任何有用的信息。 您应该在应用程序上运行分析器来找出内存泄漏的位置。
First, it's not clear what did you measure by "10,000 random 64 bit strings" test. You supposed to start the application, measure it's bootstrap memory footprint, and then run your test. It could easily be that Java 1.5 acquires more heap right after start (due to heap manager settings, for instance).
Second, we do run Java apps under 1.4, 1.5 and 1.6 under HP-UX, and they don't demonstrate any special memory requirements. We have Itanium hardware, though.
Third, why do you use top? Why not just print Runtime.getRuntime().totalMemory()?
Fourth, by adding values to ArrayList you create memory fragmentation. ArrayList has to double it's internal storage now and then. Depending on GC settings and ArrayList.ensureCapacity() implementation the amount of non-collected memory may differ dramatically between 1.4 and 1.5.
Essentially, instead of figuring out the cause of problem you have run a random test that gives you no useful information. You should run a profiler on the application to figure out where the memory leaks.
您可能还想看看您正在尝试解决的问题...我不认为有很多占用 16GB 内存的问题不需要进行一轮良好的优化。
您要启动多个虚拟机吗？ 您是否将大型数据集读入内存，并且没有足够快地丢弃它们？ 等等等等
You might also want to look at the problem you are trying to solve... I don't imagine there are many problems that eat 16GB of memory that aren't due for a good round of optimization.
Are you launching multiple VMs? Are you reading large datasets into memory, and not discarding them quickly enough? etc etc etc.