Потоки Apache Tomcat в состоянии ожидания со 100% загрузкой процессора - PullRequest
Новая
       12

Потоки Apache Tomcat в состоянии ожидания со 100% загрузкой процессора

5 голосов
/ 23 сентября 2010

Приложение, когда оно подвергается нагрузке, иногда использует 100%.

при выполнении kill -quit <pid> 1100+ потоков находились в состоянии ожидания как: 

Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode):

"http-8080-1198" daemon prio=10 tid=0x00007f17b465c800 nid=0x2061 in Object.wait() [0x00007f1762b6e000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00007f17cb087890> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458)
        - locked <0x00007f17cb087890> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484)
        at java.lang.Thread.run(Thread.java:619)

"http-8080-1197" daemon prio=10 tid=0x00007f17b465a800 nid=0x2060 in Object.wait() [0x00007f1762c6f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00007f17cb14f460> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458)
        - locked <0x00007f17cb14f460> (a org.apache.tomcat.util.net.JIoEndpoint$Worker)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484)
        at java.lang.Thread.run(Thread.java:619)
............

Состояние не меняется, даже если контекст приложения не развернут ИЛИ БД не перезапущена.

Пожалуйста, предложите вероятную причину.

Сервер приложений: Apache Tomcat 6.0.26

Макс. Потоков: 1500

Темы в состоянии ОЖИДАНИЯ: 1138

Ответы [ 2 ]

4 голосов
/ 24 сентября 2010

«Ожидание на » не является проблемой. Поток ожидает уведомления - и в этом случае он заблокирован на JIoEndpoint.Worker

Фоновая нить, которая слушает входящие TCP / IP соединения и руки их на соответствующий процессор.

Так что я думаю, что это ожидание реальных запросов.

Во-первых, загрузка ЦП фактически увеличивается, когда у вас много потоков из-за большого количества переключений контекста . Вам действительно нужно 1500? Можете ли вы попробовать уменьшить?

Во-вторых, это слишком частая или слишком частая память?

"ожидание для " будет проблемой, если вы их увидите. У вас есть BLOCKED (на объектном мониторе) или ожидающий блокировки () в трассировке стека?

0 голосов
/ 24 сентября 2010

В системе Solaris вы можете использовать команду 

prstat -L -p <pid> 0 1 > filename.txt

Это даст вам разбивку каждого процесса, выполняющего работу на ЦП, и будет основано на ID процессора облегченного веса, а не на PID. Когда вы смотрите на дамп потока, вы можете сопоставить легкий процесс с вашим NID (или TID в зависимости от реализаций), которые показаны в верхней строке дампа потока. Сопоставив эти две вещи, вы сможете определить, какие из ваших потоков являются нагрузкой на процессор.

Вот пример вывода. 

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU   PROCESS/LWPID
   687 user      1024M  891M sleep   59    0   0:40:07 12.0% java/5
   687 user      1024M  891M sleep   59    0   0:34:43 15.3% java/4
   687 user      1024M  891M sleep   59    0   0:17:00 7.6%  java/3
   687 user      1024M  891M sleep   59    0   1:00:07 31.4% java/2

Затем с соответствующим дампом потока вы можете найти эти темы 

"GC task thread#0 (ParallelGC)" prio=3 tid=0x00065295 nid=0x2 runnable
"GC task thread#1 (ParallelGC)" prio=3 tid=0x00012345 nid=0x3 runnable
"GC task thread#2 (ParallelGC)" prio=3 tid=0x0009a765 nid=0x4 runnable
"GC task thread#3 (ParallelGC)" prio=3 tid=0x0003456b nid=0x5 runnable

Так что в случае этого случая с высокой загрузкой ЦП проблема была в сборке мусора. Это видно по совпадению nid с полем LWPID

Если это вам поможет, я бы предложил сделать скрипт, который будет выводить ваш prstat и загрузку процессора одновременно. Это обеспечит вам наиболее точное представление вашей заявки.

В соответствии с вашими первыми двумя нитями, @joseK был верным. Эти темы сидят и ждут, чтобы принять запрос от пользователя. Там нет никаких проблем.

...