Estoy ejecutando CF 9.0.1 en Ubuntu en una instancia "mediana" de Amazon EC2. La FQ se ha estado consumiendo de forma intermitente (varias veces al día ... pero, en particular, no se ha aislado a horas de uso máximo). En esos momentos, corriendo.parte superior me trae esto (o 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

Entonces, obviamente está consumiendo la mayoría de los recursos del servidor. El siguiente error ha aparecido en mi cfserver.log en el período previo a cada embargo:

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.

Si corro/ opt / coldfusion9 / bin / coldfusion status, Yo obtengo:

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

En el administrador, bajoConfiguración del servidor> Solicitud de ajuste, el escenario paraNúmero máximo de solicitudes de plantillas simultáneas es 25. Así que esto tiene sentido hasta ahora. Simplemente podría aumentar el grupo de hilos para cubrir este tipo de picos de carga. Podría hacerlo en 200. (Lo que acabo de hacer como prueba).

Sin embargo, también hay este archivo./opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. Y algunos de los ajustes allí parecen entrar en conflicto. Por ejemplo, se lee:

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

Qué a) tiene menos subprocesos activos (¿qué significa esto?) Yb) tiene un máximo de subprocesos que exceden el límite de solicitud simultánea establecido en el administrador. Por lo tanto, no estoy seguro. ¿Son estas configuraciones independientes las que se deben hacer para que coincidan manualmente? O es eljrun.xml ¿Se supone que el administrador de CF escribe el archivo cuando se realizan cambios allí? Hmm Pero tal vez esto sea diferente porque, presumiblemente, el programador CF solo debería usar un subconjunto de todos los subprocesos disponibles, ¿no? ... ¿así que siempre tendríamos algunos subprocesos para usuarios reales en vivo? También tenemos esto allí:

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

Esto parece haber cambiado cuando cambié la configuración de CF Admin ... quizás ... pero es laactiveHandlerThreads que coincida con mi nueva configuración máxima de solicitudes simultáneas ... en lugar de lamaxHandlerThreads, que de nuevo lo supera. Finalmente, tenemos esto:

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

Por lo tanto, no estoy seguro de cuál (si alguno) de estos debería cambiar y cuál es exactamente la relación entre las solicitudes máximas y las hebras máximas. Además, como varios de estos listanmaxHandlerThreads como 1000, me pregunto si debería establecer el máximo de solicitudes simultáneas en 1000. Debe haber algún límite superior que dependa de los recursos disponibles del servidor ... pero no estoy seguro de qué es y realmente no quiero Para jugar con él ya que es un entorno de producción.

No estoy seguro de si se trata de este problema, pero cuando ejecuto unps aux | grep coldfusion Me sale lo siguiente:

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

Siempre hay estos dos y nunca más que estos dos procesos. Por lo tanto, no parece haber una relación de uno a uno entre los procesos y los subprocesos. Recuerdo de una instalación MX 6.1 que mantuve durante muchos años que los procesos de CF adicionales estaban visibles en la lista de procesos. Me pareció que en ese momento tenía un proceso para cada subproceso ... así que o me equivoqué o algo es muy diferente en la versión 9, ya que informa de 25 solicitudes en ejecución y solo muestra estos dos procesos. Si un solo proceso puede tener varios subprocesos en segundo plano, entonces me pregunto por qué tengo dos procesos en lugar de uno ... solo por curiosidad.

Así que, de todos modos, he estado experimentando mientras componía este post. Como se indicó anteriormente, ajusté el máximo de solicitudes simultáneas hasta 200. Esperaba que esto resolviera mi problema, pero la CF simplemente se bloqueó de nuevo (en lugar de eso, se agotó y las solicitudes comenzaron a agotarse ... tan efectivamente se "colapsó"). Esta vez, la parte superior parecía similar (aún consumía más del 99% de la CPU), pero el estado de la CF parecía 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, dado que había aumentado el número máximo de solicitudes simultáneas, estaba permitiendo que se ejecutaran más solicitudes simultáneamente ... pero todavía estaba maximizando los recursos del servidor.

Otros experimentos (después de reiniciar el CF) me mostraron que el servidor se volvió insostenible después de aproximadamente 30-35 "Reqs Run'g", con todas las solicitudes adicionales dirigidas a un tiempo de espera inevitable:

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

Por lo tanto, está claro que el aumento del máximo de solicitudes simultáneas no ha ayudado. Supongo que todo se reduce a esto: ¿con qué lo está pasando tan mal? ¿De dónde vienen estas espigas? ¿Ráfagas de tráfico? ¿En qué páginas? ¿Qué solicitudes se están ejecutando en un momento dado? Supongo que simplemente necesito más información para continuar con la solución de problemas. Si hay solicitudes de larga ejecución u otros problemas, no lo veo en los registros (aunque sí tengo esa opción marcada en el administrador). Necesito saber qué solicitudes son exactamente las responsables de estos picos. Cualquier ayuda sería muy apreciada. Gracias.

~ Día