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专家，所以对于下一步尝试的任何帮助甚至想法都会非常感激!!

日志文件： 对不起，我知道sentpace不是最友好的地方 - 如果你有其他主机建议的日志文件让我知道，我会更新帖子（所以不喜欢它们内联，它炸毁了帖子的格式）。

hs_err日志文件：http://www.sendspace.com/file/fgak8l
gc log：http://www.sendspace.com/file/w0r2ct

Answer 1

这种效果可能有很多原因 - 构建应用程序的方式（非常规使用应用程序或服务器范围？错误的数据库驱动程序和连接管理？解析巨大的XML文件？使用CFHTTP或其他外部资源）？本机会话复制的问题？）您的编码实践（var scoping无处不在？）到服务器中的各种CPU。如果没有太多的分析，你不可能想出一些神奇的子弹JVM设置（也许甚至不是这样）。但对于初学者来说，为什么你有这么大的PermGen呢？看起来像一个奇特的模式，但当然我对你的应用程序一无所知。

通过尝试一些不同的垃圾收集器，你似乎没什么可失去的。如果适合您的JVM版本，请尝试：

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

并加入：

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

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

Answer 2

稍微更新一下。我尝试了不同的GC，虽然有些人稳定了系统一段时间但它不断崩溃，只是不那么频繁。所以我一直在挖掘并最终发现，当操作系统本身拒绝分配所请求的内存时，JVM将抛出“超出交换空间”。

这通常发生在已经为JVM进程分配了最大内存时，这是jrun开销，JVM本身，所有库，堆和堆栈。由于请求生成在堆栈中，如果您生成了大量请求，堆栈将会增长和增长。每个线程的大小根据操作系统和JVM的版本而有所不同，但可以使用-Xss参数进行控制。我把我们减少到64k所以我们的java.args看起来像这样：

java.args=-server -Xmx768m -Xss64k -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance2a.log

到目前为止，一切都保持稳定，没有任何明显的减速6天，这绝对是我见过应用程序熬夜的最长时间。如果过多地减少请求大小，您将开始注意日志中的堆栈溢出错误而不是OOM错误。

我的下一步是调整MaxPermSize，但到目前为止一切都很好！

帮我稳定这个jRun配置（CF9 / Win2k3 / IIS6）

2 个答案: