当ColdFusion最大限度地利用CPU时，我如何找到它正在咀嚼/窒息？ [英] When ColdFusion is maxing out the CPU, how do I find out what it's chewing/choking on?

问题描述

我在Ubuntu上在中Amazon EC2实例上运行CF 9.0.1。 CF间歇性地（每天数次...，但是特别是没有隔离到高峰使用的小时）。在这种情况下，运行顶部可以获得这个（或类似的东西）：

I'm running CF 9.0.1 on Ubuntu on an "Medium" Amazon EC2 instance. CF has been seizing-up intermittently (several times per day...but notably not isolated to hours of peak usage). At such times, running top gets me this (or something similar):

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的起点：

So, it's obviously consuming most of the server resources. The following error has been showing up in my cfserver.log in the lead-up to each 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 status get：

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.所以这是有道理的。我可以增加线程池来覆盖这些类型的负载尖峰。

In the administrator, under Server Settings > Request Tuning, the setting for Maximum number of simultaneous Template requests is 25. So this makes sense so far. I could just increase the thread pool to cover these sort of load spikes. I could make it 200. (Which I did just now as a test.)

但是，还有这个文件 / opt / coldfusion9 / runtime / servers / coldfusion / SERVER-INF / jrun.xml 。并且一些设置在那里似乎冲突。例如，它读为：

However, there's also this file /opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. And some of the settings in there appear to conflict. For example, it reads:

<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）线程超过在管理中设置的同时请求限制。所以，我不确定。这些独立的配置是否需要手动匹配？或者是 jrun.xml 文件应该是由CF管理员写的更改在那里？嗯。但也许这是不同的，因为大概CF调度器应该只使用所有可用线程的子集，对吗？所以我们总是有真正的用户的线程？我们也有这样的：

Which a) has fewer active threads (what does this mean?), and b) has a max threads that exceed the simultaneous request limit set in the admin. So, I'm not sure. Are these independent configs that need to be made to match manually? Or is the jrun.xml file supposed to be written by the CF Admin when changes are made there? Hmm. But maybe this is different because presumably the CF Scheduler should only use a subset of all available threads, right?...so we'd always have some threads for real live users? We also have this in there:

<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 最后，我们有：

This appears to have changed when I changed the CF Admin setting...maybe...but it's the activeHandlerThreads that matches my new maximum simulataneous requests setting...rather than the maxHandlerThreads, which again exceeds it. Finally, we have this:

<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.必须有一些上限取决于可用的服务器资源...但我不知道是什么，我真的不想玩，因为它是一个生产环境。

So, I'm not certain which (if any) of these I should change and what exactly the relationship is between maximum requests and maximum threads. Also, since several of these list the maxHandlerThreads as 1000, I'm wondering if I should just set the maximum simultaneous requests to 1000. There must be some upper limit that depends on available server resources...but I'm not sure what it is and I don't really want to play around with it since it's a production environment.

我不知道它是否这个问题，但当我运行 ps aux | grep coldfusion 我得到以下：

I'm not sure if it pertains to this issue at all, but when I run a ps aux | grep coldfusion I get the following:

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个运行请求，只显示这两个进程。如果单个进程在后台可以有多个线程，那么我会想知道为什么我有两个进程而不是一个进程？...只是好奇。

There are always these two and never more than these two processes. So there does not appear to be a one-to-one relationship between processes and threads. I recall from an MX 6.1 install I maintained for many years that additional CF processes were visible in the process list. It seemed to me at the time like I had a process for each thread...so either I was wrong or something is quite different in version 9 since it's reporting 25 running requests and only showing these two processes. If a single process can have multiple threads in the background, then I'm given to wonder why I have two processes instead of one?...just curious.

，反正，我一直在试验，同时撰写这篇文章。如上所述，我调整了最大同时请求高达200.我希望这将解决我的问题，但CF只是崩溃了，而不是它崩溃，请求开始超时...所以有效地崩溃）。这一次，顶部看起来类似（仍然消耗超过99％的CPU），但CF状态看起来不同：

So, anyway, I've been experimenting while composing this post. As noted above I adjusted the maximum simultaneous requests up to 200. I was hoping this would solve my problem, but CF just crashed again (rather it slogged down and requests started timing out...so effectively "crashed"). This time, top looked similar (still consuming more than 99% of the CPU), but CF status looked different:

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

显然，最大同时请求，允许更多的请求同时运行...但是它仍然最大化了服务器资源。

Obviously, since I'd increased the maximum simultaneous requests, it was allowing more requests to run simultaneously...but it was still maxing out the server resources.

进一步的实验（重新启动CF后）在大约30-35Reqs Run'g之后，服务器变得不可用，并且所有其他请求都发出不可避免的超时：

Further experiments (after restarting CF) showed me that the server became unusably slogged after about 30-35 "Reqs Run'g", with all additional requests headed for an inevitable timeout:

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

增加最大同时请求没有帮助。我猜这是什么结果是这是：它有这么难的时间是什么？这些尖峰从哪里来？流量的爆发？在什么页面？在任何给定时间运行什么请求？我想我只需要更多的信息，以继续疑难解答。如果有长期运行的请求，或其他问题，我没有看到它在日志（虽然我有那个选项在管理中选中）。我需要知道哪些请求是那些负责这些尖峰的人。任何帮助将不胜感激。非常感谢。

So, it's clear that increasing the maximum simultaneous requests has not helped. I guess what it comes down to is this: What is it having such a hard time with? Where are these spikes coming from? Bursts of traffic? On what pages? What requests are running at any given time? I guess I simply need more information to continue troubleshooting. If there are long-running requests, or other issues, I'm not seeing it in the logs (although I do have that option checked in the admin). I need to know which requests exactly are those responsible for these spikes. Any help would be much appreciated. Thanks.

〜天

推荐答案

的高cpu生产错误和我一直处理他们的方式是这样：

I've had a number of 'high-cpu in production' type bugs and the way i've always dealt with them is this:

1. 使用< a href =http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstack.html> jstack PID >> stack.log转储5个堆栈跟踪，5秒间隔。

1. Use jstack PID >> stack.log to dump 5 of stack traces, 5 seconds apart. Number of traces and timing not critical.

打开 Samurai 。你每次进行转储时都会看到线程的视图。处理您的代码的线程启动web-（对于使用内置服务器的请求）和jrpp-通过Apache / IIS进入的请求。

Open the log in Samurai. You get a view of the threads at each time you did a dump. Threads processing your code start web- (for requests using the built-in server) and jrpp- for requests coming in through Apache/IIS.

的每个线程。你正在寻找在每个转储非常相似的堆栈。如果一个线程看起来像一直处理同一个请求，那么靠近顶部的位会指向发生无限循环的位置。

Read the history of each thread. You're looking for the stack being very similar in each dump. If a thread looks like it's handling the same request the whole time, the bits that vary near the top will point to where an infinite loop is happening.

您可以随意在线上转储一个堆栈跟踪，并指向我们。

Feel free to dump a stack trace somewhere online and point us to it.

我用来理解发生了什么的另一种技术是修改apache的httpd.conf日志时间：％D和记录会话ID：％{jsessionid}，它允许你跟踪单个用户在启动挂起，并做一些不错的统计/图表与数据请使用 LogParser 缩小数字并输出到CSV，然后使用Excel来绘制图表数据）：

The other technique I've used to understand what's going on is to modify apache's httpd.conf to log time taken: %D and record session id: %{jsessionid} which allows you to trace individual users in the run-up to hangs and to do some nice stats/graphs with the data (I use LogParser to crunch the numbers and output to CSV, followed by Excel to graph the data):

LogFormat "%h %l %u %t "%r" %>s %b %D %{jsessionid}" customAnalysis
CustomLog logs/analysis_log customAnalysis

只需记住即可启用 CF指标，这将为您带来一些措施服务器在运行中挂起什么。我设置为每10秒记录一次，并将格式更改为CSV，因此我可以grep从事件日志的指标，然后运行他们通过Excel图表服务器负载在runup中崩溃。

One other technique I've just remembered is to enable CF Metrics, which will get you some measure of what the server was up to in the runup to a hang. I set this to log every 10 seconds and change the format to be CSV, so I can grep the metrics from the event log and then run them through Excel to graph server load in the runup to crashes.

Barny

这篇关于当ColdFusion最大限度地利用CPU时，我如何找到它正在咀嚼/窒息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！