LINUX.ORG.RU
решено ФорумAdmin

Значительный CPU idle time при высоком LA

 , ,


0

2

Столкнулся с интересным поведением, имеется сервер на котором крутится множество java процессов, 2 CPU 10 ядер в каждом + HyperThreading итого 40 ядер видно в Linux

Load average 75-100, при этом local io практически отсутствует, и никто не застрял в uninterruptible sleep, при всем при этом довольно значительный idle time в vmstat.

Проверим, что количество runnable потоков примерно соответствует load average:

$ ps  Hh -eo stat,pid,command |egrep '^R' |wc -l
109

В разные моменты выдает разные значения понятное дело, но всегда в интервале 60-120

вывод mpstat -P ALL 1 (поймал момент, когда idle минимальный, обычно 10-13):

12:20:23     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:20:24     all   89.38    0.00    2.12    0.00    0.95    0.00    0.00    0.00    7.55
12:20:24       0   78.79    0.00    4.04    0.00   10.10    0.00    0.00    0.00    7.07
12:20:24       1   98.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00    1.01
12:20:24       2   88.12    0.00    1.98    0.00    0.99    0.00    0.00    0.00    8.91
12:20:24       3   94.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    4.00
12:20:24       4   89.90    0.00    1.01    0.00    0.00    0.00    0.00    0.00    9.09
12:20:24       5   91.09    0.00    3.96    0.00    0.99    0.00    0.00    0.00    3.96
12:20:24       6   99.01    0.00    0.99    0.00    0.00    0.00    0.00    0.00    0.00
12:20:24       7   97.03    0.00    0.99    0.00    0.00    0.00    0.00    0.00    1.98
12:20:24       8   98.02    0.00    0.99    0.00    0.99    0.00    0.00    0.00    0.00
12:20:24       9   97.03    0.00    0.99    0.00    0.00    0.00    0.00    0.00    1.98
12:20:24      10   90.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    9.00
12:20:24      11   94.00    0.00    3.00    0.00    0.00    0.00    0.00    0.00    3.00
12:20:24      12   86.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00   12.00
12:20:24      13   97.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    2.00
12:20:24      14  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
12:20:24      15   95.96    0.00    1.01    0.00    0.00    0.00    0.00    0.00    3.03
12:20:24      16   98.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    0.00
12:20:24      17   91.92    0.00    5.05    0.00    0.00    0.00    0.00    0.00    3.03
12:20:24      18   94.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    5.00
12:20:24      19   97.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00    1.00
12:20:24      20   83.00    0.00    3.00    0.00   10.00    0.00    0.00    0.00    4.00
12:20:24      21   82.83    0.00    4.04    0.00    7.07    0.00    0.00    0.00    6.06
12:20:24      22   98.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00    1.01
12:20:24      23   88.00    0.00    2.00    0.00    9.00    0.00    0.00    0.00    1.00
12:20:24      24   94.00    0.00    4.00    0.00    0.00    0.00    0.00    0.00    2.00
12:20:24      25   77.23    0.00    2.97    0.00    0.00    0.00    0.00    0.00   19.80
12:20:24      26   77.23    0.00    3.96    0.00    0.00    0.00    0.00    0.00   18.81
12:20:24      27   63.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00   36.00
12:20:24      28   91.92    0.00    1.01    0.00    0.00    0.00    0.00    0.00    7.07
12:20:24      29   83.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00   15.00
12:20:24      30   84.85    0.00    1.01    0.00    0.00    0.00    0.00    0.00   14.14
12:20:24      31   95.00    0.00    3.00    0.00    0.00    0.00    0.00    0.00    2.00
12:20:24      32   88.00    0.00    3.00    0.00    0.00    0.00    0.00    0.00    9.00
12:20:24      33   97.98    0.00    2.02    0.00    0.00    0.00    0.00    0.00    0.00
12:20:24      34   76.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00   22.00
12:20:24      35   83.17    0.00    2.97    0.00    0.00    0.00    0.00    0.00   13.86
12:20:24      36   73.00    0.00    3.00    0.00    1.00    0.00    0.00    0.00   23.00
12:20:24      37   86.00    0.00    5.00    0.00    0.00    0.00    0.00    0.00    9.00
12:20:24      38   83.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00   16.00
12:20:24      39   92.00    0.00    4.00    0.00    0.00    0.00    0.00    0.00    4.0

что это может быть? грешу на scheduler, но непонятно как его крутить, чтобы он успевал занимать CPU под задачи. Не очень приято терять 10% CPU на задаче, которая как раз очень жадная до этого CPU.

Ответ на: комментарий от redbaron

эти процессы изолированы от всего, ничего не используют в качестве входных данных, ничего не выдают, только пожирают CPU ?

IMHO iowait это только ожидание дисковых операций, а ожидание семафоров/футексов/сетевой ввод/вывод туда не входят и отображаются они в idle

Так что шедулер тут вряд ли виноват.

strace на жабовский процесс может показать на чем он простаивает.

vel ★★★★★
()
Ответ на: комментарий от vel

Ожидание семафоров/фьютексов и прочего снимает процесс из run queue, в моем же случае все выглядит странно:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
58  0 989612 624692 360196 137462848    0    0  7348   166 31164 43810 81  4 15  0
113  0 989612 654188 360048 137342544    0    0  7104  1140 21751 49745 81  5 14  0

смотри первую (run queue) и предпоследнюю (cpu idle) колонки,я не могу разобраться, как при таком количестве желающих повыполняться на CPU, этот самый CPU находит время простаивать.

redbaron ★★
() автор топика
Ответ на: комментарий от redbaron

футекс, мне кажется, отжирает весь таймслайс выделенный на процесс. Надо будет почитать, как оно работает... А вот семафор да, снимает процесс с рабочих

vova7890 ★★★
()
Ответ на: комментарий от vel

Это scheduller 100%, вот объяснение почему он часто может решить оставить некоторые процессоры idle: http://lwn.net/Articles/80911/

Если вкратце, он может решить, что мигрировать процесс на другой CPU дороже (в долгосрочной перспективе), чем подождать пока текущий CPU освободится.

Проверить теорию просто, заменить жабовский GC на SerialGC (-XX:+UseSerialGC), таким образом вместо дефолтных ~30 GC потоков, будет использоваться один. После этой замены, нагрузка с точки зрения системы выглядит как и ожидается:

47  0    765   3915    445 133353    0    0 11904  4566 19066 6758 98  2  0  0
45  0    765   3855    445 133370    0    0 14336   734 19701 6474 97  2  1  0
41  0    765   3781    445 133384    0    0 12636 44932 20179 7746 98  2  0  0
43  0    765   3671    445 133396    0    0  9364   416 18726 6392 98  2  1  0
45  1    765   3569    445 133417    0    0 16392 111160 18962 6050 97  2  1  0
42  0    765   2452    445 133466    0    0 60108  8282 25061 8642 97  3  1  0
47  0    765   2417    445 133481    0    0 12800  6810 20137 7614 98  2  0  0
46  0    765   2390    445 133495    0    0 11264  3060 17456 8089 97  2  1  0
42  0    765   2315    445 133524    0    0 34300  3140 22078 7422 97  2  1  0

Быстрее ли это с точки зрения времени выполнения конкретной Java задачи вопрос интересный и требует отдельного рассмотрения

redbaron ★★
() автор топика
Ответ на: комментарий от redbaron

А у тебя NUMA что-ли ? Сочувствую. Там процесс миграции между процессорами действительно может стоить дорого, в отличии от обычной SMP.

Это не кернельные проблемы шедулера - это жабопроблемы.

Если жаба плодит кучу дополнительных процессов с медленной синхронизацией между собой, то даже «умных» шедулер тут не поможет.

Хорошо, если в жабе есть возможность использовать более эффективые способы работы на данной платформе...

vel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.