「中」の Amazon EC2 インスタンスの Ubuntu で CF 9.0.1 を実行しています。CF は断続的に上昇しています (1 日に数回...ただし、特にピーク時の使用時間には分離されていません)。そのようなときに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/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>
a) アクティブなスレッドが少ない (これはどういう意味ですか?)、および 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 管理者の設定を変更したときに変更されたように見えます...多分...しかし、新しい最大同時要求設定に一致するのは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
常にこれら 2 つのプロセスがあり、これら 2 つ以上のプロセスはありません。したがって、プロセスとスレッドの間に 1 対 1 の関係があるようには見えません。長年維持してきた MX 6.1 のインストールから、追加の CF プロセスがプロセス リストに表示されていたことを思い出します。当時、各スレッドにプロセスがあるように見えました...バージョン 9 では、25 の実行中のリクエストが報告され、これら 2 つのプロセスしか表示されないため、間違っているか、何かがまったく異なります。1 つのプロセスがバックグラウンドで複数のスレッドを持つことができる場合、なぜ 1 つではなく 2 つのプロセスがあるのか疑問に思うことはありますか? ...ちょっと興味があります。
とにかく、私はこの投稿を作成しながら実験を続けてきました。上記のように、最大同時リクエスト数を 200 に調整しました。これで問題が解決することを期待していましたが、CF が再びクラッシュしました (むしろ、遅くなり、リクエストがタイムアウトし始めたので、効果的に「クラッシュ」しました)。今回は、top は同じように見えましたが (まだ CPU の 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
したがって、同時リクエストの最大数を増やしても効果がないことは明らかです。結局のところ、これは次のことだと思います：何がそんなに苦労しているのか？これらのスパイクはどこから来ていますか? トラフィックのバースト？どのページで？常にどのようなリクエストが実行されていますか? トラブルシューティングを続けるには、もっと情報が必要だと思います。実行時間の長いリクエストやその他の問題がある場合、ログには表示されません (ただし、管理者でそのオプションをチェックしています)。どのリクエストがこれらのスパイクの原因であるかを正確に知る必要があります。どんな助けでも大歓迎です。ありがとう。
〜日