Estou executando o CF 9.0.1 no Ubuntu em uma instância "Medium" do Amazon EC2. O CF tem sido confiscado intermitentemente (várias vezes por dia ... mas notavelmente não isolado para horas de pico de uso). Nesses momentos, correndotopo me pega isso (ou algo 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

Então, obviamente, está consumindo a maior parte dos recursos do servidor. O erro a seguir foi exibido em meu cfserver.log no período que antecedeu a cada captura:

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.

Se eu correr/ opt / coldfusion9 / bin / coldfusion status, Eu recebo:

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

No administrador, sobConfigurações do servidor> Solicitar ajuste, o cenário paraNúmero máximo de solicitações de modelos simultâneas é 25. Então, isso faz sentido até agora. Eu poderia apenas aumentar o pool de threads para cobrir esses picos de carga. Eu poderia fazer isso 200. (O que eu fiz agora como um teste.)

No entanto, também há esse arquivo/opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. E algumas das configurações parecem conflitar. Por exemplo, ele lê:

<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>

Qual a) tem menos encadeamentos ativos (o que isso significa?) E b) tem encadeamentos máximos que excedem o limite de solicitações simultâneas definido no admin. Então, não tenho certeza. Essas configurações independentes precisam ser feitas para corresponder manualmente? Ou é ojrun.xml arquivo deveria ser escrito pelo CF Admin quando as alterações são feitas lá? Hmm. Mas talvez isso seja diferente, porque presumivelmente o Agendador CF só deve usar um subconjunto de todos os tópicos disponíveis, certo? ... então sempre teríamos alguns tópicos para usuários reais ao vivo? Nós também temos isso aí:

<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>

Isto parece ter mudado quando mudei a configuração do CF Admin ... talvez ... mas é oactiveHandlerThreads que corresponda às minhas novas configurações de solicitações simultâneas máximas ... em vez demaxHandlerThreads, que novamente excede isso. Finalmente, temos isto:

<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>

Então, eu não estou certo de qual (se houver) eu deveria mudar e qual é exatamente o relacionamento entre o máximo de pedidos e o máximo de threads. Além disso, uma vez que vários deles listammaxHandlerThreads como 1000, eu estou querendo saber se eu deveria apenas definir o máximo de solicitações simultâneas para 1000. Deve haver algum limite superior que depende dos recursos disponíveis do servidor ... mas não tenho certeza do que é e realmente não quero para brincar com isso, já que é um ambiente de produção.

Eu não tenho certeza se pertence a este problema, mas quando eu corro umps aux | grep coldfusion Eu recebo o seguinte:

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

Há sempre esses dois e nunca mais do que esses dois processos. Portanto, não parece haver um relacionamento um-para-um entre processos e threads. Lembro-me de uma instalação do MX 6.1 que mantive durante muitos anos que processos adicionais de CF eram visíveis na lista de processos. Pareceu-me na época que eu tinha um processo para cada thread ... então, ou eu estava errado ou algo é bem diferente na versão 9, já que está relatando 25 solicitações em execução e mostrando apenas esses dois processos. Se um único processo pode ter vários threads em segundo plano, então me pergunto por que tenho dois processos em vez de um? ... apenas curioso.

Então, de qualquer forma, eu estive experimentando enquanto escrevia este post. Como mencionado acima, ajustei o número máximo de solicitações simultâneas para até 200. Esperava que isso resolvesse meu problema, mas o CF acabou de funcionar novamente (em vez disso, ele diminuiu o volume e os pedidos começaram a exceder o tempo ... de forma eficiente "travaram"). Desta vez, o top parecia similar (ainda consumindo mais de 99% da CPU), mas o status do CF parecia diferente:

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

Obviamente, como eu aumentava o número máximo de solicitações simultâneas, ele permitia que mais solicitações fossem executadas simultaneamente ... mas ainda estava maximizando os recursos do servidor.

Experiências posteriores (depois de reiniciar o CF) mostraram-me que o servidor ficou inutilmente danificado após cerca de 30-35 "Reqs Run'g", com todos os pedidos adicionais para um inevitável 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

Então, está claro que aumentar o número máximo de solicitações simultâneas não ajudou. Eu acho que o que acontece é: com o que está tendo tanto trabalho? De onde vêm esses espinhos? Rajadas de tráfego? Em quais páginas? Quais solicitações estão sendo executadas a qualquer momento? Eu acho que simplesmente preciso de mais informações para continuar com a solução de problemas. Se houver solicitações de execução longa ou outros problemas, não os verei nos logs (embora tenha essa opção marcada no admin). Preciso saber quais solicitações são exatamente as responsáveis ​​por esses picos. Qualquer ajuda seria muito apreciada. Obrigado.

~ Dia