Вычислительный узел Slurm на виртуальной машине Hyper-V, запрос оперативной памяти у Hyper-V - PullRequest
Новая
       17

Вычислительный узел Slurm на виртуальной машине Hyper-V, запрос оперативной памяти у Hyper-V

0 голосов
/ 18 апреля 2019

Я пытаюсь запустить узкий вычислительный узел на виртуальной машине, управляемой HyperV. Узел работает под управлением Ubuntu 16.04.

slurmd -C показывает: 

NodeName=calc1 CPUs=48 Boards=1 SocketsPerBoard=1 CoresPerSocket=48 ThreadsPerCore=1 RealMemory=16013
UpTime=5-20:51:31

Это не абсолютная истина, максимальный объем ОЗУ, доступный для этой машины, составляет 96 ГБ, но ОЗУ выделяется HyperV по запросу. Если нет нагрузки, узел имеет только 16 Гб.

Я пытался запустить некоторые скрипты Python, обрабатывающие большие наборы данных, без лишних слов, и видел увеличение максимальной оперативной памяти до 96 ГБ.

В моем slurmd.conf (среди других строк) есть следующее: 

SchedulerType=sched/backfill
SelectType=select/cons_res
SelectTypeParameters=CR_CPU_Memory
FastSchedule=1

DefMemPerCPU=2048
NodeName=calc1 CPUs=48 Boards=1 SocketsPerBoard=1 CoresPerSocket=48 ThreadsPerCore=1 RealMemory=96000 CoreSpecCount=8 MemSpecLimit=6000

Однако htop показывает, что загружено только 8 ядер, а 40 неактивны. А у Mem всего 16Гб.

Иногда узлы переходят в состояние Drained из-за "Низкой реальной памяти". Похоже, slurmd не верит тому, что я написал в slurm.conf

Как сделать slurmd для запроса других гигабайт оперативной памяти?

UPDATE

Я до сих пор не применил изменения конфигурации, предложенные @Carles Fenoy, но заметил странную деталь.

Выход scontrol show node: 

NodeName=calc1 Arch=x86_64 CoresPerSocket=48
   CPUAlloc=40 CPUErr=0 CPUTot=48 CPULoad=10.25
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=calc1 NodeHostName=calc1 Version=17.11
   OS=Linux 4.4.0-145-generic #171-Ubuntu SMP Tue Mar 26 12:43:40 UTC 2019
   RealMemory=96000 AllocMem=81920 FreeMem=179 Sockets=1 Boards=1
   CoreSpecCount=8 CPUSpecList=40-47 MemSpecLimit=6000
   State=MIXED ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/A
   Partitions=main
   BootTime=2019-04-12T12:50:39 SlurmdStartTime=2019-04-18T09:24:29
   CfgTRES=cpu=48,mem=96000M,billing=48
   AllocTRES=cpu=40,mem=80G
   CapWatts=n/a
   CurrentWatts=0 LowestJoules=0 ConsumedJoules=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s

Затем я ssh к calc1 и выдаю free -h. Вот его вывод: 

~$ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G         14G        172M        520K        1.1G         77M
Swap:           15G        644M         15G

ОБНОВЛЕНИЕ 2 Я обсудил эту проблему с нашим специалистом по инфраструктуре и выяснил, что этот механизм называется Hyper-V Dynamic Memory

Попытается выяснить, предоставляет ли Microsoft какие-либо API-интерфейсы для виртуальных машин. Может быть, мне повезет, и кто-то разработал для этого плагин slurm.

1 Ответ

2 голосов
/ 18 апреля 2019

Измените параметр FastSchedule на 0 или 2.

Это выдержка из документации по slurm.conf: 

   FastSchedule
          Controls  how a node's configuration specifications in slurm.conf are used.  If the number of node configuration entries in the configuration file is significantly lower than the number of nodes, setting FastSchedule
          to 1 will permit much faster scheduling decisions to be made.  (The scheduler can just check the values in a few configuration records instead of possibly thousands of  node  records.)   Note  that  on  systems  with
          hyper-threading, the processor count reported by the node will be twice the actual processor count.  Consider which value you want to be used for scheduling purposes.

          0    Base  scheduling  decisions  upon the actual configuration of each individual node except that the node's processor count in Slurm's configuration must match the actual hardware configuration if PreemptMode=sus-
               pend,gang or SelectType=select/cons_res are configured (both of those plugins maintain resource allocation information using bitmaps for the cores in the system and must remain static, while  the  node's  memory
               and disk space can be established later).

          1 (default)
               Consider the configuration of each node to be that specified in the slurm.conf configuration file and any node with less than the configured resources will be set to DRAIN.

          2    Consider the configuration of each node to be that specified in the slurm.conf configuration file and any node with less than the configured resources will not be set DRAIN.  This option is generally only useful
               for testing purposes.
...