Gpu utilization что это такое
Перейти к содержимому

Gpu utilization что это такое

  • автор:

Потребление ресурсов

Потребление электроэнергии

Чтобы узнать, сколько программа потребляет ОЗУ и насколько эффективно загружает процессорные ядра, можно использовать методы, описанные ниже.

Во время работы программы

Предварительно необходимо выяснить, на каких именно узлах работает задача. Это делается командой ‘qstat -f XXXX‘, где XXXX — номер выполняющейся задачи. Выделенные задаче узлы будут отображаться в строке ‘exec_host’:

user01@clu:~> qstat -f 389182
. exec_host = cn225/0*4+cn226/0*4+cn227/0*4+cn228/0*4 .

В данном случае задача работает на узлах cn225, cn226, cn227 и cn228. ‘0*4’ означает, что на каждом узле выделено по 4 ядра.

Метод 1

Данный способ наиболее нагляден, но применим только в том случае, если вычислительный узел монопольно занят одной задачей.

Открыть веб-интерфейс Ganglia. В левом верхнем углу в поле ‘Choose a Source’ выбрать поле, соответствующее модели используемых узлов:

BL2x220c-G6 для 8-ядерных, с именами cn101-cn196
BL2x220c-G7 для 12-ядерных, с именами cn201-cn296
SL390s-G7 для узлов с GPU, sl001-sl012

В появившемся рядом поле ‘Choose a Node’ выбрать интересующий узел. Будет отображена статистика использования ресурсов за некоторое прошедшее время. В первую очередь надо обращать внимание на использование Memory и CPU. Например, из приведённой ниже картинки видно, что задача, запустившаяся около 14:36, достаточно быстро загрузила все ядра до 90% и стабильно держит нагрузку на этом уровне, а потребление оперативной памяти с момента запуска постепенно увеличивается, и на данный момент (15:15) составляет около 9 ГБ:

Для обновления графиков необходимо нажать кнопку ‘Get Fresh Data’ в правом верхнем углу.

Метод 2

Зайти на используемый узел с помощью команды ‘ssh‘:

user01@clu:~> ssh cn225
user01@cn225:~>

Подобным образом можно зайти только на тот узел, на котором уже выполняется Ваша программа, запущенная планировщиком. Если же зайти на какой-то другой узел, то ssh-сессия будет принудительно закрыта в течении нескольких секунд.

Запустить команду ‘top‘:

user01@cn225:~> top
top - 22:56:25 up 1 day, 10:06, 1 user, load average: 4.43, 4.44, 4.45 Tasks: 349 total, 5 running, 344 sleeping, 0 stopped, 0 zombie Cpu(s): 31.8%us, 0.4%sy, 0.0%ni, 67.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 24684348k total, 23334268k used, 1350080k free, 119680k buffers Swap: 33559776k total, 0k used, 33559776k free, 7100712k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25415 user01 20 0 3835m 3.7g 15m R 101 15.6 293:43.08 fluent_mpi.13.0 25417 user01 20 0 3776m 3.6g 15m R 101 15.3 293:58.96 fluent_mpi.13.0 25416 user01 20 0 3945m 3.8g 15m R 99 16.0 294:04.56 fluent_mpi.13.0 25418 user01 20 0 3961m 3.8g 15m R 99 16.1 293:17.68 fluent_mpi.13.0 9300 root 20 0 27060 8316 1168 S 2 0.0 5:37.87 pbs_mom 1 root 20 0 1064 412 348 S 0 0.0 0:01.92 init 2 root 15 -5 0 0 0 S 0 0.0 0:00.02 kthreadd .

В данном случае видно, что:

Работают 4 процесса пользователя user01, каждый из которых потребляет около 3.7 ГБ ОЗУ (столбец RES) и полностью загружает одно ядро (столбец %CPU).

Всеми процессами (включая операционную систему) на узле суммарно используется 23334268 КБ ОЗУ из имеющихся 24684348 КБ.

Виртуальная память (SWAP) на узле не используется.
Полное потребление памяти, включая виртуальную, отображается в столбце VIRT
Если число в столбце RES не имеет суффикса g или m, то это значение в килобайтах.
Чтобы прервать работу утилиты top, необходимо нажать Ctrl-C

Использование GPU

При выполнении вычислений на графических сопроцессорах cтепень загруженности GPU и памяти видеокарты можно узнать с помощью утилиты ‘nvidia-smi‘. Для этого необходимо:

Определить используемый задачей узел и GPU.

Командой ‘ssh’ зайти с интерфейсного сервера на соответствующий узел и выполнить следующую команду, заменив ‘X’ на идентификатор нужного GPU (или нескольких GPU, через запятую):

nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.free,memory.used --format=csv -i X

При использовании узлов в очереди teslaq в качестве идентификатора GPU можно использовать его порядковый номер (от 0 до 2), определяемый из имени виртуального узла. Например, если интересует нагрузка на GPU задачей с номером 3437445, запросившей два ngpus:

Чтобы узнать выделенные задаче виртуальные узлы, выполнить на интерфейсном сервере:

qstat -f 3437445|tr -d '\n'' ''\t'|sed 's/Hold_Types.*//'|sed 's/.*exec_vnode=//'|tr -d \(\)|tr + '\n'|sed 's/:.*//'|sort

Допустим, эта команда выведет:

sl003[0] sl003[2]

Т.е. задача иcпользует GPU с номерами 0 и 2 на узле sl003.
Выполнить на интерфейсном сервере команду:

ssh sl003 nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.free,memory.used --format=csv -i 0,2

При использовании очереди a6500g10q порядковый номер GPU не является уникальным идентификатором т.к. для каждой из работающих задач доступные GPU нумеруются последовательно, начиная с ноля. Вместо этого можно использовать идентификатор шины PCI:

Добавить в начало скрипта для qsub такую команду:

nvidia-smi --query-gpu=pci.bus_id --format=csv,noheader > $PBS_O_WORKDIR/$PBS_JOBID.id

В результате после запуска задачи в рабочей директории появится файл с именем вида ‘95054.vm-pbs.id’, содержащий что-то вроде ‘00000000:15:00.0’ (или несколько таких строк, если было запрошено несколько GPU).

Выполнить команду вида:

ssh a6500g10 nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.free,memory.used --format=csv -i 00000000:15:00.0

В результате на экран будет выведено примерно такое:

utilization.gpu [%], utilization.memory [%], memory.free [MiB], memory.used [MiB] 33 %, 0 %, 1735 MiB, 30775 MiB

Обращаем внимание, что ‘utilization.memory’ — это интенсивность работы с памятью карты, а не степень её заполненности.

Может быть полезно выполнить ‘man mvidia-smi’ и изучить возможности утилиты. Например, можно запросить вывод статистики каждые 10 секунд, добавив команде параметр ‘-l 10’

После завершения программы

Выполнить команду ‘tracejob XXX‘, где ‘XXX’ — номер задачи. Эта команда анализирует логи PBS и выводит информацию, связанную с работой указанной задачи. По умолчанию обрабатываются данные только за последний день. Если задача закончилась несколько дней назад или Вы хотите получить данные, начиная с момента постановки задачи в очередь, то надо дополнительно указать параметр ‘-n ZZZ‘, где ‘ZZZ’ — количество дней, прошедших с данного момента, логи за которые должна проанализировать команда.

Пример: запрос информации по задаче с номером 482685 за два прошедших дня:

tracejob -n 2 482685
. 11/19/2013 06:05:04 A user=user01 group=users project=_pbs_project_default jobname=runs queue=bl2x220g7q ctime=1384777907 qtime=1384777907 etime=1384777907 start=1384777908 exec_host=cn263/0 exec_vnode=(cn263:mem=4194304kb:ncpus=1) Resource_List.mem=4gb Resource_List.ncpus=1 Resource_List.nodect=1 Resource_List.place=pack Resource_List.qlist=bl2x220g7q Resource_List.select=1:mem=4gb:ncpus=1:qlist=bl2x220g7q Resource_List.walltime=100:00:00 session=10647 end=1384815904 Exit_status=271 resources_used.cpupercent=98 resources_used.cput=10:33:16 resources_used.mem=1321292kb resources_used.ncpus=1 resources_used.vmem=2144544kb resources_used.walltime=10:33:17 run_count=1

Здесь видно, в частности, что задача:

Запросила 1 ядро (Resource_List.ncpus) и 4 ГБ ОЗУ (Resource_List.mem)

Но ОЗУ использовалась крайне неэффективно: resources_used.mem=1321292kb, т.е. примерно 1.26 ГБ из 4 ГБ запрошенных. Что означает, что 2.5 ГБ из зарезервированных PBS под эту задачу, не использовались и при этом были недоступны другим пользователям.

Время работы команды ‘tracejob’ зависит от временного интервала, за который запрашивается информация.

Если с момента завершения задачи прошло не очень много времени, то можно также открыть веб-интерфейс Ganglia и посмотреть на графики работы. Однако, чем больше прошло времени, тем сложнее будет по графикам определить период работы задачи.

Использование виртуальной памяти

В случае, если необходимо использовать больше ОЗУ, чем имеется у компьютера, операционная система сохраняет данные из каких-то неиспользуемых в данный момент областей оперативной памяти на жесткий диск в специальный файл (файл подкачки) или специальный раздел диска, обобщённо называемые ‘swap’ (английское ‘обмен’). Освободившаяся оперативная память используется по назначению. В случае, если потребуются данные, перенесённые в swap, то происходит аналогичная операция — часть данных из ОЗУ переносится на диск, а нужные данные с диска возвращаются в оперативную память. Подобный метод позволяет операционной системе и программам работать так, как будто на компьютере больше оперативной памяти, чем на самом деле. Поэтому такая память называется виртуальной.

К сожалению, скорость передачи данных у жесткого диска существенно меньше, чем у микросхем оперативной памяти. Поэтому интенсивное использование swap сильно замедляет работу.

Рассмотрим типичные графики, полученные при помощи системы Ganglia с сервера, на котором работает задача, потребившая всю оперативную память (обозначена на первом графике синим) и интенсивно использующая swap (фиолетовый):

Видно, что в те моменты, когда потребление swap увеличивается, процессор вместо выполнения прикладных задач (‘User CPU’, загрузка процессора пользовательскими программами) простаивает в ожидании данных (‘Wait CPU’ и ‘CPU wio’; wio = wait in/out, ожидание ввода/вывода). То есть данная программа почти половину времени не работает, а ждёт обмена данными с жёстким диском. И если бы у сервера было больше оперативной памяти, программа работала бы почти в два раза быстрее.

Поэтому рекомендуется отслеживать потребление памяти вашими задачами и при необходимости что-то менять:

В случае, если программа пишется вами, в первую очередь надо подумать об оптимизации кода с целью уменьшения потребления ОЗУ.

Если известно, что при распараллеливании задачи каждый процесс, загружающий одно ядро, требует определённое количество ОЗУ и оно больше, чем имеется у сервера, то может иметь смысл занимать сервер полностью, но задействовать не все ядра. Например: у сервера 12 ядер и 24 ГБ ОЗУ, т.е. 2 ГБ на ядро; а задаче необходимо 3 ГБ на процесс. В таком случае можно занять сервер полностью (запросить 12 ядер) но задействовать только 24/3 = 8 ядер, запустив 8 процессов. Хотя более правильным будет позапускать задачу с использованием разного количества ядер и найти компромиссный вариант, обеспечивающий максимальное использование процессора.

Перенести запуск задач на сервера другого типа, имеющие больше ОЗУ либо больше ОЗУ на одно ядро.

Следует однако отметить, что само по себе использование виртуальной памяти и количество данных, находящихся в swap, не критичны для быстродействия. Если данные просто перенеслись на диск и долгое время никому не требовались, то и больших задержек не возникло. Гораздо важнее интенсивность работы с swap — как часто происходят обращения к жёсткому диску для чтения или записи. К сожалению, количества таких обращений на графиках Ganglia нет.

Ниже приведены графики задачи, которой использование виртуальной памяти не вредит — хотя в swap находится уже 24 ГБ данных, процессор всё равно загружен на 90%. Другое дело, что виртуальная память не бесконечна и если она закончится, то такая задача прервётся. Скорее всего, для такой задачи будет более правильным сразу сохранять в файл полученные результаты и освобождать память.

Использование GPU

Диагностика графики Visual Studio не поддерживается в Visual Studio ARM64.

Используйте инструмент учета использования GPU в Профилировщике производительности, чтобы получить более полное представление о высокоуровневом использовании оборудования в вашем приложении Direct3D. С его помощью можно определить, привязана ли производительность приложения к ЦП или GPU, и понять, как более эффективно использовать оборудование платформы. Инструмент учета использования GPU поддерживает приложения, использующие Direct3D 12, Direct3D 11 и Direct3D 10 и не поддерживает другие графические API, например Direct2D или OpenGL.

Окно отчета об использовании GPU выглядит так:

Screenshot of GPU Usage Report, with CPU and GPU timelines

Requirements

Ниже приведены требования по применению инструмента учета использования GPU, дополняющие требования по диагностике графики.

    GPU и драйвер, поддерживающие необходимое инструментирование синхронизации.

Примечание. Дополнительные сведения о поддерживаемых драйверах и оборудовании см. в разделе Поддерживаемые драйвера и оборудование в конце этого документа.

Дополнительные сведения о требованиях по диагностике графики см. в статье по началу работы.

Работа с инструментом учета использования GPU

При запуске приложения под управлением инструмента учета использования GPU система Visual Studio создает сеанс диагностики, выводящий высокоуровневую информацию о производительности отрисовки приложения и использовании GPU в режиме реального времени.

Запуск инструмента учета использования GPU

Screenshot of the Performance Profiler, with GPU Usage selected

  1. В главном меню выберите Отладка>Производительность и диагностика (или нажмите сочетание клавиш на клавиатуре: ALT+F2).
  2. В концентраторе Производительность и диагностика установите флажок Использование GPU. При необходимости установите флажки для других интересующих вас инструментов. Вы можете одновременно запустить несколько инструментов производительности и диагностики, чтобы получить более полное представление о производительности приложения.

Примечание. Не все инструменты производительности и диагностики можно использовать одновременно.

Высокоуровневые сведения, отображаемые в режиме реального времени, включают в себя синхронизацию кадров, частоту кадров и уровень использования GPU. Все эти элементы информации отображаются независимо друг от друга, однако все они используют общую шкалу времени, чтобы можно было легко найти связь между ними.

Каждый график Время кадра (мс) и Кадров в секунду (кадров/с) содержит две красные горизонтальные линии, представляющие целевые показатели производительности для 60 и 30 кадров в секунду. На графике «Время кадра» приложение превышает целевой показатель производительности, когда график проходит под линией, и не достигает его, когда график проходит над линией. На графике «Кадров в секунду» действует обратный принцип — приложение превышает целевой показатель производительности, когда график проходит над линией, и не достигает его, когда график проходит под линией. В основном эти графики используются для получения общего представления о производительности приложения и выявления замедлений в работе, которые может потребоваться проверить. Например, если видите неожиданное падение частоты кадров или пик загрузки GPU, может потребоваться дальнейшая проверка.

Во время выполнения приложения под управлением инструмента учета использования GPU сеанс диагностики также собирает подробные сведения о событиях графики, которые были обработаны GPU. Эта информация используется для создания более детального отчета об использовании оборудования приложением. Поскольку создание этого отчета занимает некоторое время, его можно просмотреть только после завершения сбора информации в рамках сеанса диагностики.

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

Чтобы создать и просмотреть отчет об использовании GPU, сделайте следующее:

  1. В нижней части окна сеанса диагностики выберите ссылку Остановка сбора или в верхнем левом углу щелкните Остановить. Screenshot of a diagnostics session window in the GPU Usage tool, showing Frames per second, GPU utilization, the Stop button, and the Stop collection link.
  2. В верхней части отчета выберите часть одного из графиков, где изображена соответствующая проблема. Выбранный фрагмент может иметь длину до 3 секунд. Более длинные фрагменты усекаются с конца. Screenshot of a diagnostics session window in the GPU Usage tool with part of the diagnostic session timeline selected.
  3. Для просмотра подробной временной шкалы выделенного фрагмента в нижней части отчета выберите view details (Просмотр сведений) в сообщении . click here to view details of GPU usage for that range (Щелкните для просмотра сведений об использовании GPU для этого диапазона). Screenshot of the diagnostics session window, with range selected

Открывается новый документ с вкладками, содержащий отчет. Отчет об использовании GPU помогает определить, когда событие графики было запущено на ЦП, когда оно достигло GPU и сколько времени потребовалось GPU для его выполнения. Эти сведения помогают выявить узкие места и возможности для повышения уровня параллелизма в коде.

Экспорт в GPUView или Windows Performance Analyzer

Начиная с Visual Studio 2017, вы можете открыть эти данные с помощью GPUView и Windows Performance Analyzer. Просто выберите ссылки Открыть в GpuView или Открыть в WPA, расположенные в правом нижнем углу диагностического сеанса.

Screenshot of the diagnostics session window, with links highlighted

Работа с отчетом об использовании GPU

В верхней части отчета об использовании GPU отображаются временные шкалы для операций обработки ЦП, операций отрисовки GPU и операций копирования ЦП. Эти временные шкалы разделены светло серыми вертикальными полосами, указывающими на вертикальную синхронизацию дисплея (vsync). Частота полос соответствует частоте обновления одного из дисплеев (выбранного в раскрывающемся списке Дисплей), для которого были собраны данные об использовании GPU.

Поскольку частота обновления дисплея может превышать целевой показатель производительности, прямая зависимость вертикальной синхронизации и частоты кадров, которой должно достичь приложение, может отсутствовать. Чтобы достичь целевых показателей производительности, приложение должно завершить всю обработку, выполнить отрисовку и совершить вызов Present() с целевой частотой кадров. Отрисованный кадр не будет отображаться до следующей вертикальной синхронизации после Present() .

В нижней части отчета об использовании GPU перечислены события графики, возникшие за охваченный в отчете период времени. При выборе события отображается маркер в соответствующих событиях на временных шкалах. Как правило, одно событие в потоке ЦП отображает вызов API, а другое событие на одной из временных шкал GPU показывает, когда GPU завершил задачу. Аналогично при выборе события на временной шкале в нижней части отчета показывается соответствующее событие графики.

После увеличения временных шкал в верхней части отчета видны только наиболее продолжительные события. Чтобы просмотреть более кратковременные события, увеличьте масштаб временных шкал, нажав клавишу CTRL и вращая колесико указывающего устройства либо воспользовавшись элементом управления масштабирования в левом нижнем углу верхней панели. Можно также перетаскивать содержимое панели временных шкал для перемещения по записанным событиям.

Чтобы найти желаемое, отфильтруйте отчет об использовании GPU по имени процесса, идентификатору потока и имени события. Кроме того, вы можете выбрать, какая частота обновления дисплея определяет линии вертикальной синхронизации. Вы можете отсортировать события по уровням иерархии, если ваше приложение использует интерфейс ID3DUserDefinedAnnotation для группировки команд отрисовки.

Вот дополнительные сведения:

Управление фильтром Description
Обработать Имя процесса, который вас интересует. Этот раскрывающийся список содержит все процессы, использовавшие GPU во время сеанса диагностики. Цвет, связанный с процессом, является цветом операций потока на временных шкалах.
Поток Идентификатор потока, который вас интересует. В многопоточном приложении эта информация может помочь изолировать определенные потоки, относящиеся к интересующему вас процессу. События, связанные с выбранным потоком, выделяются на каждой временной шкале.
Отображать Номер дисплея, для которого отображается частота обновления. Некоторые драйверы можно настроить для представления нескольких физических дисплеев в качестве одного большого виртуального дисплея. Может отображаться только один дисплей, даже если к компьютеру подключено несколько дисплеев.
Фильтр Ключевые слова, которые вас интересуют. В нижней части отчета будут отображаться только те события, которые полностью или частично соответствуют ключевому слову. Можно указать несколько ключевых слов, разделяя их точкой с запятой (;).
Иерархическая сортировка Флажок, указывающий, сохраняются ли или игнорируются иерархии событий, определенные с помощью пользовательских маркеров.

Список событий в нижней части отчета об использовании GPU содержит сведения о каждом событии.

Столбец Description
Имя события Имя события графики. Событие обычно соответствует одному событию на временной шкале потоков ЦП и одному событию на временной шкале GPU. Имена событий могут быть неопределенными, если инструменту учета использования GPU не удается определить имя события. Дополнительные сведения см. в примечании после этой таблицы.
Начало ЦП (нс) Время инициирования события на ЦП путем вызова API Direct3D. Время измеряется в наносекундах и отсчитывается относительно момента запуска приложения.
Начало GPU (нс) Время инициирования события в GPU. Время измеряется в наносекундах и отсчитывается относительно момента запуска приложения.
Длительность GPU (нс) Время в наносекундах, которое потребовалось для завершения события в GPU.
Имя процесса Имя приложения, из которого пришло событие.
Идентификатор потока Идентификатор потока, из которого пришло событие.

Если GPU или драйвер не поддерживают необходимые функции инструментирования, все события будут отображаться как неопределенные. В случае возникновения этой проблемы обновите драйвер GPU и повторите попытку. Дополнительные сведения см. в разделе Поддержка оборудования и драйверов в конце этого документа.

Параметры инструмента учета использования GPU

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

Чтобы отложить профилирование относительно запуска приложения, выполните следующие действия.

Screenshot of Object Property Pages, showing collection options

  1. В главном меню выберите Отладка>Производительность и диагностика (или нажмите сочетание клавиш на клавиатуре: ALT+F2).
  2. В концентраторе Производительность и диагностика рядом с элементом Использование GPU щелкните ссылку Параметры.
  3. На странице свойств Общие в области GPU Profiling Configuration (Конфигурация профилирования GPU) снимите флажок Begin profiling at app start (Начать профилирование с момента запуска приложения), чтобы отложить профилирование.

На данный момент вы не сможете отложить профилирование для приложений Direct3D 12.

После запуска приложения в инструменте учета использования GPU вам будет доступна дополнительная ссылка в нижней части окна инструмента учета использования GPU. Чтобы начать сбор данных профилирования, выберите ссылку Start (Запуск) в сообщении Start collecting additional detailed GPU Usage Data (Запуск сбора дополнительных подробных данных об использовании GPU).

Поддержка оборудования и драйверов

Поддерживаются следующие драйверы и оборудование GPU:

Vendor Описание GPU Требуемая версия драйвера
Intel® Процессоры Intel® четвертого поколения (Haswell)

AMD Radeon™ GPU, AMD FirePro™ GPU и акселераторы AMD FirePro GPU на базе архитектуры Graphics Core Next (GCN)

В настоящее время не поддерживаются конфигурации с несколькими GPU, такими как NVIDIA® SLI™ и AMD Crossfire™. Средства настройки гибридной графики, например NVIDIA® Optimus™ и AMD Enduro™, поддерживаются.

Обратная связь

Были ли сведения на этой странице полезными?

Обратная связь

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.

Отправить и просмотреть отзыв по

. и кое-что о компьютерах.

videomem_chip

Вот примерно так часто появляются темы на форумах. Почему это чушь, и почему объём памяти совсем не так уж и важен — я подробнее писал об этом вот здесь. Если коротко –то не в памяти дело, вернее, не только в памяти.

Но объём её всё равно важен. Хотя бы потому, что его указывают в системных требованиях к играм. И пусть эти “системные требования” – часто сильно усреднённая штука, но цифры там вполне конкретные, и они хоть как-то показывают, какими примерно характеристиками должен обладать компьютер для того, чтоб эту игру запускать. Насколько важно количество видеопамяти-можно узнать только в сравнении, по тестам; их много в интернете. Один из примеров- есть здесь, это всего лишь ссылка, найденная за пару секунд в Google. Но даже из неё ясно, что видеокартам среднего уровня (а мобильные в большинстве своём относятся именно к таким, и ниже) практически всё равно, 512мб или 1гб памяти на неё есть- это не даёт сколько-нибудь ощутимых преимуществ, отличающихся от обычной погрешности в таких тестах.

Какие бы не были системные требования игры или программы, может возникнуть необходимость проверить, а сколько же в реальности игра этой самой видеопамяти потребляет. Хотя бы для того, чтоб не ломиться сразу в интернет с вопросом, на что поменять видеокарту в ноутбуке потому,что у неё – “всего” 512мб на борту.

Путаницу вносит и тот факт, что на ноутбках дискретные карты умеют оперировать двумя типами памяти. Первый –это собственная память, собственный чип видеокарты, относительно небольшого (в сравнении с следующим типом) объёма. Второй- это т.н. “разделяемая память” (“shared memory”), память, которая выделяется видеокарте из оперативной по необходимости (повторюсь, я про это писал здесь.) Значит, если у видеокарты 512мб собственной памяти, то при требованиях игры в 1гб она вообще не пойдёт? Или всё-таки будет использована shared memory, а её много, и с запасом больше (пара гигабайт?)

Вот для этого и нужен мониторинг и средство, которое позволило бы определить, сколько ресурсов ваша любимая игра “съедает”.

videomem

Стандартные тестовые пакеты вроде Aida и подобных такой возможности не дают- ну или вернее, дают её очень ненаглядным и неудобным способом. Вот так это выглядит в Aida:

Отображение загрузки в процентах тут позволяет увидеть только то, что творится в данную секунду, не давая возможности мониторинга. Т.е. запустив игру и свернув её, вы увидите тут не реальные текущие данные, а результат сворачивания, когда большая часть ресурсов не используется.

Чтоб было хорошо- используем одну из лучших утилит всех времён и народов – Process Explorer (а здесь — страница на русском, но утилита всё равно на английском).

Описывать все её возможности смысла нет, это сделано многократно в интернете. Сейчас нас интересует возможность проверки нагрузки на видео.

После запуска программы в верхней части окна будут видны графики, показывающие различную текущую информацию о процессах в системе, 6-ой слева (или 2-ой справа) нас и интересует. Двойной щелчёк по нему открывает окно, относящееся к видеоподсистеме. Туда же можно попасть, выбрав пункт “System Information” из меню “View”.

image

Здесь GPU Usage— это загрузка видеочипа, GPU Dedicated memory –использование собственной памяти видеокарты, и GPU System Memory— количество используемой оперативной. На скриншоте выше- ситуация, когда запущено несколько программ и включен Aero, на скриншоте ниже- тот же набор программ, но Aero выключен.

image

Происходит такое потому, что при включении Aero прорисовку интерфейса Windows берёт на себя видеокарта, а при отключении –как и в ХР, процессор. Соответственно изменяется и нагрузка на процессор. Кстати, с оперативной памятью системы – такая же ситуация, со включенным Aero система использует примерно на 50мб больше оперативки, чем без него.

Как посмотреть, насколько были задействованы ресурсы видеокарты во время игры? Запускаем Process Explorer, сворачиваем, запускаем игру. На графике отображается ~5 минут событий, обновление графика –каждую секунду.

Можно изменить время обновления графика, от полусекунды до 10-и секунд (меню “View”-“Update interval”, относится к данным во всей программе). Есть смысл ставить 10 секунд, получив усреднённые данные за больший период времени.

Для примера – в Fallout3 на максимальных настройках качества ресурсы видеочипа у меня (это видеокарта geforce 9600m gt ddr3 512mb в ноутбуке с 4gb опертивки и процессором core3duo P8600) использовались примерно наполовину, а загрузка видеопамяти составляла не более 400 мегабайт.

Проверить загрузку оборудования

В платформу ML Space интегрирована открытая платформа для мониторинга и анализа данных с интерактивной визуализацией Grafana. С ее помощью можно отслеживать состояние задачи обучения в режиме реального времени, а именно:

  • контролировать и оптимизировать загрузку вычислительных ресурсов в ходе обучения моделей;
  • отслеживать случаи внепланового завершения задач обучения;
  • корректировать работу процессов.

Статистика в Grafana

Для доступа в Grafana:

  1. Перейдите Environments → Задачи и окружения .
  2. Возле нужной задачи нажмите и выберите Мониторинг . Задача должна быть в статусе «Running».

Примечание Чтобы метрики Grafana отобразились для запущенной задачи, обновите страницу спустя некоторое время после начала обучения.

Можно просматривать графики и после того задача завершится, информация доступна в течение семи дней с момента завершения задачи обучения.

На панелях Grafana показываются следующие графики:

  • CPU usage per worker — уровень загруженности CPU, выделенных под рабочий узел региона ;
  • Memory usage per worker — уровень загруженности оперативной памяти, выделенной под рабочий узел региона;
  • GPU utilization — уровень загруженности GPU, выделенных под рабочий узел региона;
  • GPU memory usage — уровень загруженности памяти GPU, выделенной под рабочий узел региона.

Посмотреть графики по конкретным рабочим узлам ( worker ) можно, выбрав требуемый узел ( worker_id ) из выпадающего списка. Графики можно масштабировать.

Если модель обучалась на Jupyter Server без выделенных GPU, в Grafana можно увидеть время завершения задачи. При обучении на Jupyter Server с GPU на графиках отображается время начала выполнения задачи, а время завершения не фиксировано (now).

Анализ загрузки ресурсов

Если по графику видно, что загрузка вычислительных ресурсов идет не так, как ожидалось, можно подключиться к исполняемой в регионе задаче по протоколу SSH и отладить необходимые процессы. Подключаться необходимо к конкретному воркер-поду .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *