2

XPages で 30 GB のワークフロー アプリケーションのパフォーマンスを改善することについて、こちらで質問を受け付けています。多くの提案がありましたが、ほとんどはリサイクル、コードの改善などを含み、速度の問題を実際に修正したものはあまり話題になりません-アプリケーションプロパティの詳細タブ（私の最後の投稿を参照）

今、私は非常にうまく動作するアプリケーションを持っています。それは速く、人々は満足していますが、サーバーはまだ定期的にクラッシュしています. または、HTTP が応答しなくなり、極端な場合には 100% の CPU で実行されるため、Domino も動作が遅くなりますが、引き続き実行されます。

私はHTTPスレッドを監視してきました

tell http スレッドの状態を表示

ほとんどの場合、80 個の http スレッドがアイドル状態であるか、何かを実行しているがすぐに解放されます。SSJS でのメモ オブジェクトのリサイクルに重点を置いたアプリケーションへの前回の更新以来、ハングした http スレッドの終了が表示されると思っていましたが、まだそこにあります。

エンドユーザーに確認した2つのケースは完全に異なり、私が知る限りループは存在しないため、この問題の原因が無限ループではないことはほぼ確実です.

  1. ユーザーがドキュメントを編集しているときに、ワークフロー ボタンを押して承認し、次のユーザーに送信します。彼らはChromeを使用しています。クロムタブの回転する円が始まり、サーバーはワークフローエージェントを実行し、電子メールを送信し、ブラウザでページを閉じます。1 時間経っても解放されていないハングした http スレッドが 2 つまたは 3 つあることに気付いたので、ユーザーに連絡したところ、ページは更新されていないが、Chrome で回転する円がまだ回転しているとのことで、サーバーが何かを行っていることを示しています。 . ログを確認したところ、ワークフロー エージェントが実行され、電子メールが送信され、ドキュメントが更新されました。彼女がページを更新すると、ページが更新されていることがわかりますが、何らかの理由で Chrome はそこに座って辛抱強く待っていて、LS エージェントが実行されたというメッセージを受け取りませんでした。notesAgent を使用しています。runOnServer を実行し、結果の整数を返して、エージェントが実行されたかどうかを確認します。1 が返された場合 (私が思うに)、ページは閉じられるはずです。それ以外の場合は、メッセージが表示されます。ページが更新されなかったため、何も表示されませんでしたが、エージェントは完了しました。

  2. 夕方のユーザーは、約 15 の http スレッドがハングしました。ログを見ると、彼女が何度もページをリロードしようとしていたことがわかりました。次に、彼女が必要としているドキュメントを検索し、さらにそれを開こうとしました。彼女がドキュメントを検索したことを確認したところ、検索ページに結果が (繰り返しコントロールで) 表示され、ドキュメントをクリックして開くたびに何も起こりませんでした。そのため、彼女はドキュメントにアクセスすることさえできませんでしたが、試行するたびにスレッドがハングしていました。メモのログから URL を取得して試してみたところ、ドキュメントは正常に開きます。同じ検索を実行しましたが、ドキュメントは正常に開きます。ドキュメントへのリンクを直接彼女に送信すると、問題なく開きます。変！！

この種の動作を診断する方法はありますか? 現在、ドミノ管理者を開いて tell http show.... コマンドを実行し、スレッドがハングしていないことを確認するために一日中監視する必要があるためです。通常、ランチタイムになり、サーバーを再起動する必要がありますが、これはゴミです。

私の正気を助けてください:-)

4

3 に答える 3

1

Java ダンプのいくつかを使用してメモリ リークを分析しました。そこには大量の情報が見つかりましたが、何を探しているのかよくわからないということは、結論が見つからなかったことを意味します。

まったくの偶然で、これらのスレッド ロックをランダムに発生させるシステム内のドキュメントを操作する必要があり、これらのドキュメントが処理されるときに呼び出されるワークフロー エージェントを手動で実行しました。何が起こっているのか理解するのに 1 分ほどかかりましたが、ドキュメントの内容に基づいて MIME メールを生成しようとして、エージェントがループに陥っているように見えました。

スケジュールされたエージェントが Domino で無限ループに陥った場合、管理クライアントのエージェント マネージャーを見るだけで簡単に見つけることができます。常に CPU を消費し、決して終了しないことがわかります。

ただし、XPage がスタックしたエージェントを呼び出した場合、(少なくとも私の場合は) エージェント マネージャーが実行されているという手がかりはなく、HTTP サーバー タスクはそれが異常なことを行っていることを示しません。これが、最初は無限ループはないと思っていた理由ですが、完全に間違っていました!

MIME 電子メール ジェネレーター ルーチンで到達したループの数をカウントするコードを追加し、任意の高い値に達してループに陥ったことを示すブレークを追加しました。ほら！http スレッドがハングアップすることはもうありません。

これは、システム全体を調べて、そこにある古い (貧弱な) コードの一部を修正し、すべてを整理する絶好の口実でした。最終的には、問題を引き起こしたのは xpage ではなくエージェントでした。でも、みんなの提案に感謝します。

于 2015-01-06T15:07:43.443 に答える
0

私が強くお勧めする 2 つのアクションがあります。

  • エージェントを Java ライブラリに変換します。これは思ったよりも手間がかからず、毎回エージェント ランタイムをスピンアップする必要がなくなります (ハングの原因となる可能性があります)。
  • それだけでは不十分な場合は、通知メカニズムを再考する必要があるため、スレッドを使用してください。

Frantisek の洞察を利用する

于 2014-05-29T00:27:44.223 に答える