weblogic.socket.Muxerとは何ですか？

StackOverflow https://stackoverflow.com/questions/1623692

質問

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

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

"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）パフォーマンスに影響しますか？

役に立ちましたか？

解決

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

  

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

     

Javaマルチプレクサには次のものがあります。   特徴：

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

ネイティブマルチプレクサーはプラットフォーム固有を使用します   データを読み取るためのネイティブバイナリ   ソケット。すべてのプラットフォームの大部分   ポーリングするメカニズムを提供します   データ用のソケット。たとえば、Unix   システムは、投票システムと   Windowsアーキテクチャは補完を使用します   ポート。ネイティブが優れている   拡張性   ノンブロッキングスレッドモデル。とき   ネイティブマルチプレクサが使用され、サーバー   固定数のスレッドを作成します   着信の読み取り専用   リクエスト。 BEAでは、   の選択のデフォルト設定   ネイティブIOを有効にするパラメータ   サーバーを自動的に許可します   に適切なマルチプレクサを選択します   使用するサーバー。

     

ネイティブIOを有効にするパラメータが   選択されていない、サーバーインスタンス   Javaマルチプレクサを排他的に使用します。この   小さい場合は多分許容   クライアント数とレート   サーバーに到着するリクエストは   かなり高い。これらの条件下で、   Javaマルチプレクサは、   ネイティブマルチプレクサーとJavaネイティブの排除   インターフェース（JNI）のオーバーヘッド。とは異なり   ネイティブマルチプレクサ、スレッド数   リクエストの読み取りに使用されるものは固定されていません。   によってJavaマルチプレクサーを調整可能   パーセントソケットリーダーの構成   のパラメータ設定   管理コンソール。 変更を参照してください。   利用可能なソケットの数   読者。理想的には、構成する必要があります   このパラメーターの数   スレッドの数はおおよそ   リモート同時接続クライアント   合計スレッドプールの最大50％   サイズ。各スレッドは修正されるまで待機します   データになる時間   ソケットで利用可能。データがない場合   到着し、スレッドは次へ移動します   ソケット。

これらの理由から、明らかにネイティブマルチプレクサを使用する方が良いでしょう。

ここでは、Javaマルチプレクサ（ weblogic.socket.SocketMuxer）ではなく、デフォルトのネイティブマルチプレクサ（ weblogic.socket.EPollSocketMuxer ）を使用しているようです。

他のヒント

特定のアプリケーションサーバーの場合、スレッドダンプには、数千ではないにしても数百のバックグラウンドスレッドが表示されます。これらのサーバーは複雑な獣であり、これらのスレッドはその役割を果たしている単なる背景配管です。

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

ほとんど心配する必要はありません。岩の下を見ると、日光の下で点滅しているいものがいくつか見つかるはずです。

所属していません StackOverflow
scroll top