10

Glassfish 3.0.1 を使用していますが、応答時間が非常に長くなります。POST/PUT リクエストの 25% で 5 分のオーダーで、応答が戻ってくるまでに、前面に面したロード バランサーがタイムアウトになっています。

私の理論は、リクエストがキューに入れられ、利用可能なスレッドを待っているというものです。

これは、アクセス ログでリクエストの完了に数秒かかっていることがわかっているのに、リクエストの実行時間が予想より 5 分遅れていることが原因だと思います。

スレッドプールで何が起こっているかをデバッグするためのアドバイスはありますか? または、それらに最適な設定は何ですか？

定期的にスレッド ダンプを実行する必要がありますか? それとも 1 回限りのダンプで十分ですか?

4

3 に答える 3

6

一見すると、これはスレッドプール自体とはほとんど関係がないように見えます。あなたのネットワーク設定の残りの部分についてよく知らなくても、私がチェックするいくつかのことがあります：

  • ロード・バランサー・プールにデッド/非応答ノードはありますか? これにより、他のノードにリダイレクトされる前に、タイムアウトにより失敗するまで、すべての要求がこのノードに対して試行される可能性があります。
  • ロード バランサーと Glassfish サーバー間の初期接続に問題はありますか? これは、低速または不正確な DNS ルックアップ (サーバーは結果をキャッシュする必要があります)、プロキシの欠落、またはその他のネットワーク関連の問題である可能性があります。
  • マシン間でクロックが同期されていることを確認しましたか? これにより、ログが同期しなくなる可能性があります。5 分というのはかなり奇妙なタイムアウト期間です。

これらすべてが空になった場合は、単にロード バランサーと Web サーバーの間でインピーダンスの不一致が発生している可能性があり、負荷を処理するために Web サーバーを追加する必要がある場合があります。ロード バランサーは、入ってくるトラフィックと、そのトラフィックがどのように積み重なっているかについて、多くの統計情報を提供できるはずです。

于 2012-12-26T17:12:55.467 に答える
3

通常、サーバーで十分なワーカー スレッドを構成していない場合、この動作が発生します。デフォルト値は、一般的な Web サーバーで 15 から 100 スレッドの範囲です。ただし、アプリケーションがサーバーのワーカー スレッドをブロックする場合 (たとえば、クエリを待機することによって)、既定値は頻繁に低すぎます。ワーカーの数を 1000 まで問題なく増やすことができます (64 ビットを保証します)。また、中間サーバー (プロキシや mod_proxy を介した apache 転送など) のワーカースレッド数 (「最大同時/オープン要求」とも呼ばれます) も確認してください。

もう 1 つのよくある落とし穴は、着信要求をブロックしている間に、ソフトウェアが自分自身に要求を送信することです (たとえば、要求を再ルーティングまたは転送しようとする)。

于 2012-12-26T20:59:36.423 に答える
2

スレッドプールで何が起こっているかをデバッグするには、スレッドダンプを取得するのが最善の方法です。各スレッドダンプの間に 1 ～ 2 秒の間隔を空けて、3 ～ 4 個のスレッドダンプを次々に取得してください。

threaddump から、ワーカー スレッドの数を名前で確認できます。複数のスレッドダンプから長時間実行されているスレッドを見つけます。

スレッドダンプの分析には、TDA ツール ( http://java.net/projects/tda/downloads/download/tda-bin-2.2.zip ) を使用できます。

于 2012-12-26T18:42:16.233 に答える