Когда ColdFusion максимально загружает ЦП, как мне узнать, что он жует или давится?
Я запускаю CF 9.0.1 на Ubuntu на «Среднем» экземпляре Amazon EC2. CF периодически срывался (несколько раз в день... но, в частности, не ограничивался часами пикового использования). В такие моменты запуск topдает мне это (или что-то подобное):
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
В администраторе в разделе Настройки сервера > Настройка запросовпараметр Максимальное количество одновременных запросов шаблоновравен 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>
Что а) имеет меньше активных потоков (что это значит?), и б) имеет максимальное количество потоков, которые превышают лимит одновременных запросов, установленный в админке. Итак, я не уверен. Это независимые конфиги, которые нужно сделать, чтобы сопоставлялись вручную? Или это jrun.xmlдолжен быть записан администратором CF при внесении в него изменений? Хм. Но, может быть, дело в другом, потому что планировщик CF, по-видимому, должен использовать только подмножество всех доступных потоков, верно? ... чтобы у нас всегда было несколько потоков для реальных живых пользователей? У нас также есть это:
<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% ЦП), но состояние 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
Итак, ясно, что увеличение Максимальные одновременные запросы не помогли. Я предполагаю, что все сводится к следующему: с чем ему так тяжело? Откуда берутся эти шипы? Всплески трафика? На каких страницах? Какие запросы выполняются в любой момент времени? Думаю, мне просто нужно больше информации, чтобы продолжить устранение неполадок. Если есть длительные запросы или другие проблемы, я не вижу этого в журналах (хотя у меня есть эта опция в админке).Мне нужно знать, какие именно запросы ответственны за эти всплески. Любая помощь приветствуется. Спасибо.
~День