我在“中型”Amazon EC2实例上在Ubuntu上运行CF 9.0.1。 CF一直在间歇性地进行癫痫发作（每天数次......但特别是没有隔离到高峰使用时间）。在这种情况下，运行顶部会让我（或类似的东西）：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+COMMAND
15855 wwwrun 20 0 1762m 730m 20m S 99.3 19.4 13:22.96 coldfusion9
因此，它显然占用了大部分服务器资源。我的cfserver.log中出现了以下错误：每次抓取：
java.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool.
如果我运行 / opt / coldfusion9 / bin / coldfusion status ，我会得到：
Pg/Sec DB/Sec CP/Sec Reqs Reqs Reqs AvgQ AvgReq AvgDB Bytes Bytes
Now Hi Now Hi Now Hi Q'ed Run'g TO'ed Time Time Time In/Sec Out/Sec
0 0 0 0 -1 -1 150 25 0 0 -1352560 0 0
在管理员中，在服务器设置＆gt;下;请求调整，同时模板请求的最大数量的设置为25.所以这是有道理的。我可以增加线程池来覆盖这些负载峰值。我可以把它变成200.（我刚刚做了这个测试。）
但是，还有这个文件 /opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml 。那里的一些设置似乎有冲突。例如，它显示为：
<service class="jrunx.scheduler.SchedulerService" name="SchedulerService">
<attribute name="bindToJNDI">true</attribute>
<attribute name="activeHandlerThreads">25</attribute>
<attribute name="maxHandlerThreads">1000</attribute>
<attribute name="minHandlerThreads">20</attribute>
<attribute name="threadWaitTimeout">180</attribute>
<attribute name="timeout">600</attribute>
</service>
其中a）活动线程较少（这意味着什么？），b）最大线程数超过了admin中设置的同时请求限制。所以，我不确定。这些独立的配置是否需要手动匹配？或者 jrun.xml 文件应该由CF管理员在进行更改时写入？嗯。但也许这是不同的，因为假设CF Scheduler应该只使用所有可用线程的子集，对吧？...所以我们总是为真实用户提供一些线程？我们也有这个：
<service class="jrun.servlet.http.WebService" name="WebService">
<attribute name="port">8500</attribute>
<attribute name="interface">*</attribute>
<attribute name="deactivated">true</attribute>
<attribute name="activeHandlerThreads">200</attribute>
<attribute name="minHandlerThreads">1</attribute>
<attribute name="maxHandlerThreads">1000</attribute>
<attribute name="mapCheck">0</attribute>
<attribute name="threadWaitTimeout">300</attribute>
<attribute name="backlog">500</attribute>
<attribute name="timeout">300</attribute>
</service>
当我更改了CF管理员设置时，这似乎已经改变了......也许......但是 activeHandlerThreads 符合我新的最大同步请求设置...而不是 maxHandlerThreads ，再次超过它。最后，我们有这个：
<service class="jrun.servlet.jrpp.JRunProxyService" name="ProxyService">
<attribute name="activeHandlerThreads">200</attribute>
<attribute name="minHandlerThreads">1</attribute>
<attribute name="maxHandlerThreads">1000</attribute>
<attribute name="mapCheck">0</attribute>
<attribute name="threadWaitTimeout">300</attribute>
<attribute name="backlog">500</attribute>
<attribute name="deactivated">false</attribute>
<attribute name="interface">*</attribute>
<attribute name="port">51800</attribute>
<attribute name="timeout">300</attribute>
<attribute name="cacheRealPath">true</attribute>
</service>
所以，我不确定我应该改变哪些（如果有的话）以及最大请求和最大线程之间的关系究竟是什么。此外，由于其中一些将 maxHandlerThreads 列为1000，我想知道是否应该将最大同时请求设置为1000.必须有一些上限取决于可用的服务器资源...但我不确定它是什么，我真的不想玩它，因为它是一个生产环境。
我不确定它是否与这个问题有关，但是当我运行 ps aux |时grep coldfusion 我得到以下内容：
wwwrun 15853 0.0 0.0 8704 760 pts/1 S 20:22 0:00 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -autorestart -start coldfusion
wwwrun 15855 5.4 18.2 1678552 701932 pts/1 Sl 20:22 1:38 /opt/coldfusion9/runtime/bin/coldfusion9 -jar jrun.jar -start coldfusion
总有这两个，并且永远不会超过这两个过程。因此，进程和线程之间似乎没有一对一的关系。我记得在我维护多年的MX 6.1安装中，在进程列表中可以看到其他CF进程。在我看来，就像我对每个线程都有一个进程一样...所以要么我错了，要么在版本9中有些不同，因为它报告了25个正在运行的请求并且只显示了这两个进程。如果一个进程可以在后台有多个线程，那么我很想知道为什么我有两个进程而不是一个？...只是很好奇。
所以，无论如何，我在撰写这篇文章时一直在做实验。如上所述，我将最大同时请求调整为200.我希望这可以解决我的问题，但CF再次崩溃（相反，它已经陷入困境，请求开始超时......因此有效地“崩溃”）。这一次，top看起来很相似（仍然消耗超过99％的CPU），但CF状态看起来不同：
Pg/Sec DB/Sec CP/Sec Reqs Reqs Reqs AvgQ AvgReq AvgDB Bytes Bytes
Now Hi Now Hi Now Hi Q'ed Run'g TO'ed Time Time Time In/Sec Out/Sec
0 0 0 0 -1 -1 0 150 0 0 0 0 0 0
显然，由于我增加了最大同时请求数，因此允许同时运行更多请求...但它仍然最大化服务器资源。
进一步的实验（在重新启动CF之后）向我展示了服务器在大约30-35“Reqs Run'g”之后变得非常不稳定，所有其他请求都不可避免地超时：
Pg/Sec DB/Sec CP/Sec Reqs Reqs Reqs AvgQ AvgReq AvgDB Bytes Bytes
Now Hi Now Hi Now Hi Q'ed Run'g TO'ed Time Time Time In/Sec Out/Sec
0 0 0 0 -1 -1 0 33 0 0 -492 0 0 0
因此，很明显增加最大同时请求并没有帮助。我想它归结为：它有什么困难？这些尖峰来自哪里？交通爆发？什么页面？什么请求在任何给定时间运行？我想我只需要更多信息来继续进行故障排除。如果有长时间运行的请求或其他问题，我在日志中没有看到它（尽管我确实在管理员中检查了该选项）。我需要知道哪些请求确实是那些负责这些峰值的人。任何帮助将非常感激。感谢。
〜日
答案 0 :(得分：5)
我有一些'生产中的高cpu'类型错误，而且我一直处理它们的方式是：
使用jstack PID＆gt;＆gt; stack.log转储5个堆栈跟踪，相隔5秒。跟踪数量和时间并不重要。
在Samurai中打开日志。每次进行转储时都会获得线程视图。处理代码的线程启动web-（对于使用内置服务器的请求）和jrpp-用于通过Apache / IIS进入的请求。
阅读每个帖子的历史记录。您正在寻找每个转储中非常相似的堆栈。如果一个线程看起来一直在处理相同的请求，那么在顶部附近变化的位将指向无限循环发生的位置。
随意在线转储堆栈跟踪并指向我们。
我用来了解正在发生的事情的另一种技术是修改apache的httpd.conf以记录所用时间：％D并记录会话ID：％{jsessionid}，它允许您在启动时跟踪单个用户挂起并用数据做一些不错的统计/图表（我使用LogParser来处理数字并输出到CSV，然后用Excel绘制数据图表）：
LogFormat "%h %l %u %t "%r" %>s %b %D %{jsessionid}" customAnalysis
CustomLog logs/analysis_log customAnalysis
我刚刚记得的另一种技术是启用CF Metrics，它可以帮助您了解服务器在运行中的状态。我将其设置为每10秒记录一次并将格式更改为CSV，这样我就可以从事件日志中获取指标，然后通过Excel运行它们以在运行中将服务器负载图形化为崩溃。
巴尼
答案 1 :(得分：2)
要了解什么是最大化你的过程需要大量的系统“内部”信息。从外面查看排队请求等事情是很难做到的。有一件事是肯定的 - 将同时请求设置改为非常高的数字是不可能的诀窍:)所有它会做的是删除旨在保持的东西CF从虚拟到太多处理器。
这是我最大限度地利用CPU的事情列表。
还有许多其他原因可能发生 - 其中（正如您所推测的）代码问题随着某些脚本的运行而出现。长时间运行的请求，文件上传，繁重的提升计划任务，索引机器人流量产生流量或产生太多会话....列表继续。
希望我提供的这份清单上的内容会尽可能地打击你。祝你好运。
（是的，FR甚至CF显示器都是很好的工具，可以帮助你解决所有这些问题:)。
答案 2 :(得分：0)
几个星期前，我有一台服务器可以最大限度地提高JRun进程的CPU利用率，并定期重新启动它，只是让它在24小时内恢复到100％。我也使用JVM设置等等，直到最后发现，令我尴尬的惊喜，我的代码中的无限循环。有一个WHILE循环，其条件永远不会被满足。糟糕。
所以也许你在代码中犯了一个简单的错误，它与服务器配置无关，fwiw。
+1用于FusionReactor演示。那至少会给你一些线索。
答案 3 :(得分：0)
答案 4 :(得分：0)
您是否尝试过使用Coldfusion附带的ColdFusion Server监视器？