Проверять процессорные состязания на одном ядре, используя данные в реальном времени в GC? - PullRequest
Новая
       36

Проверять процессорные состязания на одном ядре, используя данные в реальном времени в GC?

0 голосов
/ 21 января 2019

У меня есть устройство с ARMv7 Cortex-A8 (1 Core , 13-pipeline depth) и 512M работает более 250 потоков; Однако средняя загрузка топ-команд, по-видимому, либо ниже 1, либо немного выше 1,5 [1].

При использовании vmstat [2] я вижу, что procs (r) часто оказывается очень высоким по сравнению с ядрами, имеющимися на устройстве [2], в данном случае это всего лишь одноядерный процессор.

При профилировании коллекции GC на одном из процессов, запущенных на устройстве, я получаю следующее [3] :, Интересно отметить, что в реальном времени значительно выше по сравнению со временем (пользователь + sys); Так, например, GC, как сообщается, потребляет 226 миллисекунд, тогда как в реальном времени - 230 миллисекунд.

Учитывая следующее: Правильно ли предположить, что устройство страдает от процессора Если так, то отразится ли конфликт ЦП на средней нагрузке при использовании top? Является ли средняя нагрузка сверху хорошим показателем конфликтов процессора, вызванных потоками? Что еще может привести к большим значениям для proms -r vmstat? 

[3]
2019-01-21T10:18:55.607+0000: 78.012: [GC (Allocation Failure) 2019-01-21T10:18:55.608+0000: 78.013: [DefNew: 5632K->576K(5632K), 0.2220500 secs] 13789K->9541K(17928K), 0.2260043 secs] [Times: user=0.06 sys=0.00, real=0.23 secs]

2019-01-21T10:26:18.394+0000: 520.799: [GC (Allocation Failure) 2019-01-21T10:26:18.396+0000: 520.801: [DefNew: 9423K->601K(9792K), 0.1988650 secs] 30450K->21806K(31360K), 0.2060742 secs] [Times: user=0.07 sys=0.00, real=0.21 secs]

2019-01-21T10:19:51.661+0000: 134.066: [GC (Allocation Failure) 2019-01-21T10:19:51.663+0000: 134.068: [DefNew: 9560K->766K(9792K), 0.3196409 secs] 22499K->13926K(31360K), 0.3309429 secs] [Times: user=0.04 sys=0.02, real=0.33 secs] 


[1]
//Top
top - 10:40:04 up  1:58,  8 users,  load average: 1.66, 1.23, 1.64
Threads: 251 total,   3 running, 248 sleeping,   0 stopped,   0 zombie

[2]
Vmsatat 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0      0  16136  22012 232432    0    0     0     0 1614 3670 40 35 26  0  0
 3  0      0  21740  22012 232444    0    0     0     0 2576 5744 61 39  0  0  0
 0  0      0  21628  22012 232448    0    0     0     0 2006 4809 52 22 26  0  0
 0  0      0  21740  22012 232448    0    0     0     0  595  843  5  8 87  0  0
 3  0      0  21740  22012 232448    0    0     0     0  140  309  2  4 94  0  0
 0  0      0  21740  22036 232448    0    0     0   116  220  349  8  3 89  0  0
 2  0      0  21740  22036 232448    0    0     0     0  125  282  2  3 95  0  0
 0  0      0  21740  22036 232448    0    0     0     0  129  280  2  4 94  0  0
 1  0      0  21740  22036 232448    0    0     0     0  127  266  3  3 94  0  0
 0  0      0  21740  22036 232448    0    0     0     4  145  315  3  3 94  0  0
 2  0      0  18988  22036 232448    0    0     0     0 1619 3888 43 38 19  0  0
 2  0      0  24592  22040 232444    0    0     0    36 2315 5472 64 36  0  0  0
 0  0      0  24480  22040 232444    0    0     0     0 1766 4273 51 23 26  0  0
 0  0      0  24512  22040 232444    0    0     0     0  658 1033  6  7 87  0  0
 0  0      0  24544  22040 232444    0    0     0     0  163  353  1  4 95  0  0
 0  0      0  24544  22040 232444    0    0     0     0  122  242  3  3 94  0  0
 1  0      0  24544  22040 232444    0    0     0     0  142  304  1  4 95  0  0
 0  0      0  24544  22040 232444    0    0     0     0  137  294  2  4 94  0  0
 0  0      0  24544  22040 232444    0    0     0     0  137  276  3  4 93  0  0
 0  0      0  24544  22040 232444    0    0     0     0  134  308  3  2 95  0  0
 9  0      0  19080  22040 232448    0    0     0     0 1952 4268 42 37 20  0  0
 1  0      0  24460  22040 232456    0    0     0     0 2058 4523 65 35  0  0  0
 2  0      0  24560  22040 232452    0    0     0     0 3057 7385 58 42  0  0  0

1 Ответ

0 голосов
/ 21 января 2019

Средняя загрузка Linux представляет (грубо говоря) количество процессов или потоков в очередях процессов операционной системы в R, D или (исторически) W состояниях.

Является ли средняя нагрузка на top хорошим показателем конфликта ЦП из-за потоков?

Не обязательно.

  1. Это может быть вызвано процессами, а не потоками.
  2. Состояние D означает, что процесс ожидает "необратимого" ввода-вывода: обычно это операция файловой системы.Поэтому, если вы обращаетесь к медленной файловой системе (например, к сетевому файловому серверу, который сильно загружен), это может увеличить среднюю загрузку.

Что еще может вызвать высокие значения дляvmstat 1028 * считать?

В соответствии с ручной записью vmstat, столбец r фактически является числом процессов (или потоков) в состоянии R.Столбец d - это количество процессов в состоянии D.Обратите внимание, что это мгновенные показатели, а не средние.

Итак, ответ - процессы.

Еще одна вещь, которую следует отметить, - это то, что JVM может приостановить все потоки приложения (дляпроцесс) во время работы ГХ.В зависимости от реализации GC эта приостановка может быть на время выполнения GC или только для определенных фаз.

Таким образом, ваше наблюдение о том, что время ЦП и время на ГХ практически одинаковы, не означает, что отсутствует конфликт ЦП.

И наоборот, существенное расхождение между временем ЦП и временем ГХне обязательно означает, что существует конфликт ЦП (с потоками приложения или другими процессами).Другая возможность - конфликт за (реальные) страницы памяти;то есть виртуальная память бьется.

...