Ich verwende CF 9.0.1 unter Ubuntu auf einer "mittleren" Amazon EC2-Instanz. Die Mukoviszidose hat zeitweise zugenommen (mehrmals pro Tag ... aber insbesondere nicht isoliert auf Stunden mit Spitzenbelastung). Zu solchen Zeiten läuftoben holt mir das (oder etwas ähnliches):

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

Es verbraucht also offensichtlich die meisten Serverressourcen. Der folgende Fehler wurde in meinem cfserver.log im Vorfeld jeder Erfassung angezeigt:

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.

Wenn ich renne/ opt / coldfusion9 / bin / coldfusion Status, Ich bekomme:

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

Im Administrator unterServereinstellungen> Anforderungsoptimierung, die Einstellung fürMaximale Anzahl gleichzeitiger Vorlagenanforderungen ist 25. Das macht also soweit Sinn. Ich könnte einfach den Thread-Pool vergrößern, um diese Art von Lastspitzen abzudecken. Ich könnte es 200 machen. (Was ich gerade als Test gemacht habe.)

Es gibt jedoch auch diese Datei/opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/jrun.xml. Und einige der Einstellungen dort scheinen zu widersprechen. Zum Beispiel lautet es:

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

Welche a) hat weniger aktive Threads (was bedeutet das?) Und b) hat eine maximale Anzahl von Threads, die das im Administrator festgelegte Limit für gleichzeitige Anforderungen überschreiten. Also bin ich mir nicht sicher. Müssen diese unabhängigen Konfigurationen manuell angepasst werden? Oder ist dasjrun.xml Datei, die vom CF-Administrator geschrieben werden soll, wenn dort Änderungen vorgenommen werden? Hmm. Aber vielleicht ist das anders, weil der CF-Scheduler vermutlich nur eine Teilmenge aller verfügbaren Threads verwenden sollte, oder? ... also hätten wir immer einige Threads für echte Live-Benutzer? Das haben wir auch drin:

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

Dies scheint sich geändert zu haben, als ich die CF Admin-Einstellung geändert habe ... vielleicht ... aber es ist dieactiveHandlerThreads das entspricht meiner neuen maximalen Einstellung für gleichzeitige Anforderungen ... anstatt dermaxHandlerThreads, was es wieder übertrifft. Schließlich haben wir Folgendes:

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

Ich bin mir also nicht sicher, welche davon ich ändern soll und wie genau die Beziehung zwischen maximalen Anfragen und maximalen Threads ist. Auch da mehrere dieser Liste diemaxHandlerThreads Als 1000er frage ich mich, ob ich nur die maximale Anzahl gleichzeitiger Anfragen auf 1000 setzen soll. Es muss eine Obergrenze geben, die von den verfügbaren Serverressourcen abhängt ... aber ich bin mir nicht sicher, was es ist und ich will es nicht wirklich um damit herumzuspielen, da es sich um eine Produktionsumgebung handelt.

Ich bin mir nicht sicher, ob es sich überhaupt um dieses Problem handelt, aber wenn ich eineps aux | grep coldfusion Ich bekomme folgendes:

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

Es gibt immer diese beiden und nie mehr als diese beiden Prozesse. Es scheint also keine Eins-zu-Eins-Beziehung zwischen Prozessen und Threads zu geben. Ich erinnere mich an eine MX 6.1-Installation, die ich viele Jahre lang gepflegt habe, dass zusätzliche CF-Prozesse in der Prozessliste sichtbar waren. Zu der Zeit schien es mir, als hätte ich für jeden Thread einen Prozess. Entweder habe ich mich geirrt oder etwas in Version 9 ist ganz anders, da es 25 laufende Anfragen meldet und nur diese beiden Prozesse anzeigt. Wenn ein einzelner Prozess mehrere Threads im Hintergrund haben kann, frage ich mich, warum ich zwei Prozesse anstelle von einem habe? ... nur neugierig.

Jedenfalls habe ich experimentiert, als ich diesen Beitrag verfasst habe. Wie oben erwähnt, habe ich die maximale Anzahl gleichzeitiger Anfragen auf 200 eingestellt. Ich hatte gehofft, dass dies mein Problem lösen würde, aber CF stürzte erneut ab (stattdessen wurde es langsamer, und Anfragen liefen aus ... so effektiv "abgestürzt"). Diesmal sah top ähnlich aus (verbraucht immer noch mehr als 99% der CPU), aber der CF-Status sah anders aus:

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

Da ich die maximale Anzahl gleichzeitiger Anforderungen erhöht hatte, konnten offensichtlich mehr Anforderungen gleichzeitig ausgeführt werden, aber die Serverressourcen wurden immer noch ausgeschöpft.

Weitere Experimente (nach dem Neustart von CF) zeigten, dass der Server nach etwa 30-35 "Reqs Run'g" unbrauchbar blockiert war, wobei alle zusätzlichen Anforderungen auf eine unvermeidbare Zeitüberschreitung hinausliefen:

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

Es ist also klar, dass das Erhöhen der maximalen Anzahl gleichzeitiger Anforderungen nicht geholfen hat. Ich denke, worauf es ankommt, ist Folgendes: Womit hat es so eine harte Zeit? Woher kommen diese Spikes? Verkehrsstöße? Auf welchen Seiten? Welche Anforderungen werden zu einem bestimmten Zeitpunkt ausgeführt? Ich brauche einfach mehr Informationen, um mit der Fehlerbehebung fortzufahren. Wenn es Anfragen mit langer Laufzeit oder andere Probleme gibt, wird dies nicht in den Protokollen angezeigt (obwohl ich diese Option im Administrator aktiviert habe). Ich muss wissen, welche Anfragen genau für diese Spitzen verantwortlich sind. Jede Hilfe wäre sehr dankbar. Vielen Dank.

~ Tag