weblogic.socket.Muxer использует 100% cpu

Question

Мы недавно начали испытывать развертывания в Weblogic 12c с помощью утилиты weblogic.Deployer. Мы можем развернуть EAR, но всякий раз, когда мы пытаемся развернуть это приложение с управляемым сервером, он начнет использовать 100% нашего процессора (4-х ядерный Xeon, bare-metal).

После некоторых мастерингов и бесчисленных отвалов резьбы мы можем изолировать проблему на 4 застрявших резьбах. Каждый из них потреблял 100% на ядре. Среднее значение нагрузки скачкообразно скачкообразно скачкообразно от 0.10 до 4.00 за 5 минут.

Это нити, кажется, застрял:

"ExecuteThread: '3' for queue: 'weblogic.socket.Muxer'" daemon prio=10 tid=0x00007fb52801c800 nid=0x6bf0 runnable [0x00007fb58a0ad000] 
    java.lang.Thread.State: RUNNABLE 
     at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 
     at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) 
     at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) 
     at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) 
     - locked <0x00000000e18c66d0> (a sun.nio.ch.Util$2) 
     - locked <0x00000000e18c66c0> (a java.util.Collections$UnmodifiableSet) 
     - locked <0x00000000e18c6598> (a sun.nio.ch.EPollSelectorImpl) 
     at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) 
     at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102) 
     at weblogic.socket.NIOSocketMuxer.selectFrom(NIOSocketMuxer.java:541) 
     at weblogic.socket.NIOSocketMuxer.processSockets(NIOSocketMuxer.java:470) 
     at weblogic.socket.SocketReaderRequest.run(SocketReaderRequest.java:30) 
     at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:43) 
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:147) 
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:119) 

Я, кажется, много людей с такой же проблемой (не с Weblogic, хотя):

https://github.com/netty/netty/issues/327

https://issues.jboss.org/browse/XNIO-172

Why does select() consume so much CPU time in my program?

Я не думаю, что это может произойти из-за старой версии JDK. java -version говорит:

java version "1.7.0_67" 
Java(TM) SE Runtime Environment (build 1.7.0_67-b01) 
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) 

Я гугл немного, но ничего не нашел по этому поводу. Знаете ли вы, эксперты WL, что может быть причиной этой проблемы?

Большое спасибо!

Answer 1

После долгих перерывов, почти бессонных ночей и гуглинга, пока я не истекал кровью, я почти уверен, что решил.

Это решение в значительной степени основывается на другом потоке: https://stackoverflow.com/a/7827952/1484232

Суммируя всю хижину, GC потоки столкновений (скорее всего) вызывали вопросы здесь. После применения некоторых параметров к моей виртуальной машине это было волшебным решением.

-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:ParallelCMSThreads=2 
-XX:+CMSParallelRemarkEnabled 
-XX:+CMSIncrementalMode 
-XX:+CMSIncrementalPacing 
-XX:CMSFullGCsBeforeCompaction=1 
-XX:+CMSClassUnloadingEnabled 
-XX:CMSInitiatingOccupancyFraction=80 

Если у кого-либо такая же проблема, это может быть использовано как попытка снова заставить работу работать.

Cheers.

Answer 2

Я столкнулся с той же проблемой. мне удалось решить, используя следующие параметры:

1. Использование Posix: мультиплексор

set('MuxerClass', 'weblogic.socket.PosixSocketMuxer') 

См Weblogic tunning

2. Добавить аргументы запуска:

-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider -DUseSunHttpHandler=true 

• солнечный.nio.ch.PollSelectorProvider использует Linux опрос вместо epoll_wait

• -DUseSunHttpHandler = верно обходит с использованием протокола HTTP сокета WebLogic

Answer 3

Это известная проблема с Weblogic 12с, и публикуется как следующий документ Oracle Support:

Ошибка в производительности из-за использования weblogic.socket.NIOSocketMuxer в WLS 12.1.2+ (Doc ID 212803 2.1) (link)

Обходной путь - это переход на использование родного Muxer-класса, как описано в ответе Omar MEBARKI.

В статье не рассматриваются никакие или другие обходные пути, упомянутые в других ответах здесь.