まず、背景を少し説明します。
お客様の 1 人が、当社の Web アプリの 1 つを実行している WebSphere インスタンスで CPU 使用率のスパイクを経験しています (他のアプリを使用する他のインスタンスは問題ありません)。彼らには、テスト環境とライブ環境 (両方とも iSeries) があり、どちらも問題が発生します - インスタンスごとに 1 つのアプリをセットアップします。私たちはこのアプリケーションを私たち自身のテスト環境でローカルに展開しました。また、iSeries 上の他の多くの顧客にも同じような問題は発生しませんでした。
実際に起こっていること:
その時点で処理されている要求がない場合でも、約 17%
秒ごとに、WebSphere プロセスの CPU 使用率の CPU 使用率がどこかにジャンプします。20%
顧客は、最大のスパイクが見られると報告してい30%
ます。これらのスパイクの平均は、アイドル時1.5%
の CPU 全体 (他の WebSphere インスタンスが通常使用するもの0%
)に相当します。0.1%
これまでの私の調査
ということで、スレッドを拝見しました。テスト環境の 1 つのスレッドが、~350
1 秒あたりの CPU サイクルを使用していました。ライブ環境の同様のスレッドは、~1500
1 秒あたりの CPU サイクルを使用していました (より大きな CPU を使用していることを示しています)。これらのスレッドのコール スタックは次のようになります。
Type Program Statement Procedure
QLESPI QSYS 17 LE_Create_Thread2__FP12crtt >
QJVALIBJVM QSYS 7 startThread__FPv
J com/ibm/ws/util/Threa > run
J com/ibm/ws/util/Threa > run
J com/ibm/ws/util/Threa > getTask
J com/ibm/ws/util/Bound > poll
一番下の行からのクラス名全体はcom/ibm/ws/util/BoundedBuffer
. 私は顧客に JVM ダンプを依頼しました。ここから得た唯一の追加情報は、スレッド名でした。
Thread: 00002F82 Deferrable Alarm : 11
今私の質問のために:
- これらの症状を考えると、誰でも問題を特定できますか? (多分それはロングショットです!)
- とは
Deferrable Alarm
? JVM ダンプから、この名前の 4 つのスレッドを確認できます。他の3人は元気そうです。ローカルの WebSphere (Windows 上) をデバッグし、BoundedBuffer
クラスにブレークポイントを追加すると、BoudedBuffer
s がポーリングし、定期的にリスナーを呼び出していることがわかります。 - 私は顧客のマシンの WebSphere コンソールにアクセスすることができません。また、顧客は構成を変更したことを認めていません。コンソールを確認するように依頼することはできますが、何を確認するように依頼すればよいでしょうか?
- カスタマー ボックスに telnet でアクセスできます。他に調査できることはありますか? WebSphere プロファイル ファイルなどを見ていますか? どのファイルを確認する必要がありますか?
- Call Stack と JVM Dump はコードを明示的に参照していないため、これは構成上の問題であると想定しても問題ないでしょうか?
長い質問だったので、ここまで読んでくれてありがとう。
4月30日更新 (1)
今朝、この動作は、その日の最初のリクエストが処理された後にのみ発生することに気付きました (どの Web サービスが呼び出されたかに関係なく)。これは、アプリケーションまたは Apache Axis を指し示しています。これは単なる正常な動作なのでしょうか?!
4月30日更新 (2)
したがって、この CPU アクティビティは、Web コンテナまたは Apache Axis 内の何らかのハウスキーピング アクティビティのようです。私は今、これがいくつかの異なるサーバー上のいくつかの異なる Web アプリケーションで発生していることを確認しました。Web コンポーネントを持たないアプリケーションは、同じように追加の CPU オーバーヘッドに悩まされることはありません。
それがハウスキーピング作業である場合、それを「調整」すると逆効果になる可能性があると思います-つまり、App Serverのアイドル状態を改善すると、実行できる「実際の」作業の量におそらく悪影響を与えることになります.