Когда 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/coldfusion 9/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>

Какой а) имеет меньше активных потоков (что это значит?) и b) имеет максимальные потоки, которые превышают ограничение на одновременный запрос, установленный администратором. Итак, я не уверен. Нужны ли эти независимые конфигурации, чтобы они соответствовали друг другу? Или файл 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 просто рухнул снова (скорее, он провалился и запросы начали отсчет времени... так эффективно "разбился" ). На этот раз топ выглядел похожим (все еще потребляющим более 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

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

~ день

Ответ 1

У меня было несколько ошибок типа "high-cpu in production", и я всегда с ними обращался:

Используйте jstack PID → stack.log, чтобы сбросить 5 трасс стека, 5 секунд друг от друга. Количество следов и времени не критично.
Откройте журнал Samurai. Вы получаете представление о потоках при каждом создании дампа. Темы, обрабатывающие ваш запуск кода веб-сайта (для запросов с использованием встроенного сервера) и jrpp- для запросов, поступающих через Apache/IIS.
Прочитайте историю каждого потока. Вы ищете, чтобы стек был очень схожим в каждой дампе. Если поток выглядит так, как будто он обрабатывает один и тот же запрос все время, биты, которые изменяются вблизи вершины, указывают на то, где происходит бесконечный цикл.

Не стесняйтесь удалять трассировку стека где-то в сети и указывать на нее.

Другой метод, который я использовал для понимания того, что происходит, - это изменить apache httpd.conf для регистрации времени:% D и записать идентификатор сеанса:% {jsessionid}, который позволяет отслеживать отдельных пользователей в режиме разгона для зависания и выполнения некоторых хороших статистических данных/графиков с данными (я использую LogParser для сверления чисел и вывода в CSV, а затем Excel для построения графика данных):

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

Еще один метод, который я только что запомнил, - включить CF Metrics, который даст вам некоторое представление о том, что было на сервере в разбеге, чтобы повесить, Я установил это для регистрации каждые 10 секунд и изменил формат CSV, поэтому я могу grep метрики из журнала событий, а затем запустить их через Excel, чтобы загрузить нагрузку сервера сервера при сбое.

Барни

Ответ 2

Чтобы узнать, что максимизирует ваш процесс, требуется много информации, которая является "внутренней" для вашей системы. Трудно делать это со стороны, глядя на вещи, такие как запросы в очереди и т.д. Одно можно сказать наверняка - изменение одновременной настройки запроса на очень высокое число не собирается делать трюк:) Все, что он сделает, это удалить что-то, что предназначено для сохранения CF от злости на слишком большом процессоре.

Вот мой список вещей, которые максимизируют использование ЦП.

Клиентские ключи в реестре. У меня есть пара отличных статей о почему эта проблема не может возникнуть из-за чего. проверить мой блог (coldfusion muse).
промежуточные проблемы, связанные с базой данных. Это фактически немного усугубляется в облаке, где сети и ограничения на использование полосы пропускания могут иметь вид "дроссельной заслонки", соединения с БД. Большинство приложений CF активно используют БД. Если что-то мешает или замедляет связи, результатом является количество подключений возрастает, пока оно не ударит по этому одновременному номеру запросы начинаются с очереди - но эта проблема не обязательно связана с Сам CF - это симптом.
Проблемы с JVM - настройка вашей JVM для обработки сбор мусора, есть достаточно новых и пермских помещений и т.д. важно... хотя откровенно вышеперечисленные пункты часто являются первыми в неисправность.

Есть много других причин, которые могут произойти - среди них (как вы предполагаете) проблемы с кодом, возникающие при запуске определенных скриптов. Длительные запросы, загрузка файлов, тяжелая работа по расписанию, индексный бот-трафик, генерирующий трафик или нереста слишком много сеансов... список продолжается.

Надеюсь, что-то из этого списка, который я вам предоставил, поразит вас как можно больше. удачи.

(и да FR или даже монитор CF - хорошие инструменты, которые помогут вам разобрать все это:).

Ответ 3

Несколько недель назад у меня был сервер, который максимально ускорял использование ЦП в процессе JRun и периодически перезапускал его, только чтобы в течение 24 часов он мог вернуться обратно до 100%. Я суетился с настройками JVM и тому подобное, пока, наконец, не обнаружил, к моему смущенному удивлению, бесконечный цикл в моем коде. Был цикл WHILE с условием, которое никогда не будет выполнено. К сожалению.

Итак, возможно, вы сделали простую ошибку в своем коде, и это не имеет ничего общего с конфигурацией сервера, fwiw.

+1 для демонстрации FusionReactor. Это, по крайней мере, даст вам некоторые подсказки.

Ответ 4

Вам нужно будет увеличить размер пула активных потоков. Пожалуйста, проверьте приведенные ниже ссылки.

http://www.talkingtree.com/blog/index.cfm/2005/11/28/Request-timed-out-waiting-for-an-available-thread-to-run

http://helpx.adobe.com/coldfusion/kb/coldfusion-mx-6-1-request.html

Счастливое кодирование!!!

Ответ 5

Вы пытались использовать монитор ColdFusion Server, который поставляется с Coldfusion?