我们正在运行JRun 4，并有很多崩溃。 我想了解问题来自何处，并修改了jrun.xml文件以启用度量标准日志logging。
这是我所看到的…
01/06 15:07:27 metrics Web threads (busy/total/delayed): 2/100/0 Sessions: 0 Total Memory=70720 Free=7464 01/06 15:08:27 metrics Web threads (busy/total/delayed): 1/100/0 Sessions: 0 Total Memory=66944 Free=9199 01/06 15:09:27 metrics Web threads (busy/total/delayed): 3/100/0 Sessions: 0 Total Memory=67456 Free=9644 01/06 15:10:27 metrics Web threads (busy/total/delayed): 3/100/0 Sessions: 0 Total Memory=63360 Free=8368 我一直在阅读的这本书（Adobe Coldfusion Anthology，Apress）build议“繁忙”的数字是以MB为单位的可用内存。 Adobe文档说它是“正在运行的线程”。 哪个是对的？
另外，这是什么意思 ？
如果我正确地阅读它，我总共有100个线程和3个繁忙的线程。 那么，如果其他97个线程都不忙或者没有延迟，那么还有什么呢？
我会build议使用FusionReactor或SeeFusion等工具来debuggingColdFusion的稳定性问题。 根据我的经验，崩溃与内存分配问题（不够多，垃圾回收器设置等）有关。 这也取决于你的应用程序在做什么以及有多less个并发线程被设置为运行。 上面提到的工具可以让您更加直观地了解服务器，从而实时解决问题。
busy / total / delayed线程是Jrun当前正在处理的线程数。
忙碌正在进行中，正在执行中。 Delayed是一个在线程队列中被换出并且当前正在等待执行的线程（通常是因为没有活动线程可用）。 它将一直保持到活动线程释放或达到configuration中设置的超时值。
不知道这本书“Adobe Coldfusion Anthology”，但Jrun的pipe理文档（在CD或networking上可用）在这个指标中是非常明确的。
我build议你也包括JDBC计数器，它们相当有用。
最后一件事是知道记忆，不仅是总数，还有不同的记忆，build筑的限制等等。
一些来自Windows资源监视器的CPU，页面和类似的指标通常是有帮助的。
我们搞了5年左右，得到了大量的问题，主要是在开发区域比在系统，nodaways，有时是我们的错。
最后，我推荐你，是jrun4具有“集群”的能力，如果你发现一个瓶颈，你总是可以把前端IIS和2或3 Jrun4放在后端。 很有效。
希望能帮助到你。