当ColdFusion最大化CPU时,我如何找出咀嚼/窒息的内容？

Question

我在"中型"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中,每个seize-up的前导中都出现以下错误:

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状态,我得到:

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

在管理员中,在" 服务器设置">"请求调整"下," 最大同时模板请求数 "设置为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)具有超过管理员中设置的同时请求限制的最大线程数.所以,我不确定.这些独立的配置是否需要手动匹配？或者,当在那里进行更改时,应该由CF管理员写入jrun.xml文件？嗯.但也许这是不同的,因为假设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

因此,很明显,增加最大同时请求并没有帮助.我想它归结为:它有什么困难？这些尖峰来自哪里？交通爆发？什么页面？什么请求在任何给定时间运行？我想我只需要更多信息来继续进行故障排除.如果有长时间运行的请求或其他问题,我在日志中没有看到它(尽管我确实在管理员中检查了该选项).我需要知道哪些请求确实是那些负责这些峰值的人.任何帮助将非常感激.谢谢.

〜天

Answer 1

我有一些'生产中的高cpu'类型的错误,我总是处理它们的方式是这样的:

1. 使用jstack PID >> stack.log转储5个堆栈跟踪,相隔5秒.跟踪数和时序并不重要.

2. 打开Samurai的日志.每次进行转储时都会获得线程视图.处理代码的线程启动web-(对于使用内置服务器的请求)和jrpp-用于通过Apache/IIS进入的请求.

3. 阅读每个线程的历史记录.您正在寻找每个转储中非常相似的堆栈.如果一个线程看起来总是处理相同的请求,那么在顶部附近变化的位将指向无限循环发生的位置.

随意在线转储堆栈跟踪并指向我们.

我用来了解正在发生的事情的另一种技术是修改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运行它们以在运行中将服务器负载图形化为崩溃.

巴尼