Странное использование процессора: 100%, но температура ненормально низкая - PullRequest
Новая
       3

Странное использование процессора: 100%, но температура ненормально низкая

2 голосов
/ 11 февраля 2020

Я столкнулся со странным поведением с моим алгоритмом / процессором, мне было интересно, что может быть причиной этого.

Процессор, который я использую: AMD 2990WX 32c / 64t, ОС: Ubuntu 18.04LTS с ядром 4.15.0-64-generi c.

Алгоритм (Julia 1.0.3): 

@sync @distributed for var in range(0.1,step=0.1,stop=10.0)
                       res=do_heavy_stuff(var) #solves differential equation,
                                               #basically, multiplying 200x200 matrices many times
                       save(filename,"RES",res)
end

Функция do_heavy_stuff (var) Требуется ~ 3 часа, чтобы решить на одном ядре процессора. Когда я запускаю его параллельно с 10 процессами ( julia -p 10 my_code.jl ), это занимает ~ 4 часа для каждой параллели l oop, то есть каждые 4 часа я получаю 10 сохраненных файлов. Ожидается замедление, так как частота процессора снижается с 4,1 ГГц до 3,4 ГГц.

Если я запускаю 3 отдельных экземпляра с 10 процессами в каждом, так что общее использование процессора составляет 30 ядер, это все равно занимает ~ 4 часа для один цикл l oop, означающий, что я выполняю 30 запусков, которые выполняются и сохраняются каждые 4 часа.

Однако, если я запускаю 2 экземпляра (один имеет значение 0, другой - +10) с 30 процессами каждый раз julia -p 30 my_code.jl , я вижу (используя htop), что загрузка ЦП составляет 60 (+) потоков, но алгоритм становится чрезвычайно медленным (через 20 часов все равно сохраняется ноль файлов). Кроме того, я вижу, что температура процессора аномально низкая (~ 45 C вместо ожидаемых 65 C).

Из этой информации я могу догадаться, что использование (почти) всех потоков моего процессора заставляет его делать что-то бесполезное, что поглощает циклы процессора, но никаких операций с плавающей запятой не выполняется. Я не вижу ввода-вывода для SSD, я использую только половину оперативной памяти.

Я запустил mpstat mpstat -A : https://pastebin.com/c19nycsT, и я вижу, что все мои ядра просто простаивают в нерабочем состоянии, что объясняет низкую температуру, однако я до сих пор не понимаю что именно является узким местом? Как мне устранить неполадки? Есть ли способ увидеть (не касаясь аппаратного обеспечения), является ли проблема пропускной способностью ОЗУ или чем-то еще?

РЕДАКТИРОВАТЬ: До меня дошло, что я неправильно использовал mpstat. Очевидно, mpstat -A дает статистику процессора с момента запуска компьютера, в то время как мне были нужны кратковременные интегрированные результаты, которые можно получить с помощью mpstat -P ALL 2 . К сожалению, я узнал об этом только после того, как убил свой код, о котором идет речь, поэтому реальных данных из mpstat нет. Тем не менее, мне все еще интересно, как можно было бы устранить такую ​​ситуацию, когда ядра, кажется, что-то делают, но результат не показывает? Как мне найти узкое место?

1 Ответ

0 голосов
/ 15 февраля 2020

Поскольку вы используете многопроцессорность, есть две наиболее вероятные причины поведения наблюдателя:

  • длительные задержки при вводе / выводе. Когда вы обрабатываете много дисковых данных или считываете данные из сети, ваши процессы естественным образом блокируются. В этом случае загрузка ЦП может быть низкой в ​​сочетании с длительным временем выполнения.
  • высокая дисперсия времени выполнения для do_heavy_stuff. Эта разница может возникнуть из-за нестабильного ввода-вывода или разных параметров модели, что приводит к разному времени выполнения Почему это проблема, требует понимания того, как @distributed распределяет рабочую нагрузку между рабочими процессами. А именно, каждый работник получает сумму, равную for l oop. Например, если у вас есть 4 рабочих, первый получает var в диапазоне 0.1:0.1:2.5, второй 2.6:0.1:5.0 и так далее. Теперь, если некоторые значения var приводят к тяжелым задачам, первый рабочий может получить 5 часов работы, а другие рабочие - 1 час работы. Это означает, что @sync завершается через 5 часов, когда фактически все время работает только один процессор.

Глядя на ваш пост, я бы настоятельно поспорил по второй причине.

...