jakarta-ee - 帮我稳定这个 jRun 配置 (CF9/Win2k3/IIS6)

Question

不确定这是否更适合 ServerFault，但由于我不是管理员而是开发人员，我想我会尝试 SO。

一段时间以来，我们一直在努力保持多服务器配置的稳定。上个月底，我们在两台服务器设置(每台一个实例)上运行在 CF 7.0.2 下。那时，我们设法将每个实例的正常运行时间缩短到大约 1 周，然后它们才会自行重启。自本月初以来，我们升级到 CF 9，我们回到了第一天多次重启的状态。

我们当前的配置是 2 个 Win2k3 服务器，运行 4 个实例的集群，每个服务器 2 个实例。在这一点上，我们非常确定这是由于 JVM 设置不当造成的。

我们一直在玩弄它们，虽然有些比其他更稳定，但我们从未完全正确。

从默认:

java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/

目前:

java.args=-server -Xmx896m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance1b.log

我们已经确定，通过使用 FusionReactor 进行监控，我们确实需要超过默认的 512MB，平均而言，我们消耗的内存量徘徊在 300MB 左右，在重负载下可能会上升到 700MB。

大多数崩溃将记录在 jrun4/bin/hs_err_pid*.log 中，总是“交换空间不足”

我在帖子底部附上了昨天的 hs_err 和垃圾收集器日志文件的链接。

相关部分是( 我认为 )这个:

Heap
 PSYoungGen      total 89856K, used 19025K [0x55490000, 0x5b6f0000, 0x5b810000)
  eden space 79232K, 16% used [0x55490000,0x561a64c0,0x5a1f0000)
  from space 10624K, 52% used [0x5ac90000,0x5b20e2f8,0x5b6f0000)
  to   space 10752K, 0% used [0x5a1f0000,0x5a1f0000,0x5ac70000)
 PSOldGen        total 460416K, used 308422K [0x23810000, 0x3f9b0000, 0x55490000)
  object space 460416K, 66% used [0x23810000,0x36541bb8,0x3f9b0000)
 PSPermGen       total 107520K, used 106079K [0x03810000, 0x0a110000, 0x23810000)
  object space 107520K, 98% used [0x03810000,0x09fa7e40,0x0a110000)

从中，我发现它的 PSPermGen 已满(大多数日志在崩溃前会显示相同)，这就是我们增加 MaxPermSize 但总数仍显示为 107520K 的原因!？？!

这里没有人是 jRun 专家，所以任何关于下一步尝试的帮助甚至想法都将不胜感激!

日志文件:
抱歉，我知道 sendspace 不是最友好的地方 - 如果您对日志文件有其他主机建议，请告诉我，我会更新帖子(所以不喜欢它们内联，它会破坏帖子的格式)。

hs_err 日志文件:http://www.sendspace.com/file/fgak8l

gc 日志:http://www.sendspace.com/file/w0r2ct

Answer 1

这种影响可能有很多原因——从你的应用程序的构建方式(应用程序或服务器范围的非常规使用？糟糕的数据库驱动程序和连接管理？解析巨大的 XML 文件？使用 CFHTTP 或其他外部资源？问题？ native session 复制？)到您的编码实践(到处都是变量范围？)到服务器中的 CPU 类型。您不太可能在没有太多分析的情况下想出一些神奇的 JVM 设置(甚至可能不会)。但是对于初学者来说，为什么会有如此大的 PermGen？似乎是一种奇特的模式，但当然我对您的应用一无所知。

尝试一些不同的垃圾收集器似乎没有什么损失。如果适合您的 JVM 版本，请尝试:

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

并添加:

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

这可能有助于管理您的大型永久代。如果您尝试这些，请不要忘记取出 XX:+UseParallelGC。