我们注意到运行 Solaris 10 的客户的永久 GC 容量从 50% 增长到 97%。
在注意到 perm gen 的峰值之前,您的客户的应用程序中是否有重大的代码更改?还是一直都是这样(从 50% 到 97%)?
我想此时这并不重要,但在某些情况下,在系统测试期间应该可以检测到这样的尖峰(假设您的团队在客户的系统测试周期中具有可见性。)
可以肯定的一件事是,以 97% 的速度运行太接近舒适度的最大值,您将不得不使用 max perm gen 参数(并且因此使用其他堆参数......很可能。)
此 JVM 使用默认值“permgen”(我们没有将任何自定义 Permgen FLAG 传递给 JVM)。
不是一个好主意。在部署之前,您应该(必须阅读)始终表征您的(或您的客户)应用程序。您的客户应该告诉您他们需要什么参数,或者您的团队必须在 UAT 和系统测试周期期间确定这些参数(假设您对这些有可见性;见上文。)
我们是否应该认为它很快就会发生 OutOfMemoryError ?
这不是不可避免的,但有可能(特别是如果应用程序尚未承受最大可能负载时)。如果峰值是最近出现的现象,也有可能。在这种情况下,很可能是由于代码更改或由于其他因素(操作系统中的补丁、容器中的补丁、客户流量的变化、数据库中的变化等)导致的先前未知的情况。
我们应该设置更高的 PermGen 值,而不是在生产中以 97% 的 permgen 空间运行?
海事组织,是的。如果您(或您的客户)可以描述或估计应用程序的内存(永久和堆)需求(以及当前和未来可能的流量),您应该给自己 10%-20% 的保证金,以防万一。少了就是玩火。任何更有可能的东西都是浪费的。
内存可能很便宜,但应用程序的性能和稳定性却不是 ;)
如果你没有使用visualgc,你应该。这是一个很好的工具,可以直观地检查 JVM 内存中不同段的情况。还有visualvm,它更强大、更通用,然而,读数的visualgc UI呈现特别适合这个任务。
PS:我们在 solaris 10 上使用 JDK 1.6.0_23。
我不认为这应该重要。您的应用程序容器是什么(如果您的应用程序在一个容器中运行。)您可能需要编辑您的帖子以包含它。