SLURM `srun` проти` sbatch` та їх параметри


95

Я намагаюся зрозуміти, в чому різниця між SLURM srunі sbatchкомандами. Я буду радий загальним поясненням, а не конкретним відповідям на наступні запитання, але тут є деякі конкретні моменти плутанини, які можуть стати відправною точкою та дати уявлення про те, що я шукаю.

Згідно з документацією , srunце для подання робочих місць і sbatchдля подання робочих місць для подальшого виконання, але практична різниця для мене незрозуміла, і їх поведінка, схоже, однакова. Наприклад, у мене є кластер з 2 вузлами, кожен з 2 процесорами. Якщо я виконую srun testjob.sh &5 разів поспіль, це приємно поставить у чергу п'яте завдання, поки не стане доступним центральний процесор, як і виконання sbatch testjob.sh.

Для того, щоб зробити питання більш конкретним, я вважаю, що гарним місцем для початку може бути: які речі я можу зробити з одним, а я не можу з іншим, і чому?

Багато аргументів обох команд однакові. Ті , які здаються найбільш важливими є --ntasks, --nodes, --cpus-per-task, --ntasks-per-node. Як вони пов'язані один з одним, і як вони відрізняються по srunпорівнянні sbatch?

Однією особливою відмінністю є те srun, що спричинить помилку, якщо testjob.shне має дозволу на виконання, тобто chmod +x testjob.shтоді як із sbatchзадоволенням запустить її. Що відбувається "під капотом", що змушує це бути так?

У документації також згадується, що srunзазвичай використовується всередині sbatchсценаріїв. Це призводить до запитання: як вони взаємодіють між собою, і яка "канонічна" ситуація використання кожного з них? Зокрема, я б коли-небудь використовував srunсам по собі?

Відповіді:


110

У документації сказано

srun is used to submit a job for execution in real time

поки

sbatch is used to submit a job script for later execution.

Вони обидва приймають практично однаковий набір параметрів. Основна відмінність полягає в тому, що srunце інтерактивність та блокування (ви отримуєте результат у своєму терміналі, і ви не можете писати інші команди, поки він не закінчений), тоді як sbatchце пакетна обробка та неблокування (результати записуються у файл, і ви можете надіслати інші команди зразу).

Якщо ви використовуєте srunу фоновому режимі зі &знаком, ви видаляєте функцію "блокування" srun, яка стає інтерактивною, але не блокує. Однак він все ще є інтерактивним, що означає, що результат буде захаращувати ваш термінал, а srunпроцеси пов’язані з вашим терміналом. Якщо ви від'єднаєтеся, ви втратите контроль над ними, інакше вони можуть бути вбиті (залежно від того, використовують вони їх stdoutчи ні). І їх буде вбито, якщо машину, до якої ви підключаєтесь, щоб подати завдання, перезавантажити.

Якщо ви використовуєте sbatch, ви подаєте свою роботу, і нею займається Slurm; Ви можете від’єднатись, убити термінал тощо без наслідків. Ваша робота більше не пов'язана з запущеним процесом.

Які речі я можу зробити з одним, а я не можу з іншим, і чому?

Функція, яка доступна sbatchі не доступна, srunце масиви вакансій . Як srunможна використовувати в sbatchсценарії, немає нічого, з чим ви не можете зробити sbatch.

Як вони пов’язані між собою, і чим вони відрізняються для srun проти sbatch?

Всі параметри --ntasks, --nodes, --cpus-per-task, --ntasks-per-nodeмають однакове значення в обох командах. Це справедливо для майже всіх параметрів, за винятком --exclusive.

Що відбувається "під капотом", що змушує це бути так?

srunнегайно виконує сценарій на віддаленому хості, а sbatchкопіює сценарій у внутрішню пам’ять, а потім завантажує його на обчислювальний вузол при запуску завдання. Ви можете перевірити це, змінивши сценарій подання після того, як його було надіслано; зміни не враховуватимуться (див. це ).

Як вони взаємодіють між собою, і яка "канонічна" ситуація використання кожного з них?

Зазвичай ви використовуєте sbatchдля подання завдання, а srunв сценарії подання - для створення кроків роботи, як їх називає Slurm. srunвикористовується для запуску процесів. Якщо ваша програма є паралельною програмою MPI, srunподбає про створення всіх процесів MPI. Якщо ні, srunзапустить вашу програму стільки разів, скільки вказано --ntasksпараметром. Існує багато випадків використання, залежно від того, паралельна ваша програма чи ні, має тривалий час роботи чи ні, складається з одного виконуваного файлу чи ні, і т. Д. Якщо не вказано інше, srunза замовчуванням успадковує відповідні параметри sbatchабо sallocяку вона запускає під ( звідси ).

Зокрема, я б ніколи не використовував srun сам по собі?

За винятком невеликих тестів, ні. Загальновживаним способом є srun --pty bashотримання оболонки на обчислювальній роботі.


5
Дякую за відповідь, це краще за все, на що я міг сподіватися. Одне наступне, оскільки це було одним із моїх початкових пунктів плутанини: навіщо заважати телефонувати srunвсередині сценарію подання? Можливо, я збентежений у значенні "кроку на роботу". Наприклад, якщо у мене є скрипт, який називається таким, runjob.shщо містить #!/bin/bash srun myjob.sh, чи існує практична різниця між викликом (a) sbatch runjob.shvs (b) sbatch myjob.shvs (c) srun myjob.shvs (d) srun runjob.sh? (Очевидно, останній дурний, але мені цікаво).
dkv

3
можливо, ви могли б переглянути слайди навчальної сесії, яку я нещодавно провів, щоб отримати ідеї щодо того, як використовується srun у сценарії подання: cism.ucl.ac.be/Services/Formations/slurm/2016/slurm.pdf
damienfrancois

4
Схоже, що всі приклади у слайдах (а також підручник на сторінці CECI) використовуються srunвсередині sbatchсценарію подання. Однак я виявив, що команди без srunсценарію подання будуть виконуватися однаково. Чи насправді є різниця між чотирма викликами, про які я згадав вище?
dkv

8
Усі ваші приклади працюватимуть однаково, лише якщо (1) розподіл призначений для одного центрального процесора і (2) програма є суто послідовною. Щоб побачити відмінності, запитуйте більше одного завдання. Інша відмінність полягає в тому, що якщо ви не використовуєте srun у sbatch, команда sstat не поверне жодної корисної інформації
damienfrancois,

1
@Atcold ця версія може бути більш оновленою
damienfrancois

5

Це насправді не повністю відповідає на питання, але ось ще деяка інформація, яку я знайшов, може бути корисною для когось у майбутньому:


З відповідного ланцюжка я знайшов подібне запитання:

У двох словах, sbatch та salloc виділяють ресурси для роботи, тоді як srun запускає паралельні завдання між цими ресурсами. При виклику в рамках розподілу завдань srun запускає паралельні завдання через деякі або всі виділені ресурси. У цьому випадку srun успадковує за замовчуванням відповідні параметри sbatch або salloc, під якими він працює. Потім ви можете (зазвичай) надати різні варіанти, які замінять отримане за замовчуванням. Кожне виклик srun у межах задачі називається кроком роботи.

srun також можна викликати поза розподілом роботи. У цьому випадку srun запитує ресурси, і коли ці ресурси надаються, запускає завдання через ці ресурси як одне завдання та крок роботи.

Існує відносно нова веб-сторінка, яка детальніше описує опції -B та --exclusive.

doc / html / cpu_management.shtml


Додаткова інформація на сторінці поширених запитань про SLURM .

Команда srun має два різні режими роботи. По-перше, якщо його не запустити в рамках існуючої роботи (тобто не в межах розподілу завдань Slurm, створеного salloc або sbatch), тоді він створить розподіл завдань і породить додаток. Якщо запускається в рамках існуючого розподілу, команда srun створює лише додаток. Для цього питання ми розглянемо лише перший режим роботи та порівняємо створення розподілу завдань за допомогою команд sbatch та srun.

Команда srun призначена для інтерактивного використання, хтось контролює вихід. Результат роботи програми розглядається як вихід команди srun, як правило, на терміналі користувача. Команда sbatch призначена для надсилання сценарію для подальшого виконання, і його вихідні дані записуються у файл. Параметри команд, які використовуються при розподілі завдань, майже однакові. Найбільш помітна різниця в параметрах полягає в тому, що команда sbatch підтримує концепцію масивів завдань, тоді як srun - ні. Інша суттєва відмінність полягає в стійкості до несправностей. Помилки, пов’язані із завданнями sbatch, зазвичай призводять до того, що завдання вимагається і виконується знову, тоді як відмови, пов’язані з srun, зазвичай призводять до генерування повідомлення про помилку з очікуванням, що користувач відповість відповідним чином.


Ще одна відповідна розмова тут

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.