12

WebLogic 8.1でweblogic.socket.Muxerが何に使用されているかを理解している人はいますか？

多くの場合、スレッドダンプでは、次のようなスタックトレースが表示されます。

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=20 idx=0x68 tid=26709 prio=5 alive, in native, blocked, daemon
    -- Blocked trying to get lock: java/lang/String@0x2b673d373c50[fat lock]
    at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
    at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1675)[optimized]
    at jrockit/vm/Locks.lockFat(Locks.java:1776)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
    at jrockit/vm/Locks.monitorEnter(Locks.java:2439)[optimized]
    at weblogic/socket/EPollSocketMuxer.processSockets(EPollSocketMuxer.java:153)
    at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)
    at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)
    at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)
    at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

それは私がそれに問題を抱えているということではありません、それは理解するのがただ興味をそそられます：

1）それは何をしているのですか？
2）パフォーマンスに影響を与える可能性はありますか？

4

3 に答える 3

9

ドキュメントから ( http://download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246 ):

WebLogic Server は、マルチプレクサと呼ばれるソフトウェア モジュールを使用して、サーバ上の着信リクエストとクライアント上の着信応答を読み取ります。これらのマルチプレクサには、主に Java マルチプレクサまたはネイティブ マルチプレクサの 2 つのタイプがあります。

Java マルチプレクサには、次の特性があります。

  • 純粋な Java を使用してソケットからデータを読み取ります。
  • また、RMI クライアントで使用できる唯一のマルチプレクサでもあります。
  • ソケットから読み取るデータが存在するまで読み取りをブロックします。この動作は、多数のソケットがある場合や、データがソケットに頻繁に到着しない場合には、適切にスケーリングされません。これは通常、クライアントにとっては問題になりませんが、サーバーにとっては大きなボトルネックになる可能性があります。

ネイティブ マルチプレクサは、プラットフォーム固有のネイティブ バイナリを使用して、ソケットからデータを読み取ります。すべてのプラットフォームの大部分は、データのソケットをポーリングするメカニズムを提供します。たとえば、Unix システムはポーリング システムを使用し、Windows アーキテクチャは完了ポートを使用します。ネイティブはノンブロッキング スレッド モデルを実装しているため、優れたスケーラビリティを提供します。ネイティブ マルチプレクサを使用する場合、サーバーは着信要求の読み取り専用の一定数のスレッドを作成します。BEA Enable Native IOでは、サーバが使用する適切なマルチプレクサをサーバが自動的に選択できるように、パラメータに selected のデフォルト設定を使用することをお勧めします。

パラメータが選択されていない場合Enable Native IO、サーバー インスタンスは Java マルチプレクサを排他的に使用します。クライアント数が少なく、リクエストがサーバーに到着する速度がかなり高い場合は、これで問題ない可能性があります。これらの条件下では、Java マルチプレクサはネイティブ マルチプレクサと同様に機能し、Java Native Interface (JNI) のオーバーヘッドを排除します。ネイティブ マルチプレクサとは異なり、リクエストの読み取りに使用されるスレッドの数は固定されておらずPercent Socket Readers 、管理コンソールでパラメータ設定を構成することによって Java マルチプレクサ用に調整できます。使用可能なソケット リーダーの数の変更を参照してください。. 理想的には、スレッドの数が、合計スレッド プール サイズの最大 50% までのリモート同時接続クライアントの数とほぼ等しくなるように、このパラメーターを構成する必要があります。各スレッドは、ソケットでデータが使用可能になるまで一定時間待機します。データが到着しない場合、スレッドは次のソケットに移動します。

これらの理由から、ネイティブ マルチプレクサを使用する方が明らかに優れています。

ここでweblogic.socket.EPollSocketMuxerは、Java マルチプレクサ ( weblogic.socket.SocketMuxer).

于 2009-10-26T11:00:19.867 に答える
7

状況をかなり説明したこのリンクを見つけました：

ソケット マルチプレクサは、サーバーの既存のソケット接続を管理します。最初に、処理待ちの着信要求があるソケットを判別します。次に、プロトコルを決定するのに十分なデータを読み取り、プロトコルに基づいて適切なランタイム レイヤーにソケットをディスパッチします。ランタイム層では、ソケット マルチプレクサ スレッドが使用する実行スレッド キューを決定し、それに応じて要求を委譲します。

于 2009-10-26T09:30:04.393 に答える
5

どのアプリケーション サーバーでも、スレッド ダンプは数千とは言わないまでも数百のバックグラウンド スレッドを示します。これらのサーバーは複雑な獣であり、これらのスレッドはその仕事を行うバックグラウンドの配管にすぎません。

「マルチプレクサ」は、複数のデータ ストリームを 1 つのチャネルに結合するためのメカニズムであるマルチプレクサです。Weblogic はこれらを使用して、Weblogic 自体またはクラスタ内の他のノードとデータを交換します。いつでも、何の関係もないため、それらの多くは「ブロック」されます。

心配する必要はほぼありません。岩の下を見ると、太陽の下でまばたきをしているいくつかの醜いものが見つかるはずです.

于 2009-10-26T09:29:47.727 に答える