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

Question

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

相当长一段时间以来，我们一直在努力保持多服务器配置的稳定。上月底，我们在两台服务器设置(每台一个实例)上运行 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 类型。如果不进行大量分析，您不太可能想出一些 Elixir 的 JVM 设置(甚至可能也不会)。但对于初学者来说，为什么会有这么大的永久代？似乎是一种奇怪的模式，但我当然对您的应用程序一无所知。

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

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

并添加:

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

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