Was ist weblogic.socket.Muxer?

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

Frage

Hat jemand von euch verstehen, was weblogic.socket.Muxer in WebLogic verwendet wird 8.1?

Oft in Thread-Dumps Ich sehe Stapel Spuren ähnlich wie folgt aus: 

"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

Es ist nicht, dass ich damit keine Probleme haben, es ist intresting nur zu verstehen:

1), was es tut?
2) kann er jede Leistung beeinträchtigen?

War es hilfreich?

Lösung

Aus der Dokumentation ( http: // download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246 ):

  

WebLogic Server verwendet Software-Module   genannt Muxer eingehenden zu lesen   Anfragen auf dem Server und eingehende   Antworten auf dem Client. Diese Muxer   Es gibt zwei Haupttypen: die Java   muxer oder native muxer.

     

Ein Java muxer hat folgende   Merkmale:

     
      
  • Verwendet reine Java-Daten aus Sockets zu lesen.
    •   
  • Es ist auch die einzige muxer für RMI-Clients.
    •   
  • Blocks auf liest, bis Daten von einem Socket zu lesen ist. Dieses Verhalten tritt nicht gut skalieren, wenn es eine große Anzahl von Steckdosen und / oder wenn Daten ankommen selten   an den Buchsen. Dies ist in der Regel kein Problem für Kunden, aber es kann einen großen Engpass für einen Server erstellen.
    •   
     

Native Muxer verwenden plattformspezifische   nativen Binärdateien Daten lesen aus   Steckdosen. Die Mehrheit aller Plattformen   bietet einen Mechanismus zur Abstimmung eines   Buchse für Daten. Zum Beispiel Unix   Systeme nutzen die Umfrage-System und die   Windows-Architektur verwendet Abschluss   Häfen. Einheimische bieten überlegen   Skalierbarkeit, weil sie eine Umsetzung   nicht blockierend Thread-Modell. Wenn ein   nativen muxer verwendet wird, der Server   erzeugt eine feste Anzahl von Threads   zu lesen eingehende gewidmet   Anfragen. BEA empfiehlt die Verwendung von   Standardeinstellung für die ausgewählte von   Enable Native IO Parameter,   kann der Server automatisch   wählt die geeignete muxer für die   Server zu verwenden.

     

Wenn der Enable Native IO Parameter   die Serverinstanz nicht ausgewählt ist,   ausschließlich verwendet die Java muxer. Diese   vielleicht akzeptabel, wenn es ein kleines ist   Anzahl der Clients und die Rate, mit   die Anfragen kommen an dem Server   ziemlich hoch. Unter diesen Umständen,   die Java muxer führt sowie eine   nativen muxer und beseitigen Java Native   Interface (JNI) Overhead. nicht wie   nativer Muxer, die Anzahl der Threads   verwendet, um Anforderungen zu lesen ist nicht festgelegt und   abstimmbar ist für Java Muxer durch   Konfigurieren des Percent Socket Readers   Parametereinstellung in der   Administrationskonsole. Siehe ändern   Die Anzahl der verfügbaren Sockel   Leser . Im Idealfall sollten Sie konfigurieren   diese Parameter, so dass die Anzahl der   Fäden entspricht in etwa der Anzahl der   Fern gleichzeitig verbundene Clients   bis zu 50% des gesamten Thread-Pools   Größe. Jeder Thread wartet auf einen festen   Zeitaufwand für die Daten werden   an einer Steckdose zur Verfügung. Wenn keine Daten   der Faden bewegt sich zum nächsten kommt,   Buchse.

Dann aus diesen Gründen, es ist offensichtlich besser nativer Muxer zu verwenden.

Hier sieht es aus wie Sie die Standard-nativen muxer (weblogic.socket.EPollSocketMuxer) verwenden, nicht die Java muxer (weblogic.socket.SocketMuxer).

Andere Tipps

Ich habe gefunden, Link , die die Situation ziemlich erklärt:

  

Der Socket-Muxer verwaltet die Server   bestehende Socket-Verbindungen. es zuerst   bestimmt, welche Buchsen eingehende haben   Warte Anfragen verarbeitet zu werden. Es   dann liest genügend Daten, um zu bestimmen   Das Protokoll und sendet die Buchse   auf eine geeignete Laufzeitschicht basierend   auf dem Protokoll. In der Laufzeitschicht,   die Buchse muxer Fäden bestimmen   das Ausführen Fadenwarteschlange verwendet werden   und delegiert die Anfrage entsprechend.

Für jeden gegebenen Anwendungsserver, ein Thread-Dump finden Sie Hunderte zeigt, wenn nicht Tausende von Hintergrund-Threads. Diese Server sind komplexe Tiere und diese Fäden sind nur der Hintergrund Sanitär seine Arbeit zu tun.

A „muxer“ ist ein Multiplexer, der zum Kombinieren von mehreren Datenströmen auf einen einzelnen Kanal einen Mechanismus ist. Weblogic werden diese zum Austausch von Daten mit sich selbst oder mit anderen Knoten im Cluster werden. Zu jedem gegebenen Zeitpunkt wird eine Reihe von denen sein „blockiert“, da sie nichts zu tun haben.

Es ist mit ziemlicher Sicherheit kein Grund zur Besorgnis. Wenn Sie unter dem Felsen suchen, sind Sie verpflichtet, ein paar hässlichen Dinge unter Blinken bis auf Sie in der Sonne zu finden.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top