Когда ColdFusion увеличивает нагрузку на процессор, как мне узнать, что он жует / задыхается?
Я запускаю CF 9.0.1 в Ubuntu на "Medium" 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
В админке, подServer Settings > Request Tuning, настройка дляMaximum number of simultaneous Template requests 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 Admin ... может быть ... но это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
Таким образом, ясно, что увеличение максимального количества одновременных запросов не помогло. Я предполагаю, что это сводится к следующему: с чем ему так тяжело? Откуда эти шипы? Всплески трафика? На каких страницах? Какие запросы выполняются в любой момент времени? Я думаю, мне просто нужно больше информации, чтобы продолжить устранение неполадок. Если есть длительные запросы или другие проблемы, я не вижу их в журналах (хотя у меня эта опция отмечена в админке). Мне нужно знать, какие именно запросы отвечают за эти всплески. Любая помощь приветствуется. Благодарю.
~ День