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

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

Предварительно необходимо выяснить, на каких именно узлах работает задача. Это делается командой '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

  • При выполнении вычислений на GPU cтепень загруженности GPU можно узнать с помощью утилиты nvidia-smi. Для этого необходимо:
    • Определить, какой виртуальный узел (vnode) выделен задаче. Из него получить имя соответствующего сервера и номер GPU (от 0 до 2).
    • Командой 'ssh' зайти с интерфейсного сервера на узел с GPU, на котором работает задача.
    • Выполнить следующую команду, заменив 'X' на номер GPU:
      nvidia-smi -i X --query-gpu=utilization.gpu --format=csv,noheader
  • Например, нас интересует задача с номером 3437445.
    • Чтобы узнать выделенные задаче виртуальные узлы, выполняем на интерфейсном сервере:
      user01@clu:~> 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[1]
      sl003[2]
    • Т.е. задача иcпользует все три GPU на узле sl003.
    • Переходим с интерфесного сервера на узел sl003:
      user01@clu:~> ssh sl003
    • Чтобы узнать степень загруженности всех GPU, выполняем:
      user01@sl003:~> nvidia-smi -i 0 --query-gpu=utilization.gpu --format=csv,noheader
      user01@sl003:~> nvidia-smi -i 1 --query-gpu=utilization.gpu --format=csv,noheader
      user01@sl003:~> nvidia-smi -i 2 --query-gpu=utilization.gpu --format=csv,noheader

Выполнить команду '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. Запросила 1 ядро (Resource_List.ncpus) и 4 ГБ ОЗУ (Resource_List.mem)
  2. Но ОЗУ использовалась крайне неэффективно: 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%. Другое дело, что виртуальная память не бесконечна и если она закончится, то такая задача прервётся. Скорее всего, для такой задачи будет более правильным сразу сохранять в файл полученные результаты и освобождать память.