Я запускаю 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

Таким образом, ясно, что увеличение максимального количества одновременных запросов не помогло. Я предполагаю, что это сводится к следующему: с чем ему так тяжело? Откуда эти шипы? Всплески трафика? На каких страницах? Какие запросы выполняются в любой момент времени? Я думаю, мне просто нужно больше информации, чтобы продолжить устранение неполадок. Если есть длительные запросы или другие проблемы, я не вижу их в журналах (хотя у меня эта опция отмечена в админке). Мне нужно знать, какие именно запросы отвечают за эти всплески. Любая помощь приветствуется. Благодарю.

~ День