Weblogic.socket.muxer 란 무엇입니까?

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

문제

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) 성능에 영향을 줄 수 있습니까?

도움이 되었습니까?

해결책

문서에서 (http://download.oracle.com/docs/cd/e13222_01/wls/docs100/perform/wlstuning.html#wp1152246):

Weblogic Server는 Muxers라는 소프트웨어 모듈을 사용하여 서버에서 들어오는 요청과 클라이언트의 수신 응답을 읽습니다. 이 muxers는 Java Muxer 또는 Native Muxer의 두 가지 주요 유형입니다.

Java Muxer에는 다음과 같은 특성이 있습니다.

  • 순수한 Java를 사용하여 소켓에서 데이터를 읽습니다.
  • 또한 RMI 클라이언트가 사용할 수있는 유일한 muxer입니다.
  • 소켓에서 읽을 데이터가있을 때까지 읽기의 블록. 이 동작은 소켓이 많거나 소켓에서 데이터가 드물게 도착할 때 확장되지 않습니다. 이것은 일반적으로 클라이언트에게는 문제가되지 않지만 서버에 대한 막대한 병목 현상을 만들 수 있습니다.

Native Muxers는 플랫폼 별 네이티브 바이너리를 사용하여 소켓의 데이터를 읽습니다. 모든 플랫폼의 대부분은 데이터 용 소켓을 투표하는 메커니즘을 제공합니다. 예를 들어, UNIX 시스템은 폴링 시스템을 사용하고 Windows 아키텍처는 완료 포트를 사용합니다. 네이티브는 비 차단 스레드 모델을 구현하기 때문에 우수한 확장 성을 제공합니다. 기본 Muxer가 사용되면 서버는 들어오는 요청을 읽는 데 전용 된 고정 된 수의 스레드를 만듭니다. BEA는 선택한 기본 설정을 사용하는 것이 좋습니다. Enable Native IO 서버가 서버가 사용할 적절한 muxer를 자동으로 선택할 수있는 매개 변수.

만약 Enable Native IO 매개 변수가 선택되지 않으며 서버 인스턴스는 독점적으로 Java Muxer를 사용합니다. 클라이언트가 적고 요청이 서버에 도착하는 속도가 상당히 높으면 허용 될 수 있습니다. 이러한 조건에서 Java Muxer는 기본 Muxer뿐만 아니라 JNI (Java Native Interface) 오버 헤드를 제거합니다. 기본 Muxers와 달리 요청을 읽는 데 사용되는 스레드 수는 고정되지 않았으며 Percent Socket Readers관리 콘솔의 매개 변수 설정. 보다 사용 가능한 소켓 리더 수 변경. 이상적으로는이 매개 변수를 구성하여 스레드 수는 총 스레드 풀 크기의 최대 50%까지 동시에 연결된 원격 클라이언트 수와 거의 같습니다. 각 스레드는 소켓에서 데이터를 사용할 수 있도록 고정 된 시간을 기다립니다. 데이터가 없으면 스레드가 다음 소켓으로 이동합니다.

그런 이유로, 기본 뮤저스를 사용하는 것이 분명히 낫습니다.

여기에서는 기본 기본 Muxer를 사용하는 것처럼 보입니다.weblogic.socket.EPollSocketMuxer), Java Muxer가 아닙니다 (weblogic.socket.SocketMuxer).

다른 팁

나는 찾았다 이 링크 상황을 거의 설명했습니다.

소켓 Muxer는 서버의 기존 소켓 연결을 관리합니다. 먼저 처리를 기다리는 소켓이 들어있는 소켓이 결정됩니다. 그런 다음 프로토콜을 결정하기에 충분한 데이터를 읽고 프로토콜을 기반으로 소켓을 적절한 런타임 계층으로 발산합니다. 런타임 레이어에서 소켓 Muxer 스레드는 사용할 스레드 큐를 실행하고 그에 따라 요청을 위임합니다.

주어진 응용 프로그램 서버의 경우 스레드 덤프는 수천 개의 배경 스레드를 보여줍니다. 이 서버는 복잡한 짐승 이며이 스레드는 그 작업을 수행하는 배경 배관 일뿐입니다.

"muxer"는 멀티플렉서이며, 이는 여러 데이터 스트림을 단일 채널에 결합하는 메커니즘입니다. Weblogic은 이것들을 사용하여 데이터를 자체 또는 클러스터의 다른 노드와 교환합니다. 주어진 시간에, 많은 사람들이 할 일이 없기 때문에 많은 사람들이 "차단"될 것입니다.

걱정할 이유가 거의 없습니다. 바위 아래를 보면 햇빛 속에서 당신을 깜박 거리는 몇 가지 추악한 것들을 찾아야합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top