| srun(1) | Slurm Commands | srun(1) |
نام (NAME)
srun - اجرای کارهای موازی
خلاصه دستور (SYNOPSIS)
srun [OPTIONS(0)... [executable(0) [args(0)...]]] [ : [OPTIONS(N)...]] executable(N) [args(N)...]
گزینه(ها)
چندین کار
را در یک کار
ناهمگنِ
هم‌زمان‌بندی‌شده
تعریف
می‌کنند.
برای
جزئیات
بیشتر
درباره
کارهای
ناهمگن، به
سند زیر
مراجعه
کنید
https://slurm.schedmd.com/heterogeneous_jobs.html
توضیحات (DESCRIPTION)
یک کار موازی را روی خوشه‌ای که توسط Slurm مدیریت می‌شود اجرا می‌کند. در صورت لزوم، srun ابتدا یک تخصیص منبع ایجاد می‌کند که کار موازی درون آن اجرا شود.
سند زیر
تأثیر
گزینه‌های
مختلف بر
تخصیص
پردازنده‌ها
به کارها و
تسک‌ها را
شرح می‌دهد.
https://slurm.schedmd.com/cpu_management.html
مقدار بازگشتی (RETURN VALUE)
دستور srun
بالاترین
کد خروج در
میان تمام
تسک‌های
اجرا شده،
یا
بالاترین
سیگنال (با
بیت مرتبه
بالا
تنظیم‌شده
در یک عدد
صحیح ۸ بیتی
-- به عنوان
مثال ۱۲۸ +
سیگنال) از
هر تسکی که
با سیگنال
خارج شده
است را
بازمی‌گرداند.
مقدار ۲۵۳
برای
خطاهای
کمبود
حافظه (out-of-memory)
رزرو شده
است.
هنگامی که با --async فراخوانی شود، به محض اینکه کنترلر درخواست ایجاد گام را بپذیرد، فارغ از اینکه تسک‌های گام در نهایت چگونه خارج شوند، srun مقدار 0 را بازمی‌گرداند. برای بررسی کد خروج گام پس از اتمام آن، از sacct(1) استفاده کنید.
تفکیک مسیر فایل اجرایی (EXECUTABLE PATH RESOLUTION)
فایل اجرایی به ترتیب زیر تفکیک می‌شود:
۱. اگر
فایل
اجرایی با
«.» شروع
شود، مسیر
به این صورت
ساخته
می‌شود:
دایرکتوری
کاری جاری /
فایل
اجرایی
۲. اگر فایل
اجرایی با
«/» شروع
شود، مسیر
مطلق در نظر
گرفته
می‌شود.
۳. اگر فایل
اجرایی از
طریق PATH قابل
تفکیک باشد.
path_resolution(7) را
ببینید.
۴. اگر فایل
اجرایی در
دایرکتوری
کاری جاری
باشد.
دایرکتوری کاری جاری، همان دایرکتوری کاری فرایند فراخواننده است مگر اینکه آرگومان --chdir ارسال شده باشد، که دایرکتوری کاری جاری را بازنویسی خواهد کرد.
گزینه‌ها (OPTIONS)
- -A, --account=<account>
- منابع استفاده‌شده توسط این کار را به حساب مشخص‌شده اختصاص می‌دهد (شارژ می‌کند). account یک رشته دلخواه است. نام حساب می‌تواند پس از ثبت کار با استفاده از دستور scontrol تغییر یابد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --acctg-freq=<datatype>=<interval>[,<datatype>=<interval>...]
- فواصل نمونه‌برداری حسابداری و پروفایل‌سازی کار را بر حسب ثانیه تعریف می‌کند. این گزینه می‌تواند برای بازنویسی پارامتر JobAcctGatherFrequency در فایل slurm.conf استفاده شود. <datatype>=<interval> فاصله نمونه‌برداری تسک را برای پلاگین jobacct_gather یا فاصله نمونه‌برداری را برای یک نوع پروفایل‌سازی توسط پلاگین acct_gather_profile مشخص می‌کند. چندین جفت <datatype>=<interval> جدا شده با کاما را می‌توان مشخص کرد. مقادیر پشتیبانی‌شده برای datatype عبارتند از:
- task
- فاصله
نمونه‌برداری
برای
پلاگین‌های
jobacct_gather و برای
پروفایل‌سازی
تسک توسط
پلاگین acct_gather_profile.
نکته: این بسامد برای پایش مصرف حافظه استفاده می‌شود. اگر محدودیت‌های حافظه اعمال شده باشند، بالاترین بسامدی که کاربر می‌تواند درخواست کند همان مقداری است که در فایل slurm.conf پیکربندی شده است. این قابلیت غیرفعال‌شدنی نیست.
- energy
- فاصله نمونه‌برداری برای پروفایل‌سازی مصرف انرژی با استفاده از پلاگین acct_gather_energy.
- network
- فاصله نمونه‌برداری برای پروفایل‌سازی infiniband با استفاده از پلاگین acct_gather_interconnect.
- filesystem
- فاصله نمونه‌برداری برای پروفایل‌سازی سیستم‌فایل با استفاده از پلاگین acct_gather_filesystem.
مقدار
پیش‌فرض
برای فاصله
نمونه‌برداری
تسک ۳۰
ثانیه است.
مقدار
پیش‌فرض
برای تمام
فواصل دیگر 0
است. فاصله 0
نمونه‌برداری
از نوع
مشخص‌شده
را غیرفعال
می‌کند. اگر
فاصله
نمونه‌برداری
تسک 0 باشد،
اطلاعات
حسابداری
تنها هنگام
خاتمه کار
جمع‌آوری
می‌شود
(کاهش تداخل
Slurm با کار).
مقادیر
کوچک‌تر
(غیر صفر)
تأثیر
بیشتری بر
کارایی کار
دارند، اما
مقدار ۳۰
ثانیه برای
برنامه‌هایی
با کمتر از
۱۰،۰۰۰ تسک
احتمالاً
محسوس
نخواهد بود.
این گزینه
برای
تخصیص‌های
کار اعمال
می‌شود.
- --async
- یک گامِ کار
را ثبت
می‌کند که
به صورت
ناهمگام
اجرا
می‌شود، به
جای اجرای
همگام با
دستور srun که
آن را ثبت
کرده است.
این گام
توسط مدیر
گام کار
راه‌اندازی
و نظارت
می‌شود، که
در صورت در
دسترس
نبودن
منابع در
زمان فعلی،
گام را برای
اجرای بعدی
در صف قرار
می‌دهد.
دستور srun
بلافاصله
پس از
پذیرفته
شدن گام
توسط
کنترلر و
گزارش
شناسه گام
آن، بدون
انتظار
برای شروع
یا پایان
گام،
بازمی‌گردد.
برای
جزئیات
بیشتر
درباره
قالب
خروجی، --parsable
را ببینید.
خروجی مستقیماً روی گره‌های محاسباتی در فایل‌هایی که با --output و --error نام‌گذاری شده‌اند نوشته می‌شود؛ اگر هیچ‌کدام داده نشود، slurm-%J.out (نسبت به دایرکتوری کاری هر تسک) استفاده می‌شود. ورودی نیز با مشخص کردن یک فایل از طریق --input=<file> پشتیبانی می‌شود. حالت‌هایی که نیازمند ارسال ورودی استاندارد خودِ srun به تسک‌ها هستند (--input=all یا --input=<taskid>) کار نمی‌کنند زیرا srun هیچ ارتباط ورودی/خروجی با گام ندارد. برخی گزینه‌ها مانند --label و --unbuffered، به جای srun، روی گره محاسباتی توسط فرایند slurmstepd(8) که خروجی را می‌نویسد اعمال می‌شوند.
از آنجا که srun پیش از پایان گام خارج می‌شود، کد خروج گام را منتقل نمی‌کند و سیگنال‌ها (مانند SIGINT ناشی از Ctrl-C) را به تسک‌های در حال اجرا هدایت نمی‌کند. برای ارسال سیگنال یا پایان دادن به یک گام ناهمگام از scancel <jobid>.<stepid> استفاده کنید.
این گزینه تنها می‌تواند در یک تخصیص کار موجود که مدیر گام در آن فعال است استفاده شود (--stepmgr در salloc(1)/sbatch(1) و SlurmctldParameters=enable_stepmgr در slurm.conf(5) را ببینید).
این گزینه با --pty و --immediate مانعةالجمع است.
نکته: این یک ویژگی جدید و در مرحله آزمایشی (بتا) است و نحوه استفاده از آن ممکن است در نسخه‌های بعدی تغییر کند.
- --bb=<spec>
- مشخصات
بافر
انفجاری (burst buffer).
ساختار این
مشخصات
وابسته به
سیستم است.
همچنین --bbf
را ببینید.
این گزینه
برای
تخصیص‌های
کار اعمال
می‌شود.
هنگامی که
گزینه --bb
استفاده
می‌شود، Slurm
این گزینه
را تحلیل
کرده و یک
فایل
اسکریپت
بافر
انفجاری
موقت ایجاد
می‌کند که
به صورت
داخلی توسط
پلاگین‌های
burst buffer استفاده
می‌شود.
برای
اطلاعات
بیشتر و
مثال‌ها،
راهنمای
بافر
انفجاری Slurm
را ببینید:
https://slurm.schedmd.com/burst_buffer.html
- --bbf=<file_name>
- مسیر فایل
حاوی
مشخصات
بافر
انفجاری (burst buffer).
ساختار این
مشخصات
وابسته به
سیستم است.
همچنین --bb
را ببینید.
این گزینه
برای
تخصیص‌های
کار اعمال
می‌شود.
برای
اطلاعات
بیشتر و
مثال‌ها،
راهنمای
بافر
انفجاری Slurm
را ببینید:
https://slurm.schedmd.com/burst_buffer.html
- --bcast[=<dest_path>]
- کپی کردن فایل اجرایی روی گره‌های محاسباتی تخصیص‌یافته. اگر نام فایل مشخص شده باشد، فایل اجرایی در مسیر فایل مقصدِ مشخص‌شده کپی می‌شود. اگر مسیر مشخص‌شده با «/» پایان یابد، به عنوان یک دایرکتوری مقصد در نظر گرفته می‌شود و نام فایل مقصد slurm_bcast_<job_id>.<step_id>_<nodename> خواهد بود. اگر هیچ dest_path مشخص نشده باشد و DestDir در BcastParameters مربوط به slurm.conf پیکربندی شده باشد، از آن استفاده می‌شود و نام فایل از الگوی بالا پیروی می‌کند. اگر هیچ‌یک از موارد قبلی مشخص نشده باشد، آنگاه --chdir استفاده می‌شود و نام فایل نیز از الگوی بالا پیروی خواهد کرد. برای مثال، «srun --bcast=/tmp/mine -N3 a.out» فایل «a.out» را از دایرکتوری فعلی شما در فایل «/tmp/mine» روی هر یک از سه گره محاسباتی تخصیص‌یافته کپی کرده و آن فایل را اجرا می‌کند. این گزینه برای تخصیص‌های گام اعمال می‌شود..IP
- --bcast-exclude={NONE|<exclude_path>[,<exclude_path>...]}
- فهرستی جداشده با کاما از مسیرهای مطلق دایرکتوری که باید هنگام تشخیص خودکار و انتشار وابستگی‌های شیء اشتراکی (shared object) اجرایی از طریق --bcast، مستثنی شوند. اگر کلیدواژهٔ «NONE» پیکربندی شود، هیچ مسیر دایرکتوری‌ای مستثنی نخواهد شد. مقدار پیش‌فرض همان مقدار BcastExclude در slurm.conf است و این گزینه آن را لغو (override) می‌کند. همچنین --bcast و --send-libs را ببینید.
- -b, --begin=<time>
- آغاز این کار را تا زمان مشخص‌شده به تعویق می‌اندازد. زمان‌هایی با قالب HH:MM:SS را برای اجرای کار در زمان مشخصی از روز می‌پذیرد (ثانیه‌ها اختیاری هستند). (اگر آن زمان گذشته باشد، روز بعد فرض می‌شود.) همچنین می‌توانید midnight، noon، elevenses (ساعت ۱۱ صبح)، fika (ساعت ۳ بعدازظهر) یا teatime (ساعت ۴ بعدازظهر) را مشخص کنید، و می‌توانید زمان را با پسوند AM یا PM برای اجرا در صبح یا عصر تعیین نمایید. همچنین می‌توانید با مشخص کردن تاریخی به قالب MMDDYY یا MM/DD/YY یا YYYY-MM-DD روز اجرای کار را تعیین کنید. با استفاده از قالب YYYY-MM-DD[THH:MM[:SS]] تاریخ و زمان را ترکیب کنید. همچنین می‌توانید زمان‌هایی مانند now + count time-units را مشخص کنید، که در آن time-units می‌تواند seconds (پیش‌فرض)، minutes، hours، days یا weeks باشد. کلیدواژه‌های today و tomorrow نیز می‌توانند استفاده شوند. این مقدار را می‌توان پس از ارسال کار با استفاده از دستور scontrol تغییر داد. برای مثال:
-
--begin=16:00 --begin=now+1hour --begin=now+60 (seconds by default) --begin=2010-01-20T12:34:00
نکاتی در
مورد مشخص
کردن
تاریخ/زمان:
- اگرچه فیلد
'seconds' در مشخصات
زمان HH:MM:SS توسط
کد مجاز
شمرده شده
است، توجه
داشته
باشید که
زمان‌بندی
بررسی (poll time)
زمان‌بند Slurm
آن‌قدر
دقیق نیست
که اعزام
کار را
دقیقاً در
همان ثانیه
تضمین کند.
کار در
اولین
بررسی پس از
زمان
تعیین‌شده،
واجد شرایط
شروع خواهد
بود. فاصلهٔ
زمانی دقیق
بررسی به
زمان‌بند Slurm
بستگی دارد
(به عنوان
مثال، ۶۰
ثانیه با sched/builtin
پیش‌فرض).
- اگر زمانی
(HH:MM:SS) مشخص
نشود،
مقدار
پیش‌فرض (00:00:00)
است.
- اگر تاریخی
بدون سال
مشخص شود
(مثلاً MM/DD)،
سال جاری
فرض
می‌شود،
مگر اینکه
ترکیب MM/DD و HH:MM:SS
برای آن سال
گذشته
باشد، که در
این حالت
سال بعد
استفاده
می‌شود.
این گزینه
برای
تخصیص‌های
کار اعمال
می‌شود.
- -D, --chdir=<path>
- فرایندهای راه دور را ملزم می‌کند پیش از آغاز اجرا، یک chdir به path انجام دهند. حالت پیش‌فرض، chdir به دایرکتوری کاری فعلی فرایند srun است. مسیر می‌تواند به عنوان یک مسیر کامل یا یک مسیر نسبی نسبت به دایرکتوری محل اجرای دستور مشخص شود. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --cluster-constraint=<list>
- ویژگی‌هایی را مشخص می‌کند که یک کلاستر فدرال (federated cluster) باید دارا باشد تا یک کار هم‌نیا (sibling job) به آن ارسال شود. Slurm در صورتی که کلاستر حداقل یکی از ویژگی‌های مشخص‌شده را داشته باشد، تلاش خواهد کرد یک کار هم‌نیا به آن ارسال کند.
- -M, --clusters=<string>
- کلاسترهایی که دستورها باید به آنها صادر شوند. چندین نام کلاستر را می‌توان با کاما از هم جدا کرد. کار به کلاستری ارسال خواهد شد که نزدیک‌ترین زمان تخمینی برای آغاز کار را فراهم کند. مقدار پیش‌فرض، کلاستر فعلی است. مقدار 'all' برای اجرا روی تمام کلاسترها پرس‌وجو خواهد کرد. به گزینهٔ --export برای کنترل متغیرهای محیطی صادرشده بین کلاسترها توجه کنید. این گزینه فقط برای تخصیص‌های کار اعمال می‌شود. توجه داشته باشید که slurmdbd باید فعال باشد تا این گزینه به درستی کار کند، مگر اینکه در یک فدراسیون با پیکربندی FederationParameters=fed_display اجرا شود.
- --comment=<string>
- یک توضیح دلخواه. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --compress[=type]
- فشرده‌سازی فایل پیش از ارسال آن به میزبان‌های محاسباتی. آرگومان اختیاری، کتابخانهٔ فشرده‌سازی داده را که باید استفاده شود مشخص می‌کند. پیش‌فرض در صورت تنظیم، BcastParameters Compression= و در غیر این صورت "lz4" است. مقادیر پشتیبانی‌شده "lz4" هستند. برخی از کتابخانه‌های فشرده‌سازی ممکن است در برخی سیستم‌ها در دسترس نباشند. برای استفاده با گزینهٔ --bcast. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- --consolidate-segments
- اطمینان
حاصل
می‌کند که
تمام
بخش‌ها (segments)
حاصل از
تخصیص، در
یک بلوک
تجمیع‌شدهٔ
سطح بالاتر
ادغام
می‌شوند.
این گزینه برای تخصیص‌های کار اعمال می‌شود. نکته: این گزینه تنها با افزونهٔ topology/block کار خواهد کرد.
- -C, --constraint=<list>
- گره‌ها
می‌توانند
دارای
ویژگی‌هایی
(features) باشند که
توسط مدیر Slurm
به آنها
اختصاص
یافته است.
کاربران
می‌توانند
با استفاده
از گزینهٔ
constraint مشخص
کنند
کدام‌یک از
این
ویژگی‌ها
برای
کارشان
الزامی است.
اگر به
دنبال
قیدهای
انعطاف‌پذیر
(soft constraints) هستید،
لطفاً برای
اطلاعات
بیشتر --prefer را
ببینید.
تنها
گره‌هایی
که دارای
ویژگی‌های
منطبق با
قیدهای کار
باشند برای
برآورده
کردن
درخواست
استفاده
خواهند شد.
قیدهای
متعدد را
می‌توان با
AND، OR، Matching OR،
تعداد
منابع و
غیره مشخص
کرد (برخی
عملگرها در
همهٔ انواع
سیستم
پشتیبانی
نمی‌شوند).
نکته: ویژگی‌های تغییرپذیر (Changeable features) ویژگی‌هایی هستند که توسط یک افزونهٔ NodeFeatures تعریف شده‌اند.
گزینه‌های پشتیبانی‌شدهٔ --constraint عبارتند از:
- Single Name (نام تکی)
- تنها گره‌هایی که ویژگی مشخص‌شده را دارند استفاده خواهند شد. برای مثال، --constraint="intel"
- Node Count (تعداد گره)
- یک درخواست
می‌تواند
با افزودن
یک ستاره و
عدد پس از
نام ویژگی،
تعداد
گره‌های
مورد نیاز
با آن ویژگی
را مشخص
کند. برای
مثال، --nodes=16
--constraint="graphics*4" نشان
می‌دهد که
کار به ۱۶
گره نیاز
دارد و
حداقل چهار
گره از آن
گره‌ها
باید دارای
ویژگی "graphics"
باشند. در
صورت
درخواست
بیش از یک
ویژگی و
استفاده از
تعداد گره،
درخواست
باید داخل
کروشه‌ها
قرار گیرد.
نکته: این گزینه توسط افزونهٔ NodeFeatures کمکی (helpers) پشتیبانی نمی‌شود. در عوض می‌توان از کارهای ناهمگن (heterogeneous jobs) استفاده کرد.
- AND
- تنها گره‌هایی که تمام ویژگی‌های مشخص‌شده را دارند استفاده خواهند شد. علامت آمپرسند (&) برای عملگر AND استفاده می‌شود. برای مثال، --constraint="intel&gpu"
- OR
- تنها گره‌هایی که حداقل یکی از ویژگی‌های مشخص‌شده را دارند استفاده خواهند شد. خط عمودی (|) برای عملگر OR استفاده می‌شود. اگر ویژگی‌های تغییرپذیر درخواست نشده باشند، گره‌های موجود در تخصیص می‌توانند ویژگی‌های متفاوتی داشته باشند. برای مثال، salloc -N2 --constraint="intel|amd" می‌تواند منجر به تخصیص کاری شود که در آن یک گره دارای ویژگی intel و گره دیگر دارای ویژگی amd باشد. با این حال، اگر عبارت حاوی یک ویژگی تغییرپذیر باشد، تمام عملگرهای OR به طور خودکار به عنوان Matching OR در نظر گرفته می‌شوند تا تمام گره‌های موجود در تخصیص کار دارای مجموعه ویژگی‌های یکسانی باشند. برای مثال، salloc -N2 --constraint="foo|bar&baz" به کار دو گره تخصیص داده می‌شود که هر دو گره foo دارند، یا هر دو bar و baz دارند (یک یا هر دو گره می‌توانند foo، bar و baz را داشته باشند). افزونهٔ helpers مربوط به NodeFeatures اولین مجموعه از ویژگی‌های گره را که با تمام گره‌های موجود در تخصیص کار مطابقت دارد پیدا می‌کند؛ این ویژگی‌ها به عنوان ویژگی‌های فعال روی گره تنظیم شده و به RebootProgram (نگاه کنید به slurm.conf(5)) و اسکریپت کمکی (نگاه کنید به helpers.conf(5)) ارسال می‌شوند. در این حالت، افزونهٔ helpers از اولین مورد از بین "foo" یا "bar,baz" که با دو گره موجود در تخصیص کار مطابقت داشته باشد استفاده می‌کند.
- Matching OR
- اگر تنها یکی از یک مجموعه گزینه‌های ممکن باید برای تمام گره‌های تخصیص‌یافته استفاده شود، از عملگر OR استفاده کرده و گزینه‌ها را درون کروشه قرار دهید. برای مثال، --constraint="[rack1|rack2|rack3|rack4]" ممکن است برای تعیین اینکه تمام گره‌ها باید روی یک رک منفرد از کلاستر تخصیص یابند استفاده شود، اما از هر کدام از آن چهار رک می‌توان استفاده کرد..IP
- تعدادهای چندگانه (Multiple Counts)
- تعداد
مشخصی از
چندین منبع
را می‌توان
با استفاده
از عملگر AND و
قرار دادن
گزینه‌ها
درون
براکت‌ها
تعیین کرد.
برای مثال،
--constraint="[rack1*2&rack2*4]"
ممکن است
برای مشخص
کردن اینکه
دو گره باید
از
گره‌هایی
با ویژگی
«rack1» و چهار
گره باید از
گره‌هایی
با ویژگی
«rack2» تخصیص
داده شوند،
استفاده
شود.
نکته: این گزینه توسط افزونه NodeFeatures از نوع helpers پشتیبانی نمی‌شود.
نکته: تعدادهای چندگانه می‌تواند باعث تخصیص کارها با ساختار شبکه‌ای غیربهینه شود.
- براکت‌ها (Brackets)
- از
براکت‌ها
می‌توان
برای نشان
دادن اینکه
به دنبال
مجموعه‌ای
از گره‌ها
با
نیازمندی‌های
مختلفِ
مشخص‌شده
درون براکت
هستید
استفاده
کرد. برای
مثال،
--constraint="[(rack1|rack2)*1&(rack3)*2]"
یک گره با
یکی از
ویژگی‌های
«rack1» یا «rack2»،
و دو گره با
ویژگی «rack3»
برای شما
فراهم
می‌کند. اگر
بیش از یک
ویژگی
درخواست
شود و از
تعداد
گره‌ها
استفاده
گردد،
درخواست
باید توسط
براکت
احاطه شده
باشد.
نکته: براکت‌ها تنها برای نحوهای تعدادهای چندگانه (Multiple Counts) و OR تطبیقی (Matching OR) اختصاص یافته‌اند. عملگرهای AND به یک تعداد برای هر ویژگی درون براکت نیاز دارند (مانند «[quad*2&hemi*1]»). اسلورم (Slurm) تنها یک مجموعه از قیدهای داخل براکت را به ازای هر کار مجاز می‌داند.
نکته: براکت‌ها توسط افزونه NodeFeatures از نوع helpers پشتیبانی نمی‌شوند. OR تطبیقی را می‌توان بدون براکت و با استفاده از نویسه خط عمودی (|) همراه با حداقل یک ویژگی قابل‌تغییر درخواست کرد.
- پرانتزها (Parentheses)
- از پرانتزها می‌توان برای گروه‌بندی ویژگی‌های مشابه گره در کنار یکدیگر استفاده کرد. برای مثال، --constraint="[(knl&snc4&flat)*4&haswell*1]" می‌تواند برای تعیین اینکه چهار گره با ویژگی‌های «knl»، «snc4» و «flat» به همراه یک گره با ویژگی «haswell» مورد نیاز است استفاده شود. از پرانتزها همچنین می‌توان برای گروه‌بندی عملیات استفاده کرد. بدون پرانتزها، ویژگی‌های گره دقیقاً از چپ به راست تجزیه می‌شوند. برای مثال: --constraint="foo&bar|baz" گره‌هایی با foo و bar، یا baz را درخواست می‌کند. --constraint="foo|bar&baz" گره‌هایی با foo و baz، یا bar و baz را درخواست می‌کند (توجه کنید که baz چگونه با همه چیز AND شد). --constraint="foo&(bar|baz)" گره‌هایی با foo و حداقل یکی از bar یا baz را درخواست می‌کند. نکته: عملگر OR درون پرانتز نباید با افزونه NodeFeatures از نوع KNL استفاده شود اما توسط افزونه NodeFeatures از نوع helpers پشتیبانی می‌شود.
این گزینه برای تخصیص‌های کار و گام کار اعمال می‌شود.
- --container=<path_to_container>
- مسیر مطلق به بسته کانتینر OCI (bundle).
- --container-id=<container_id>
- نام یکتا برای کانتینر OCI.
- --container-type=<container_type>
- نوع کانتینر کار برای کار.
- --contiguous
- در صورت
تنظیم،
گره‌های
تخصیص‌یافته
باید یک
مجموعه
پیوسته
تشکیل دهند.
نکته: این گزینه تنها با افزونه topology/flat کار خواهد کرد. سایر افزونه‌های توپولوژی ترتیب گره‌ها را تغییر داده و مانع از تأثیرگذاری این گزینه می‌شوند. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- -S, --core-spec=<num>
- تعداد
هسته‌های
تخصصی (Specialized Cores)
در هر گره
که توسط کار
برای
عملیات
سیستم رزرو
شده و توسط
برنامه
استفاده
نمی‌شوند.
اگر AllowSpecResourcesUsage
فعال باشد،
یک کار
می‌تواند
مقدار CoreSpecCount
همه
گره‌های
تخصیص‌یافته
خود را با
این گزینه
بازنویسی
(override) کند.
هسته‌های
تخصصی
بازنویسی‌شده
همچنان
برای
فرآیندهای
سیستمی
رزرو
خواهند
ماند. کار
یک تخصیص
ضمنی --exclusive
برای
باقی‌مانده
هسته‌های
روی گره
دریافت
خواهد کرد،
که در نتیجه
فرآیندهای
کار قادر به
استفاده از
(و محاسبه
هزینه برای)
تمامی
هسته‌های
روی گره،
به‌جز
هسته‌های
تخصصی
بازنویسی‌شده
خواهند بود.
این گزینه
نمی‌تواند
همراه با
گزینه --thread-spec
استفاده
شود.
نکته: تنظیم صریح مقدار هسته تخصصی یک کار، به طور ضمنی گزینه --exclusive را تنظیم می‌کند.
نکته: در صورتی که -n مشخص نشده باشد، این گزینه ممکن است به صورت ضمنی بر تعداد وظایف تأثیر بگذارد.
این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --cores-per-socket=<cores>
- محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شده هسته به ازای هر سوکت. در صورت فعال بودن افزونه task/affinity، اطلاعات تکمیلی را زیر گزینه -B در بالا مشاهده کنید. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --cpu-bind=[{quiet|verbose},]<type>
- مقید کردن
وظایف به
پردازنده‌ها
(CPUs). تنها
زمانی
استفاده
می‌شود که
افزونه task/affinity
فعال باشد.
نکته: برای
اینکه Slurm
همواره
وضعیت قید CPU
انتخاب‌شده
را برای همه
دستورهای
اجراشده در
یک پوسته
گزارش کند،
می‌توانید
حالت پرگو
(verbose) را با
تنظیم
مقدار
متغیر
محیطی SLURM_CPU_BIND
روی "verbose"
فعال کنید.
متغیرهای محیطی اطلاع‌رسانی زیر در زمان استفاده از --cpu-bind مقداردهی می‌شوند:
-
SLURM_CPU_BIND_VERBOSE SLURM_CPU_BIND_TYPE SLURM_CPU_BIND_LIST
برای توضیحات دقیق‌تر درباره هریک از متغیرهای SLURM_CPU_BIND به بخش متغیرهای محیطی (ENVIRONMENT VARIABLES) مراجعه کنید. این متغیرها تنها در صورتی در دسترس هستند که افزونه task/affinity پیکربندی شده باشد.
هنگام استفاده از --cpus-per-task برای اجرای وظایف چندنخی، آگاه باشید که قید CPU از والد فرآیند به ارث برده می‌شود. این بدان معناست که وظیفه چندنخی باید خود قید CPU را تعیین یا پاک کند تا از استفاده همه نخ‌های وظیفه چندنخی از همان ماسک/پردازنده والد جلوگیری شود. روش دیگر، استفاده از ماسک‌های عریض (fat masks - ماسک‌هایی که بیش از یک پردازنده مجاز را مشخص می‌کنند) برای وظایف است تا چندین پردازنده را برای وظایف چندنخی فراهم کنند.
توجه داشته باشید که به یک گام کار می‌تواند تعداد متفاوتی پردازنده در هر گره تخصیص یابد یا پردازنده‌هایی تخصیص داده شوند که از مکان صفر شروع نمی‌شوند. بنابراین یکی از گزینه‌هایی که به صورت خودکار قید وظیفه را تولید می‌کنند توصیه می‌شود. ماسک‌ها یا قیدهای صریحاً مشخص‌شده تنها زمانی رعایت می‌شوند که به گام کار تمام پردازنده‌های موجود روی گره تخصیص یافته باشد.
مقید کردن یک وظیفه به یک دامنه محلی NUMA به معنای مقید کردن وظیفه به مجموعه‌ای از پردازنده‌هاست که به دامنه محلی NUMA یا «گره NUMA» تعلق دارند. اگر گزینه‌های دامنه محلی NUMA در سیستم‌های بدون پشتیبانی از NUMA استفاده شوند، هر سوکت به عنوان یک دامنه محلی در نظر گرفته می‌شود.
اگر از گزینه --cpu-bind استفاده نشود، حالت پیش‌فرض قید به پیکربندی Slurm و تخصیص منابع گام بستگی خواهد داشت. اگر همه گره‌های تخصیص‌یافته دارای حالت CpuBind پیکربندی‌شده یکسانی باشند، از آن استفاده خواهد شد. در غیر این صورت اگر پارتیشن کار دارای یک حالت CpuBind پیکربندی‌شده باشد، از آن استفاده خواهد شد. در غیر این صورت اگر Slurm دارای مقدار TaskPluginParam پیکربندی‌شده باشد، از آن حالت استفاده خواهد شد. در غیر این صورت مقیدسازی خودکار همانطور که در ادامه توضیح داده شده انجام خواهد شد.
- اتصال خودکار (Auto Binding)
- تنها زمانی اعمال می‌شود که task/affinity فعال باشد. اگر تخصیص گام کار شامل تخصیصی با تعداد سوکت، هسته یا نخی برابر با حاصل‌ضرب تعداد وظایف در cpus-per-task باشد، وظایف به طور پیش‌فرض به منابع مناسب مقید خواهند شد (اتصال خودکار). این حالت عملکرد را با تنظیم صریح "--cpu-bind=none" غیرفعال کنید. از TaskPluginParam=autobind=[threads|cores|sockets] برای تنظیم یک قید پیش‌فرض پردازنده در حالتی که «اتصال خودکار» تطابقی پیدا نکند، استفاده کنید.
- q[uiet]
- مقیدسازی در سکوت پیش از اجرای وظیفه (پیش‌فرض)
- v[erbose]
- گزارش با جزئیات وضعیت مقیدسازی پیش از اجرای وظیفه
- no[ne]
- وظایف را به پردازنده‌ها مقید نکن (پیش‌فرض، مگر اینکه مقیدسازی خودکار اعمال شده باشد)
- map_cpu:<list>
- مقیدسازی با تنظیم ماسک‌های پردازنده بر روی وظایف (یا رتبه‌ها) به گونهٔ مشخص‌شده؛ جایی که <list> عبارت است از <cpu_id_for_task_0>,<cpu_id_for_task_1>,... اگر تعداد وظایف (یا رتبه‌ها) از تعداد عناصر موجود در این فهرست بیشتر باشد، عناصر فهرست در صورت نیاز از ابتدای فهرست دوباره استفاده خواهند شد. برای ساده‌سازی پشتیبانی از تعداد وظایف بالا، فهرست‌ها می‌توانند پس از نگاشت شامل یک ستاره و شمارش تکرار باشند. برای مثال "map_cpu:0*4,3*4".
- mask_cpu:<list>
- مقیدسازی با تنظیم ماسک‌های پردازنده بر روی وظایف (یا رتبه‌ها) به گونهٔ مشخص‌شده؛ جایی که <list> عبارت است از <cpu_mask_for_task_0>,<cpu_mask_for_task_1>,... نگاشت برای یک گره مشخص می‌شود و نگاشت مشابهی به وظایف موجود در هر گره اعمال می‌گردد (یعنی کمترین شناسهٔ وظیفه در هر گره به نخستین ماسک مشخص‌شده در فهرست نگاشت می‌شود و غیره). ماسک‌های پردازنده همیشه به عنوان مقادیر هگزادسیمال تفسیر می‌شوند اما می‌توانند اختیاری با پیشوند '0x' همراه باشند. اگر تعداد وظایف (یا رتبه‌ها) از تعداد عناصر موجود در این فهرست بیشتر باشد، عناصر فهرست در صورت نیاز از ابتدای فهرست دوباره استفاده خواهند شد. برای ساده‌سازی پشتیبانی از تعداد وظایف بالا، فهرست‌ها می‌توانند پس از نگاشت شامل یک ستاره و شمارش تکرار باشند. برای مثال "mask_cpu:0x0f*4,0xf0*4".
- rank_ldom
- مقیدسازی به یک دامنهٔ محلی NUMA بر پایهٔ رتبه (rank). پشتیبانی نمی‌شود مگر اینکه کل گره به کار تخصیص داده شده باشد.
- map_ldom:<list>
- مقیدسازی با نگاشت شناسه‌های دامنهٔ محلی NUMA به وظایف به گونهٔ مشخص‌شده؛ جایی که <list> برابر است با <ldom1>,<ldom2>,...<ldomN>. شناسه‌های دامنهٔ محلی به صورت مقادیر ده‌دهی تفسیر می‌شوند مگر اینکه پیشوند '0x' داشته باشند که در این صورت به عنوان مقادیر هگزادسیمال تفسیر می‌گردند. پشتیبانی نمی‌شود مگر اینکه کل گره به کار تخصیص داده شده باشد.
- mask_ldom:<list>
- مقیدسازی با تنظیم ماسک‌های دامنهٔ محلی NUMA بر روی وظایف به گونهٔ مشخص‌شده؛ جایی که <list> برابر است با <mask1>,<mask2>,...<maskN>. ماسک‌های دامنهٔ محلی NUMA همیشه به عنوان مقادیر هگزادسیمال تفسیر می‌شوند اما می‌توانند اختیاری با پیشوند '0x' همراه باشند. پشتیبانی نمی‌شود مگر اینکه کل گره به کار تخصیص داده شده باشد.
- sockets
- تولید خودکار ماسک‌ها برای مقیدسازی وظایف به سوکت‌ها. تنها پردازنده‌هایی از سوکت که به کار تخصیص داده شده‌اند استفاده خواهند شد. اگر تعداد وظایف با تعداد سوکت‌های تخصیص‌یافته متفاوت باشد، این می‌تواند منجر به مقیدسازی زیربهینه (sub-optimal) شود.
- cores
- تولید خودکار ماسک‌ها برای مقیدسازی وظایف به هسته‌ها. اگر تعداد وظایف با تعداد هسته‌های تخصیص‌یافته متفاوت باشد، این می‌تواند منجر به مقیدسازی زیربهینه شود.
- threads
- تولید خودکار ماسک‌ها برای مقیدسازی وظایف به رشته‌ها. اگر تعداد وظایف با تعداد رشته‌های تخصیص‌یافته متفاوت باشد، این می‌تواند منجر به مقیدسازی زیربهینه شود.
- ldoms
- تولید خودکار ماسک‌ها برای مقیدسازی وظایف به دامنه‌های محلی NUMA. اگر تعداد وظایف با تعداد دامنه‌های محلی تخصیص‌یافته متفاوت باشد، این می‌تواند منجر به مقیدسازی زیربهینه شود.
- help
- نمایش پیام راهنما برای cpu-bind
- این گزینه برای تخصیص‌های کار (job) و گام (step) اعمال می‌شود.
- --cpu-freq=<p1>[-p2][:p3]
-
درخواست اینکه گام کاری آغازشده توسط این دستور srun در صورت امکان با یک فرکانس درخواستی، روی پردازنده‌های انتخاب‌شده برای آن گام در گره(های) محاسباتی اجرا شود.
p1 می‌تواند [#### | low | medium | high | highm1] باشد که scaling_speed فرکانس را روی مقدار متناظر تنظیم کرده، و scaling_governor فرکانس را روی UserSpace قرار می‌دهد. برای تعریف این مقادیر به ادامه مراجعه کنید.
p1 می‌تواند [Conservative | OnDemand | Performance | PowerSave] باشد که scaling_governor را روی مقدار متناظر تنظیم می‌کند. گاورنر باید در فهرستی باشد که با گزینهٔ CpuFreqGovernors در slurm.conf تعیین شده است.
هنگامی که p2 مشخص شده باشد، p1 حداقل فرکانس مقیاس‌پذیری و p2 حداکثر فرکانس مقیاس‌پذیری خواهد بود. در این حالت، گاورنر p3 یا CpuFreqDef نمی‌تواند UserSpace باشد زیرا از یک بازه پشتیبانی نمی‌کند.
p2 می‌تواند [#### | medium | high | highm1] باشد. مقدار p2 باید بزرگ‌تر از p1 بوده و با گاورنر UserSpace ناسازگار است.
p3 می‌تواند [Conservative | OnDemand | Performance | PowerSave | SchedUtil | UserSpace] باشد که گاورنر را روی مقدار متناظر تنظیم خواهد کرد.
اگر p3 مقدار UserSpace باشد، فرکانس‌های scaling_speed، scaling_max_freq و scaling_min_freq به طور ایستا بر روی مقدار تعیین‌شده توسط p1 تنظیم خواهند شد.
هر فرکانس درخواستی کمتر از حداقل فرکانس موجود، به حداقل فرکانس در دسترس گرد خواهد شد. به همین ترتیب، هر فرکانس درخواستی بیشتر از حداکثر فرکانس موجود، به حداکثر فرکانس در دسترس گرد خواهد شد.
در صورت نبود p3، از پارامتر CpuFreqDef در slurm.conf برای تنظیم گاورنر استفاده خواهد شد. اگر CpuFreqDef وجود نداشته باشد، گاورنر پیش‌فرض استفاده از گاورنر فعلی سیستم خواهد بود که بر روی هر پردازنده تنظیم شده است. بنابراین مشخص کردن یک بازه بدون وجود CpuFreqDef یا یک گاورنر مشخص، مجاز نیست.
مقادیر پذیرفتنی در حال حاضر شامل موارد زیر هستند:
- ####
- فرکانس بر حسب کیلوهرتز
- Low
- پایین‌ترین فرکانس در دسترس
- High
- بالاترین فرکانس در دسترس
- HighM1
- (High منهای یک) فرکانس بعدی پس از بالاترین فرکانس در دسترس را انتخاب می‌کند
- Medium
- تلاش می‌کند فرکانسی در میانهٔ بازهٔ در دسترس تنظیم کند
- Conservative
- تلاش می‌کند از گاورنر پردازندهٔ Conservative استفاده کند.IP
- OnDemand
- تلاش می‌کند از گاورنر پردازندهٔ OnDemand استفاده کند (مقدار پیش‌فرض)
- Performance
- تلاش می‌کند از گاورنر پردازندهٔ Performance استفاده کند
- PowerSave
- تلاش می‌کند از گاورنر پردازندهٔ PowerSave استفاده کند
- UserSpace
- تلاش می‌کند از گاورنر پردازندهٔ UserSpace استفاده کند
-
متغیر محیطی اطلاعاتی زیر در گام کار هنگام درخواست گزینهٔ --cpu-freq تنظیم می‌شود.
SLURM_CPU_FREQ_REQ
همچنین در صورتی که این متغیر محیطی هنگام صدور دستور 'srun' مقداردهی شده باشد، می‌تواند برای مشخص کردن مقدار فرکانس درخواستی پردازنده استفاده شود. گزینهٔ --cpu-freq در خط فرمان مقدار متغیر محیطی را بازنویسی خواهد کرد. ساختار مقدار در این متغیر محیطی همانند خط فرمان است. برای شرح متغیر SLURM_CPU_FREQ_REQ، بخش ENVIRONMENT VARIABLES را ببینید.
نکته: این پارامتر به عنوان یک درخواست در نظر گرفته می‌شود، نه یک الزام. اگر گرهِ مربوط به گام کار از تنظیم فرکانس پردازنده پشتیبانی نکند یا مقدار درخواستی خارج از محدودهٔ فرکانس‌های مجاز باشد، خطایی ثبت می‌شود اما به گام کار اجازهٔ ادامه داده خواهد شد.
نکته: تنظیم فرکانس صرفاً برای پردازنده‌های گام کار بدین معناست که تسک‌ها به همان پردازنده‌ها محدود (confined) شده‌اند. اگر محدودسازی تسک (یعنی فعال بودن افزونهٔ task/affinity TaskPlugin یا فعال بودن افزونهٔ task/cgroup TaskPlugin با مقدار "ConstrainCores=yes" در cgroup.conf) پیکربندی نشده باشد، این پارامتر نادیده گرفته می‌شود.
نکته: هنگامی که گام کامل شود، فرکانس و گاورنر هر پردازندهٔ انتخاب‌شده به مقادیر قبلی بازنشانی می‌شود.
نکته: ارسال کارها با گزینهٔ --cpu-freq در حالتی که ProctrackType برابر با linuxproc باشد می‌تواند موجب شود کارها پیش از آنکه بخش Accounting قادر به دریافت اطلاعات کار باشد، بسیار سریع اجرا و تمام شوند. در نتیجه همهٔ اطلاعات حسابداری ثبت نخواهد شد.
این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --cpus-per-gpu=<ncpus>
- درخواست
می‌کند به
ازای هر GPU
تخصیص‌یافته،
تعداد ncpus
پردازنده
اختصاص
یابد. این
گزینه به
معنای فعال
بودن ضمنی --exact
است. با
گزینهٔ --cpus-per-task
سازگار
نیست.
این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- -c, --cpus-per-task=<ncpus>
- درخواست
می‌کند که
تعداد ncpus
پردازنده
به ازای هر
فرایند
تخصیص داده
شود. این
امر ممکن
است در
صورتی که
کار
چندریسمانی
(multithreaded) باشد و
برای
کارایی
بهینه به
بیش از یک
پردازنده
به ازای هر
تسک نیاز
داشته
باشد، مفید
باشد.
درخواست
صریح این
گزینه
مستلزم
فعال شدن
ضمنی --exact است.
مقدار
پیش‌فرض،
یک
پردازنده
به ازای هر
فرایند است
و متضمن --exact
نیست. اگر -c
بدون -n
مشخص شود،
با رعایت
محدودیت -c
تا جای ممکن
تسک‌های
بیشتری در
هر گره
تخصیص
خواهند
یافت. برای
مثال در
خوشه‌ای با
۸ پردازنده
در هر گره،
درخواستی
برای ۴ گره
و ۳
پردازنده
برای هر تسک
ممکن است
بسته به
مصرف منابع
توسط سایر
کارها، ۳ یا
۶ پردازنده
در هر گره (۱
یا ۲ تسک در
هر گره)
تخصیص دهد.
چنین کاری
ممکن است
قادر به
اجرای بیش
از مجموعاً
۴ تسک
نباشد.
هشدار: پیکربندی‌ها و گزینه‌هایی وجود دارند که توسط درخواست‌های کار و گام کار به صورت متفاوتی تفسیر می‌شوند و این امر می‌تواند به ناسازگاری‌هایی در این گزینه منجر شود. برای مثال، دستور srun -c2 --threads-per-core=1 prog ممکن است دو هسته را برای کار تخصیص دهد، اما اگر هر یک از آن هسته‌ها شامل دو ریسمان باشد، تخصیص کار شامل چهار پردازنده خواهد بود. سپس تخصیص گام کار، دو ریسمان را به ازای هر پردازنده و در مجموع دو تسک اجرا خواهد کرد.
هشدار: هنگامی که srun از داخل salloc یا sbatch اجرا می‌شود، پیکربندی‌ها و گزینه‌هایی وجود دارند که اگر مقدار -c بزرگ‌تر از -c در salloc یا sbatch باشد، می‌توانند به تخصیص‌های ناسازگار منجر شوند.
نکته: اگر --mem-per-cpu نیز مشخص شده باشد، در صورتی که از حد مجاز MaxMemPerCPU فراتر رود، تعداد پردازنده‌های تخصیص‌یافته می‌تواند افزایش یابد. در صورتی که -n مشخص نشده باشد، تعداد تسک‌ها می‌تواند بیشتر از حد انتظار باشد.
این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --deadline=<OPT>
- اگر امکان
اتمام کار
پیش از این
ضرب‌الاجل
وجود
نداشته
باشد، کار
را حذف
می‌کند (start > (deadline -
time[-min])).
پیش‌فرض،
نداشتن
ضرب‌الاجل
است. توجه
داشته
باشید اگر
نه DefaultTime و نه
MaxTime روی
پارتیشنی
که کار در
آن قرار
دارد
پیکربندی
نشده
باشند، در
صورت
استفاده از
ضرب‌الاجل،
لازم است
کار شکلی از
محدودیت
زمانی (--time[-min]) را
مشخص کند.
قالب‌های زمانی معتبر عبارتند از:
HH:MM[:SS] [AM|PM]
MMDD[YY] یا MM/DD[/YY] یا MM.DD[.YY]
MM/DD[/YY]-HH:MM[:SS]
YYYY-MM-DD[THH:MM[:SS]]]
now[+count[seconds(default)|minutes|hours|days|weeks]]این گزینه فقط برای تخصیص‌های کار اعمال می‌شود.
- --delay-boot=<minutes>
- اگر کار
برای مدت
زمانی کمتر
از این دوره
واجد شرایط
اجرا بوده
است،
گره‌ها را
به منظور
برآورده
کردن
ویژگی‌های
مشخص‌شدهٔ
این کار
بازراه‌اندازی
(reboot) نکن. اگر
کار کمتر از
این مدت
مشخص منتظر
مانده
باشد، فقط
از
گره‌هایی
استفاده
خواهد کرد
که از قبل
دارای
ویژگی‌های
مشخص‌شده
هستند.
آرگومان بر
حسب دقیقه
است. یک
مقدار
پیش‌فرض
می‌تواند
توسط مدیر
سیستم با
استفاده از
گزینهٔ delay_boot
در پارامتر
پیکربندی
SchedulerParameters در
فایل slurm.conf
تعیین شود؛
در غیر این
صورت مقدار
پیش‌فرض
صفر است
(بدون
تاخیر).
این گزینه فقط برای تخصیص‌های کار اعمال می‌شود.
- -d, --dependency=<dependency_list>
- آغاز این
کار را تا
زمانی که
وابستگی‌های
مشخص‌شده
برآورده
شوند، به
تعویق
می‌اندازد.
پس از
برآورده
شدن یک
وابستگی،
از کار حذف
می‌شود. این
گزینه برای
گام‌های
کار (اجرای srun
در یک تخصیص
موجود salloc یا sbatch)
اعمال
نمی‌شود و
فقط مخصوص
تخصیص‌های
کار است.
<dependency_list> به
صورت
<type:job_id[:job_id][,type:job_id[:job_id]]>
یا
<type:job_id[:job_id][?type:job_id[:job_id]]>
است. اگر از
جداکنندهٔ
«,» استفاده
شود، تمام
وابستگی‌ها
باید
برآورده
شوند. اگر
از
جداکنندهٔ
«?» استفاده
شود،
برآورده
شدن هر یک
از
وابستگی‌ها
کافی است.
تنها
می‌توان از
یک نوع
جداکننده
استفاده
کرد. برای
مثال:
-d afterok:20:21,afterany:23
بدین معناست که کار تنها پس از کد خروج 0 در کارهای 20 و 21 و همچنین اتمام کار 23 می‌تواند اجرا شود. با این حال:-d afterok:20:21?afterany:23
بدین معناست که هر یک از شرایط (afterok:20 یا afterok:21 یا afterany:23) برای آزاد شدن کار کافی خواهد بود. کارهای متعددی می‌توانند وابستگی یکسانی داشته باشند و این کارها حتی ممکن است متعلق به کاربران متفاوتی باشند. این مقدار را می‌توان پس از ارسال کار با استفاده از دستور scontrol تغییر داد. وابستگی به کارهای راه‌دور در یک فدراسیون (federation) مجاز است. هنگامی که یک وابستگی به دلیل وضعیت خاتمهٔ کار قبلی با شکست مواجه شود، کار وابسته هرگز اجرا نخواهد شد، حتی اگر کار قبلی مجدداً در صف قرار گیرد (requeued) و در اجرای بعدی وضعیت خاتمهٔ متفاوتی داشته باشد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- after:job_id[[+time][:jobid[+time]...]]
- پس از آنکه کارهای مشخص‌شده شروع یا لغو شوند و 'time' دقیقه از شروع یا لغو کار سپری شود، این کار می‌تواند اجرا شود. اگر زمانی برای 'time' داده نشود، پس از شروع یا لغو هیچ تاخیری وجود نخواهد داشت. afterany:job_id[:jobid...] این کار می‌تواند پس از خاتمه یافتن کارهای مشخص‌شده شروع به اجرا کند. این نوع وابستگی پیش‌فرض است.
- afterburstbuffer:job_id[:jobid...]
- این کار می‌تواند پس از خاتمه یافتن کارهای مشخص‌شده و تکمیل تمام عملیات انتقال داده خروجی (stage out) بافر انفجاری (burst buffer) مرتبط با آنها، شروع به اجرا کند.
- aftercorr:job_id[:jobid...]
- یک تسک از این آرایه کار (job array) می‌تواند پس از آنکه شناسه تسک متناظر در کار مشخص‌شده با موفقیت تکمیل شد (با کد خروج صفر به پایان رسید)، شروع به اجرا کند. اگر کار مشخص‌شده یک آرایه نباشد، همانند afterok با آن رفتار می‌شود.
- afternotok:job_id[:jobid...]
- این کار می‌تواند پس از خاتمه یافتن کارهای مشخص‌شده در یک وضعیت ناموفق (کد خروج غیرصفر، خرابی گره، اتمام مهلت زمانی، و غیره) شروع به اجرا کند. این کار باید زمانی ارسال شود که کار مشخص‌شده هنوز فعال است یا ظرف MinJobAge ثانیه پس از پایان یافتن کار مشخص‌شده ارسال گردد. اگر شناسه کار وابسته پیدا نشود و روی همان کلاستری باشد که کار از آن ارسال شده، کار رد می‌شود. اگر شناسه کار وابسته پیدا نشود و روی کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق علامت‌گذاری می‌شود.
- afterok:job_id[:jobid...]
- این کار می‌تواند پس از اجرای موفقیت‌آمیز کارهای مشخص‌شده (رسیدن به پایان با کد خروج صفر) شروع به اجرا کند. این کار باید زمانی ارسال شود که کار مشخص‌شده هنوز فعال است یا ظرف MinJobAge ثانیه پس از پایان یافتن کار مشخص‌شده ارسال گردد. اگر شناسه کار وابسته پیدا نشود و روی همان کلاستری باشد که کار از آن ارسال شده، کار رد می‌شود. اگر شناسه کار وابسته پیدا نشود و روی کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق علامت‌گذاری می‌شود.
- singleton
- این کار می‌تواند پس از خاتمه یافتن تمام کارهایی که قبلاً اجرا شده‌اند و نام کار و کاربر یکسانی دارند، شروع به اجرا کند. به عبارت دیگر، در هر نقطه از زمان تنها یک کار با آن نام و متعلق به آن کاربر می‌تواند در حال اجرا یا در حالت تعلیق باشد. در یک فدراسیون، وابستگی singleton باید در تمام کلاسترها برآورده شود، مگر اینکه از DependencyParameters=disable_remote_singleton در slurm.conf استفاده شده باشد.
- -X, --disable-status
- غیرفعال کردن نمایش وضعیت تسک هنگامی که srun یک سیگنال SIGINT (Ctrl-C) منفرد دریافت می‌کند. در عوض بلافاصله SIGINT به کار در حال اجرا هدایت می‌شود. بدون این گزینه، برای خاتمه اجباری کار به یک Ctrl-C دوم ظرف یک ثانیه نیاز است و srun بلافاصله خارج خواهد شد. همچنین می‌تواند از طریق متغیر محیطی SLURM_DISABLE_STATUS تنظیم شود. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- -m, --distribution={*|block|cyclic|arbitrary|plane=<size>}[:{*|block|cyclic|fcyclic}[:{*|block|cyclic|fcyclic}]][,{Pack|NoPack}]
-
مشخص کردن روش‌های توزیع جایگزین برای فرایندهای دوردست. برای تخصیص کار، این گزینه متغیرهای محیطی را تعیین می‌کند که توسط درخواست‌های بعدی srun استفاده خواهند شد. توزیع تسک بر تخصیص کار در آخرین مرحله از ارزیابی منابع در دسترس توسط افزونه cons_tres تأثیر می‌گذارد. در نتیجه، گزینه‌های دیگر (مانند --ntasks-per-node و --cpus-per-task) ممکن است پیش از توزیع تسک بر انتخاب منابع اثر بگذارند. برای اطمینان از یک توزیع تسک مشخص، کارها باید به تمام گره دسترسی داشته باشند، که می‌توان با استفاده از پرچم --exclusive یا با درخواست تمامی منابع روی گره(ها) به این هدف رسید.
این گزینه توزیع تسک‌ها روی گره‌هایی که منابع بر روی آنها تخصیص یافته است، و همچنین توزیع آن منابع را به تسک‌ها برای انتساب (وابستگی تسک) کنترل می‌کند. روش توزیع اول (قبل از اولین ":") توزیع تسک‌ها روی گره‌ها را کنترل می‌کند. روش توزیع دوم (بعد از اولین ":") توزیع CPUهای تخصیص‌یافته روی سوکت‌ها را برای انتساب به تسک‌ها کنترل می‌کند. روش توزیع سوم (بعد از دومین ":") توزیع CPUهای تخصیص‌یافته روی هسته‌ها را برای انتساب به تسک‌ها کنترل می‌کند. توزیع‌های دوم و سوم فقط در صورتی اعمال می‌شوند که وابستگی تسک فعال باشد. توزیع سوم تنها زمانی پشتیبانی می‌شود که افزونه task/cgroup پیکربندی شده باشد. مقدار پیش‌فرض برای هر نوع توزیع با * مشخص می‌شود.
توجه داشته باشید که با select/cons_tres، تعداد CPUهای تخصیص‌یافته به هر سوکت و گره ممکن است متفاوت باشد. برای اطلاعات بیشتر در مورد تخصیص منابع، توزیع تسک‌ها روی گره‌ها و انتساب تسک‌ها به CPUها، به https://slurm.schedmd.com/mc_support.html مراجعه کنید.
- *
- استفاده از روش پیش‌فرض برای توزیع تسک‌ها روی گره‌ها (block). اگر یک افزونه مکان‌شناسی (topology) پیکربندی شده باشد و کاربر روش توزیعی مشخص نکند، تسک‌ها به جای ترتیب نمایه گره، بر اساس ترتیب توپولوژی توزیع می‌شوند. برای غیرفعال کردن این رفتار، CR_NO_DIST_TOPO_BLOCK را در SelectTypeParameters ببینید.
- block
- روش توزیع بلوکی (block) تسک‌ها را طوری روی یک گره توزیع می‌کند که تسک‌های متوالی یک گره مشترک داشته باشند. برای مثال، تخصیص سه گره را در نظر بگیرید که هر کدام دارای دو پردازنده هستند. یک درخواست توزیع بلوکی چهار تسکی، آن تسک‌ها را به‌گونه‌ای روی گره‌ها توزیع می‌کند که تسک‌های یک و دو روی گره اول، تسک سه روی گره دوم و تسک چهار روی گره سوم قرار گیرند. اگر تعداد تسک‌ها از تعداد گره‌های تخصیص‌یافته بیشتر باشد، توزیع بلوکی رفتار پیش‌فرض است.
- cyclic
- روش توزیع چرخشی (cyclic) تسک‌ها را به‌گونه‌ای روی یک گره توزیع می‌کند که تسک‌های متوالی روی گره‌های متوالی (به صورت نوبت‌گردشی یا round-robin) توزیع شوند. برای مثال، تخصیص سه گره را در نظر بگیرید که هر کدام دارای دو پردازنده هستند. یک درخواست توزیع چرخشی چهار تسکی، آن تسک‌ها را به‌گونه‌ای روی گره‌ها توزیع می‌کند که تسک‌های یک و چهار روی گره اول، تسک دو روی گره دوم و تسک سه روی گره سوم قرار گیرند. توجه داشته باشید هنگامی که SelectType برابر با select/cons_tres باشد، ممکن است تعداد یکسانی از CPUها روی هر گره تخصیص نیافته باشد. توزیع تسک‌ها به صورت نوبت‌گردشی بین تمامی گره‌هایی خواهد بود که هنوز CPUهای اختصاص‌نیافته به تسک‌ها دارند. توزیع چرخشی رفتار پیش‌فرض است اگر تعداد تسک‌ها بیشتر از تعداد گره‌های تخصیص‌یافته نباشد.
- plane
- تسک‌ها در بلوک‌هایی به اندازه <size> توزیع می‌شوند. اندازه باید مشخص شود یا متغیر SLURM_DIST_PLANESIZE تنظیم شده باشد. تعداد تسک‌های توزیع‌شده به هر گره مانند توزیع چرخشی است، اما شناسه‌های تسک اختصاص‌یافته به هر گره به اندازه plane وابسته است. مشخصات توزیع اضافی را نمی‌توان با این گزینه ترکیب کرد. برای جزئیات بیشتر (شامل مثال‌ها و نمودارها)، لطفاً به https://slurm.schedmd.com/mc_support.html و https://slurm.schedmd.com/dist_plane.html مراجعه کنید.
- arbitrary
- روش توزیع
دلخواه (arbitrary)
فرایندها
را به ترتیب
فهرست‌شده
در فایلی که
توسط متغیر
محیطی SLURM_HOSTFILE
تعیین شده
است، تخصیص
می‌دهد. اگر
این متغیر
تعریف شده
باشد، بر هر
روش
مشخص‌شده
دیگری
اولویت
خواهد داشت.
در صورت عدم
تنظیم، روش
به طور
پیش‌فرض
روی block قرار
می‌گیرد.
فایل
میزبان‌ها
(hostfile) باید
حداقل حاوی
تعداد
میزبان‌های
درخواست‌شده
باشد و در
هر خط یک
مورد یا به
صورت
جداشده با
کاما قرار
گیرد. اگر
تعداد
تسک‌ها
مشخص شود (-n,
--ntasks=<number>)،
تسک‌های
شما به
ترتیب درون
فایل روی
گره‌ها
چیده
می‌شوند.
نکته: گزینه توزیع arbitrary تنها با روش تخصیص عمومی پشتیبانی می‌شود و نمی‌توان از آن با قابلیت‌هایی مانند topology، CR_LLN، CR_Pack_Nodes، یا pack_serial_at_end استفاده کرد. هدف اصلی این گزینه، کنترل چیدمان تسک‌های یک مرحله از کار (job step) در یک تخصیص کار موجود برای دستور srun است.
نکته: اگر تعداد تسک‌ها مشخص شده و فهرستی از گره‌های درخواستی نیز ارائه شده باشد، در صورتی که تعداد گره‌های فهرست بیشتر از تعداد تسک‌ها باشد، تعداد گره‌های استفاده‌شده از آن فهرست کاهش می‌یابد تا با تعداد تسک‌ها همخوانی داشته باشد.
روش توزیع دوم (توزیع CPUها در سرتاسر سوکت‌ها برای انتساب):
- *
- استفاده از روش پیش‌فرض برای توزیع CPUها روی سوکت‌ها (cyclic).
- block
- روش توزیع بلوکی (block) پیش از رفتن به سوکت متوالی بعدی، CPUهای تخصیص‌یافته را به صورت متوالی از همان سوکت برای انتساب به تسک‌ها توزیع می‌کند..IP
- cyclic
- روش توزیع cyclic
پردازنده‌های
تخصیص‌یافته
را جهت
مقیدسازی (binding)
به یک تسک
معین،
به‌صورت
متوالی از
یک سوکت و
برای تسک
بعدی از
سوکت
متوالی
بعدی، به
شیوهٔ
نوبت‌گردشی
(round-robin) در میان
سوکت‌ها
توزیع
می‌کند.
برای
تسک‌هایی
که به بیش
از یک
پردازنده
نیاز
دارند، در
صورت امکان
تمام آن
پردازنده‌ها
روی یک سوکت
واحد تخصیص
خواهند
یافت.
نکته: در گره‌هایی که hyper-threading فعال است، تسکی که هسته‌های کامل درخواست نمی‌کند ممکن است در میان سوکت‌ها توزیع شود. با مشخص کردن --ntasks-per-core=1 می‌توان از این مسئله جلوگیری کرد، که تسک‌ها را مجبور به تخصیص هسته‌های کامل می‌کند.
- fcyclic
- روش توزیع fcyclic پردازنده‌های تخصیص‌یافته را برای مقیدسازی به تسک‌ها، از سوکت‌های متوالی به شیوهٔ نوبت‌گردشی در میان سوکت‌ها توزیع می‌کند. برای تسک‌هایی که به بیش از یک پردازنده نیاز دارند، هر یک از پردازنده‌ها به روش چرخشی (cyclic) در میان سوکت‌ها تخصیص خواهند یافت.
روش توزیع سوم (توزیع پردازنده‌ها در میان هسته‌ها برای مقیدسازی):
- *
- استفاده از روش پیش‌فرض برای توزیع پردازنده‌ها در میان هسته‌ها (به ارث برده شده از روش توزیع دوم).
- block
- روش توزیع block پردازنده‌های تخصیص‌یافته را پیش از استفاده از هستهٔ متوالی بعدی، به‌صورت پیاپی از همان هسته برای مقیدسازی به تسک‌ها توزیع می‌کند.
- cyclic
- روش توزیع cyclic پردازنده‌های تخصیص‌یافته را جهت مقیدسازی به یک تسک معین، به‌طور پیاپی از همان هسته و برای تسک بعدی از هستهٔ متوالی بعدی، به شیوهٔ نوبت‌گردشی در میان هسته‌ها توزیع می‌کند.
- fcyclic
- روش توزیع fcyclic پردازنده‌های تخصیص‌یافته را برای مقیدسازی به تسک‌ها، از هسته‌های متوالی به شیوهٔ نوبت‌گردشی در میان هسته‌ها توزیع می‌کند.
کنترل اختیاری برای توزیع تسک‌ها روی گره‌ها:
- Pack
- به جای توزیع یکنواخت تسک‌های یک گام کاری (job step) در میان گره‌های تخصیص‌یافتهٔ آن، آنها را تا حد امکان به‌صورت فشرده روی گره‌ها قرار می‌دهد. این حالت فقط زمانی اعمال می‌شود که از روش توزیع تسک "block" استفاده شود.
- NoPack
- به جای فشرده‌سازی حداکثری تسک‌های یک گام کاری روی گره‌ها، آنها را به‌طور یکنواخت توزیع می‌کند. این گزینهٔ کاربری جایگزین پارامتر پیکربندی CR_Pack_Nodes در SelectTypeParameters خواهد شد.
- این گزینه برای تخصیص‌های job و step اعمال می‌شود.
- --epilog={none|<executable>}
- دستور srun برنامهٔ اجرایی executable را دقیقاً پس از تکمیل گام کاری اجرا خواهد کرد. آرگومان‌های خط فرمان برای executable همان دستور و آرگومان‌های گام کاری خواهند بود. اگر none مشخص شود، هیچ مؤخره‌ای (epilog) برای srun اجرا نخواهد شد. این پارامتر جایگزین پارامتر SrunEpilog در slurm.conf می‌شود. این پارامتر کاملاً مستقل از پارامتر Epilog در slurm.conf است. این گزینه برای تخصیص‌های job اعمال می‌شود.
- -e, --error=<filename_pattern>
- نحوهٔ تغییر مسیر stderr را مشخص می‌کند. به‌طور پیش‌فرض در حالت تعاملی (interactive)، srun اگر فایلی برای stdout مشخص شده باشد، stderr را به همان فایل تغییر مسیر می‌دهد. گزینهٔ --error برای این فراهم شده است که امکان تغییر مسیر stdout و stderr به مکان‌های متفاوتی وجود داشته باشد. برای گزینه‌های بیشتر بخش IO Redirection را در زیر ببینید. اگر فایل مشخص‌شده از قبل وجود داشته باشد، بازنویسی خواهد شد. این گزینه برای تخصیص‌های job و step اعمال می‌شود.
- --exact
- به یک گام (step)
اجازه
می‌دهد
تنها به
منابعی که
برای آن
درخواست
شده دسترسی
داشته باشد.
به‌طور
پیش‌فرض،
تمام منابع
غیر-GRES در هر
گره در
تخصیص گام
استفاده
خواهند شد.
این گزینه
فقط برای
تخصیص‌های
step اعمال
می‌شود.
نکته: گام‌های موازی یا مسدود می‌شوند یا رد خواهند شد تا زمانی که منابع درخواست‌شدهٔ گام در دسترس قرار گیرند، مگر اینکه --overlap مشخص شده باشد. منابع job می‌توانند پس از تکمیل دستور srun در حالی که Slurm در حال پاکسازی کار است نگه داشته شوند. مؤخره‌های step و/یا پلاگین‌های SPANK می‌توانند آزادسازی منابع step را بیش از این نیز به تأخیر بیندازند.
- -x, --exclude={<host1[,<host2>...]|<filename>}
- درخواست می‌کند که فهرست مشخصی از میزبان‌ها در منابع تخصیص‌یافته به این job گنجانده نشوند. در صورتی که فهرست میزبان حاوی نویسهٔ "/" باشد، به عنوان یک نام فایل در نظر گرفته خواهد شد. این گزینه برای تخصیص‌های job و step اعمال می‌شود.
- --exclusive[={allocation|mcs|topo|user}]
- بسته به
زمینه،
منابع
انحصاری را
برای job یا job step
درخواست
می‌کند.
هنگامی که srun
--exclusive برای
راه‌اندازی
یک step در یک job
در حال اجرا
استفاده
شود،
هم‌معنی با
--exact خواهد
بود.
هنگامی که srun --exclusive برای آغاز هم‌زمان یک job و یک step استفاده شود، هم گره‌های کامل (whole nodes) و هم رفتار --exact اجرا خواهند شد؛ بدین معنی که تمام منابع یک یا چند گره به job تخصیص داده می‌شود و فقط منابع مشخص‌شده به هر تسک درون step اعطا خواهد شد. گزینهٔ allocation گره‌های کامل را دریافت می‌کند اما رفتار --exact را اعمال نمی‌کند -- بدین معنی که هر گام به تمام منابع موجود در تخصیص دسترسی خواهد داشت (مشابه اجرای srun بدون سایر گزینه‌های محدودکننده در یک تخصیص در حال اجرا). گزینهٔ allocation را می‌توان با تنظیم LaunchParameters=srun_exclusive_allocation در slurm.conf به حالت پیش‌فرض تبدیل کرد.
گزینه‌های (mcs|topo|user) صرفاً برای کنترل نحوهٔ اشتراک منابع بین چندین job هنگامی که srun برای تخصیص یک job استفاده می‌شود وجود دارند و دلالتی بر --exact ندارند. هنگامی که برای آغاز یک job استفاده شوند، تخصیص job نمی‌تواند گره‌ها (یا بخش توپولوژی با "=topo") را با سایر کارهای در حال اجرا (یا فقط با سایر کاربران با گزینهٔ "=user" یا گزینهٔ "=mcs") به اشتراک بگذارد. اگر user/mcs/topo مشخص نشده باشند (یعنی تخصیص job نتواند گره‌ها را با سایر کارهای در حال اجرا به اشتراک بگذارد)، به تخصیص job تمام CPUها و GRESها روی تمام گره‌های موجود در تخصیص اختصاص می‌یابد، اما حافظه فقط به همان میزانی که درخواست شده تخصیص می‌یابد. این بر اساس طراحی به منظور پشتیبانی از gang scheduling است، زیرا کارهای معلق‌شده (suspended) همچنان در حافظه باقی می‌مانند. برای درخواست تمام حافظه روی یک گره، از --mem=0 استفاده کنید. رفتار پیش‌فرض اشتراکی/انحصاری به پیکربندی سیستم بستگی دارد و گزینهٔ OverSubscribe مربوط به پارتیشن، بر گزینهٔ job اولویت دارد. نکته: از آنجا که GRES اشتراکی (MPS) نمی‌تواند هم‌زمان با یک GRES به اشتراک‌گذارنده (GPU) تخصیص یابد، این گزینه فقط تمام GRESهای به اشتراک‌گذارنده را تخصیص می‌دهد و هیچ GRES اشتراکی زیربنایی را تخصیص نخواهد داد.
نکته: این گزینه با --oversubscribe ناسازگار (مانعةالجمع) است.
بخش EXAMPLE را در زیر ببینید.
- --export={[ALL,]<environment_variables>|ALL|NONE}
- مشخص می‌کند که کدام متغیرهای محیطی از محیط ارسال (submission environment) به برنامهٔ راه‌اندازی‌شده منتقل شوند.
- --export=ALL
- حالت پیش‌فرض در صورتی که --export مشخص نشده باشد. تمام محیط کاربری از محیط فراخواننده بارگذاری خواهد شد.
- --export=NONE
- هیچ بخشی از
محیط
کاربری
تعریف
نخواهد شد.
کاربر باید
از مسیر
مطلق برای
فایل
باینری
اجرایی
استفاده
کند که محیط
را تعریف
خواهد کرد.
کاربر
نمی‌تواند
هم‌زمان با
"NONE"
متغیرهای
محیطی
صریحی را
مشخص کند.
این گزینه به‌ویژه برای کارهایی که در یک کلاستر ارسال شده و در کلاستر متفاوتی اجرا می‌شوند (برای مثال با مسیرهای متفاوت) اهمیت دارد. برای جلوگیری از به ارث بردن تنظیمات صدور محیط (مانند "NONE") توسط گام‌ها از دستور sbatch، یا --export=ALL را تنظیم کنید و یا متغیر محیطی SLURM_EXPORT_ENV باید برابر با "ALL" قرار گیرد..IP
- --export=[ALL,]<environment_variables>
- همه متغیرهای محیطی SLURM* را به همراه متغیرهای به‌صراحت تعریف‌شده صادر (export) می‌کند. نام چندین متغیر محیطی باید با کاما از یکدیگر جدا شوند. نام‌های متغیرهای محیطی می‌توانند برای انتقال مقدار فعلی مشخص شوند (مانند "--export=EDITOR") یا مقادیر مشخصی ممکن است صادر شوند (مانند "--export=EDITOR=/bin/emacs"). اگر "ALL" مشخص شود، تمام متغیرهای محیطی کاربر بارگذاری خواهند شد و نسبت به هر متغیر محیطی که به‌صراحت داده شده است اولویت خواهند داشت.
- مثال: --export=EDITOR,ARG1=test
- در این مثال، محیط منتقل‌شده تنها شامل متغیر EDITOR از محیط کاربر، متغیرهای محیطی SLURM_*، و ARG1=test خواهد بود.
- مثال: --export=ALL,EDITOR=/bin/emacs
- برای این مثال دو نتیجه ممکن وجود دارد. اگر فراخواننده متغیر محیطی EDITOR را تعریف کرده باشد، محیط کار این متغیر را از محیط فراخواننده به ارث خواهد برد. اگر فراخواننده متغیر محیطی تعریف‌شده‌ای برای EDITOR نداشته باشد، محیط کار از مقدار ارائه‌شده توسط --export استفاده خواهد کرد.
- --external-launcher
- یک گام (step)
ویژه روی یک
یا چند گره
تخصیص‌یافته
ایجاد
می‌کند که
هیچ منبعی
مصرف
نخواهد
کرد، اما به
تمامی
منابع
تخصیص‌یافته
کار روی آن
گره‌ها
دسترسی
خواهد داشت.
گزینه‌هایی مانند --ntasks-per-*، --mem*، --cpus*، --tres*، --gres* نادیده گرفته خواهند شد.
این گزینه برای استفاده در پیاده‌سازی‌های MPI است که به اجراکننده (launcher) اختصاصی خود نیاز دارند. این گزینه گامی را با دسترسی به تمام منابع راه‌اندازی می‌کند که بعداً هر تعداد فرایند کاربری با دسترسی به همه این منابع ایجاد خواهد کرد.
مصرف منابع در این گام ویژه همچنان در صورت فعال بودن افزونه‌های حسابداری (accounting) محاسبه خواهد شد. این گام ویژه می‌تواند با هر گام دیگری همپوشانی داشته باشد.
نکته: این گزینه برای استفاده مستقیم در نظر گرفته نشده است.
- --extra=<string>
- یک رشته
دلخواه که
در صورت
استفاده از
فاصله‌ها
یا برخی
نویسه‌های
خاص، در
علامت
نقل‌قول
تکی یا
دوتایی
قرار
می‌گیرد.
اگر SchedulerParameters=extra_constraints فعال باشد، این رشته برای فیلتر کردن گره‌ها بر اساس فیلد Extra در هر گره استفاده می‌شود.
- -B, --extra-node-info=<sockets>[:cores[:threads]]
- انتخاب گره
را به
گره‌هایی
محدود
می‌کند که
حداقل
تعداد
مشخص‌شده
سوکت، هسته
در هر سوکت
و/یا رشته (thread)
در هر هسته
را داشته
باشند.
نکته: این گزینه‌ها اندازه تخصیص منابع را مشخص نمی‌کنند. هر مقدار مشخص‌شده به عنوان یک حداقل در نظر گرفته می‌شود. از علامت ستاره (*) می‌توان به عنوان جایگزین بدون محدود کردن انتخاب گره برای آن نوع استفاده کرد. در صورت تمایل، سطوح مجزا را می‌توان در گزینه‌های جداگانه نیز مشخص کرد:
-
--sockets-per-node=<sockets> --cores-per-socket=<cores> --threads-per-core=<threads>
اگر افزونه task/affinity فعال باشد، مشخص کردن یک تخصیص به این روش همچنین گزینه پیش‌فرض --cpu-bind از نوع threads را تنظیم می‌کند در صورتی که گزینه -B تعداد رشته را مشخص کرده باشد؛ در غیر این صورت گزینه cores اگر تعداد هسته مشخص شده باشد؛ و در غیر این صورت گزینه sockets. اگر SelectType روی select/cons_tres پیکربندی شده باشد، برای اینکه این گزینه لحاظ شود، باید پارامتری از نوع CR_Core، CR_Core_Memory، CR_Socket، یا CR_Socket_Memory داشته باشد. اگر مشخص نشود، دستور scontrol show job مقدار 'ReqS:C:T=*:*:*' را نمایش خواهد داد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
نکته: این گزینه با --hint، --threads-per-core و --ntasks-per-core ناسازگار (مانعةالجمع) است.
نکته: اگر تعداد سوکت‌ها، هسته‌ها و رشته‌ها همگی مشخص شده باشند، تعداد گره‌ها مشخص شده باشد (به صورت یک عدد ثابت، نه یک بازه) و تعداد وظایف (tasks) مشخص NOT شده باشد، srun به طور ضمنی تعداد وظایف را به صورت یک وظیفه به ازای هر رشته محاسبه می‌کند.
- --gpu-bind=[verbose,]<type>
- معادل با --tres-bind=gres/gpu:[verbose,]<type> برای تمام گزینه‌ها و مستندات، --tres-bind را ببینید.
- --gpu-freq=[<type]=value>[,<type=value>][,verbose]
- درخواست
می‌کند که
GPUهای
تخصیص‌یافته
به کار با
مقادیر
فرکانس
خاصی
پیکربندی
شوند. این
گزینه
می‌تواند
برای
پیکربندی
مستقل
فرکانس‌های
GPU و حافظه آن
استفاده
شود. پس از
تکمیل کار،
فرکانس‌های
تمام GPUهای
تحت تأثیر
به
بالاترین
مقادیر
ممکن
بازنشانی
خواهند شد.
در برخی
موارد، سقف
توان مصرفی
سیستم (power caps)
ممکن است بر
مقادیر
درخواست‌شده
اولویت
یافته و
اعمال شوند.
فیلد type
می‌تواند
"memory" باشد.
اگر type مشخص
نشود،
فرکانس GPU مد
نظر است.
فیلد value
می‌تواند
یکی از
مقادیر "low"،
"medium"، "high"، "highm1"
یا یک مقدار
عددی بر حسب
مگاهرتز (MHz)
باشد. اگر
مقدار عددی
مشخص‌شده
امکان‌پذیر
نباشد،
نزدیک‌ترین
مقدار ممکن
استفاده
خواهد شد.
برای تعریف
مقادیر به
موارد زیر
مراجعه
کنید. گزینه
verbose باعث ثبت
اطلاعات
فرکانس
فعلی GPU در
لاگ می‌شود.
مثال‌های
استفاده
شامل "--gpu-freq=medium,memory=high"
و "--gpu-freq=450" است.
تعاریف مقادیر (value) پشتیبانی‌شده:
- low
- پایین‌ترین فرکانس موجود.
- medium
- تلاش می‌کند فرکانسی در میانه محدوده موجود تنظیم کند.
- high
- بالاترین فرکانس موجود.
- highm1
- (یکی کمتر از بالاترین) فرکانس بعدیِ نزدیک به بالاترین فرکانس موجود را انتخاب می‌کند.
- -G, --gpus=[type:]<number>
- تعداد کل
GPUهای مورد
نیاز برای
کار را مشخص
می‌کند.
مشخص کردن
نوع
اختیاری GPU
نیز
امکان‌پذیر
است. همچنین
گزینه‌های
--gpus-per-node، --gpus-per-socket و
--gpus-per-task را
ببینید.
نکته: تخصیص باید حداقل شامل یک GPU در هر گره باشد، یا در صورت استفاده از انواع، یک مورد از هر نوع GPU در هر گره وجود داشته باشد. اگر گره‌های مختلف به انواع مختلفی از GPU نیاز دارند، از کارهای ناهمگن (heterogeneous jobs) استفاده کنید.
- --gpus-per-node=[type:]<number>
- تعداد GPUهای
مورد نیاز
برای کار را
روی هر گرهِ
موجود در
تخصیص
منابع کار
مشخص
می‌کند.
مشخص کردن
نوع
اختیاری GPU
نیز
امکان‌پذیر
است. برای
مثال "--gpus-per-node=volta:3".
می‌توان
چند گزینه
را در یک
فهرست
جداشده با
کاما
درخواست
کرد، به
عنوان مثال:
"--gpus-per-node=volta:3,kepler:1".
همچنین
گزینه‌های
--gpus، --gpus-per-socket و
--gpus-per-task را
ببینید.
نکته: این گزینه با --gres=gpu ناسازگار (مانعةالجمع) است.
- --gpus-per-socket=[type:]<number>
- تعداد GPUهای مورد نیاز برای کار را روی هر سوکتِ موجود در تخصیص منابع کار مشخص می‌کند. مشخص کردن نوع اختیاری GPU نیز امکان‌پذیر است. برای مثال "--gpus-per-socket=volta:3". می‌توان چند گزینه را در یک فهرست جداشده با کاما درخواست کرد، به عنوان مثال: "--gpus-per-socket=volta:3,kepler:1". نیاز دارد که در کار تعداد سوکت در هر گره (--sockets-per-node) مشخص شده باشد. همچنین گزینه‌های --gpus، --gpus-per-node و --gpus-per-task را ببینید. این گزینه برای تخصیص‌های کار اعمال می‌شود..IP
- --gpus-per-task=[type:]<number>
- تعداد GPUهای مورد نیاز برای کار به ازای هر تسکی که قرار است در تخصیص منابع کار ایجاد شود را مشخص می‌کند. می‌توان یک نوع GPU اختیاری را نیز تعیین کرد. به عنوان مثال "--gpus-per-task=volta:1". چندین گزینه را می‌توان در یک فهرست جدا شده با ویرگول درخواست کرد، برای مثال: "--gpus-per-task=volta:3,kepler:1". همچنین گزینه‌های --gpus، --gpus-per-socket و --gpus-per-node را ببینید. این گزینه نیازمند تعداد تسک صریح است، مانند -n، --ntasks یا "--gpus=X --gpus-per-task=Y" به جای بازه مبهمی از گره‌ها با -N، --nodes. این گزینه به صورت ضمنی --tres-bind=gres/gpu:per_task:<gpus_per_task>، یا در صورت مشخص شدن چندین نوع gpu، مقدار --tres-bind=gres/gpu:per_task:<gpus_per_task_type_sum> را تنظیم می‌کند. با این حال، می‌توان آن را با تعیین صریح --tres-bind=gres/gpu بازنویسی کرد.
- --gres=<list>
- فهرستی جدا
شده با
ویرگول از
منابع
عمومی
مصرفی (generic consumable resources)
درخواست‌شده
برای هر گره
را مشخص
می‌کند.
قالب هر
ورودی در
این فهرست
به صورت
"name[[:type]:count]" است.
بخش name نوع
منبع مصرفی
است (مانند gpu).
بخش type
دسته‌بندی
اختیاری
برای منبع
است (مانند a100).
بخش count
تعداد آن
منابع با
مقدار
پیش‌فرض ۱
است. تعداد
می‌تواند
دارای
پسوندی از
"k" یا "K"
(مضرب
۱۰۲۴)، "m" یا
"M" (مضرب
۱۰۲۴ ×
۱۰۲۴)، "g" یا
"G" (مضرب
۱۰۲۴ × ۱۰۲۴
× ۱۰۲۴)، "t"
یا "T" (مضرب
۱۰۲۴ × ۱۰۲۴
× ۱۰۲۴ ×
۱۰۲۴)، "p" یا
"P" (مضرب
۱۰۲۴ × ۱۰۲۴
× ۱۰۲۴ ×
۱۰۲۴ ×
۱۰۲۴) باشد.
منابع
مشخص‌شده
در هر گره
به کار
تخصیص داده
خواهند شد.
منابع
عمومی
مصرفی در
دسترس توسط
مدیر سیستم
قابل
پیکربندی
است. اگر
آرگومان
گزینه "help"
باشد،
فهرستی از
منابع
عمومی
مصرفی در
دسترس چاپ
شده و دستور
خارج
می‌شود.
مثال‌های
کاربرد
شامل "--gres=gpu:2"،
"--gres=gpu:kepler:2" و "--gres=help"
است. نکته:
این گزینه
برای
تخصیص‌های
کار و گام
کار (step) اعمال
می‌شود. به
طور
پیش‌فرض،
به یک گام
کار تمام
منابع
عمومی که
توسط کار
درخواست
شده‌اند
تخصیص
می‌یابد،
به جز
مواردی که
هنگام
انحصاری (exclusive)
بودن کار به
طور ضمنی
درخواست
شده‌اند.
برای تغییر
این رفتار
به گونه‌ای
که به هیچ
گام کاری
منبع عمومی
تخصیص داده
نشود،
مقدار --gres را
به صورت
صریح با
تعداد صفر
برای هر
منبع عمومی
تنظیم
کنید، یا
"--gres=none" را قرار
دهید، یا
متغیر
محیطی SLURM_STEP_GRES را
برابر با "none"
بگذارید.
نکته: این گزینه با --gpus-per-node مانعةالجمع (ناسازگار) است.
- --gres-flags=<type>
- گزینه‌های مقیدسازی تسک به منابع عمومی (generic resource task binding) را مشخص می‌کند.
- allow-task-sharing
- به تسک‌ها
اجازه
دسترسی به
هر GPU در
تخصیص کار
که روی همان
گره تسک
قرار دارد
را می‌دهد.
این گزینه
زمانی مفید
است که از --gpu-bind
یا --tres-bind=gres/gpu برای
مقید کردن
GPUها به
تسک‌های
مشخص
استفاده
می‌شود،
اما ارتباط
میان GPUها
بین تسک‌ها
نیز مورد
نیاز است.
نکته: این گزینه منحصر به srun است.
- multiple-tasks-per-sharing
- گزینه one-task-per-sharing را نفی می‌کند. این گزینه زمانی کاربرد دارد که به طور پیش‌فرض در SelectTypeParameters تنظیم شده باشد.
- disable-binding
- گزینه enforce-binding را نفی می‌کند. این گزینه زمانی کاربرد دارد که به طور پیش‌فرض در SelectTypeParameters تنظیم شده باشد.
- enforce-binding
- تنها
پردازنده‌های
(CPU) در دسترس
کار مواردی
خواهند بود
که به GRES
انتخابی
مقید
شده‌اند
(یعنی CPUهای
مشخص‌شده
در فایل gres.conf
به دقت
اعمال
خواهند شد).
این گزینه
ممکن است
باعث تأخیر
در شروع کار
شود. برای
مثال، کاری
که نیازمند
دو GPU و یک CPU
است تا
زمانی که هر
دو GPU روی یک
سوکت منفرد
در دسترس
قرار
نگیرند به
تأخیر
می‌افتد،
به جای
اینکه از
GPUهای مقید
به
سوکت‌های
جداگانه
استفاده
کند؛ با این
حال،
کارایی
برنامه
ممکن است به
دلیل بهبود
سرعت
ارتباط
افزایش
یابد.
مستلزم این
است که گره
با بیش از
یک سوکت
پیکربندی
شده باشد و
فیلتر
منابع بر
پایه هر
سوکت انجام
خواهد شد.
نکته: این گزینه می‌تواند به طور پیش‌فرض در SelectTypeParameters تنظیم شود.
نکته: این گزینه برای تخصیص‌های کار، منحصر به SelectType=cons_tres است.
نکته: این گزینه در صورت تلاش برای اجبار به مقیدسازی روی چندین gres در چندین سوکت می‌تواند نتایج تعریف‌نشده به همراه داشته باشد.
- one-task-per-sharing
- اجازه
تخصیص gresهای
اشتراکی از
یک sharing gres یکسان
به تسک‌های
مختلف داده
نمی‌شود.
نکته: این پرچم تنها در صورتی اعمال می‌شود که gresهای اشتراکی با --tres-per-task درخواست شده باشند.
نکته: این گزینه می‌تواند به صورت پیش‌فرض با SelectTypeParameters=ONE_TASK_PER_SHARING_GRES تنظیم شود.
نکته: این گزینه منحصر به SelectTypeParameters=MULTIPLE_SHARING_GRES_PJ است.
- -h, --help
- نمایش اطلاعات راهنما و خروج.
- --het-group=<expr>
- هر مؤلفه را در یک تخصیص کار ناهمگن که قرار است گامی برای آن ایجاد شود شناسایی می‌کند. فقط برای دستورات srun اجرا شده درون یک تخصیص salloc یا اسکریپت sbatch اعمال می‌شود. عبارت <expr> مجموعه‌ای از اعداد صحیح متناظر با یک یا چند آفست گزینه در خط فرمان salloc یا sbatch است. مثال‌ها: "--het-group=2"، "--het-group=0,4"، "--het-group=1,3-5". مقدار پیش‌فرض --het-group=0 است.
- --hint=<type>
- تسک‌ها را
بر اساس
رهنمودهای
برنامه (application hints)
مقید
می‌کند.
نکته: این گزینه متضمن مقادیر مشخصی برای برخی گزینه‌های مرتبط است، که مانع از استفاده آن در کنار هرگونه مقدار تعیین‌شده توسط کاربر برای --ntasks-per-core، --cores-per-socket، --sockets-per-node، --threads-per-core، --cpu-bind (به جز --cpu-bind=verbose) یا -B می‌شود. این گزینه‌های متداخل در صورت مشخص شدن به عنوان آرگومان‌های خط فرمان، بر --hint اولویت خواهند داشت. اگر گزینه متداخل به صورت متغیر محیطی تعیین شده باشد، --hint به عنوان آرگومان خط فرمان اولویت خواهد داشت.
- compute_bound
- تنظیمات مربوط به برنامه‌های وابسته به محاسبات (compute bound) را انتخاب می‌کند: استفاده از تمام هسته‌ها در هر سوکت، یک رشته به ازای هر هسته.
- memory_bound
- تنظیمات مربوط به برنامه‌های وابسته به حافظه (memory bound) را انتخاب می‌کند: استفاده از تنها یک هسته در هر سوکت، یک رشته به ازای هر هسته.
- multithread
- استفاده از رشته‌های اضافی با چندرشتگی درون‌هسته‌ای (in-core multi-threading) که می‌تواند برای برنامه‌های با ارتباطات فشرده مفید باشد. تنها با پلاگین task/affinity پشتیبانی می‌شود.
- nomultithread
- عدم استفاده از رشته‌های اضافی با چندرشتگی درون‌هسته‌ای؛ تسک‌ها را به یک رشته به ازای هر هسته محدود می‌کند. تنها با پلاگین task/affinity پشتیبانی می‌شود.
- help
- نمایش این پیام راهنما
- این گزینه برای تخصیص‌های کار اعمال می‌شود.
- -H, --hold
- مشخص می‌کند که کار باید در وضعیت نگه‌داشته‌شده یا تعلیق (held state با اولویت صفر) ارسال شود. یک کار نگه‌داشته‌شده را می‌توان بعداً با استفاده از scontrol جهت بازنشانی اولویت آن آزاد کرد (برای مثال «scontrol release <job_id>»). این گزینه برای تخصیص‌های کار (job allocations) اعمال می‌شود.
- --ignore-signals=<signals_list>
- فهرستی از سیگنال‌های جداشده با کاما را مشخص می‌کند که srun باید آنها را نادیده بگیرد. هم نام‌ها و هم شماره‌های سیگنال پذیرفته می‌شوند. به‌طور معمول srun با هدایت این سیگنال‌ها به وظایف (tasks) در حال اجرا یا با انجام پاکسازی به آنها واکنش نشان می‌دهد؛ هنگامی که یک سیگنال در اینجا فهرست شود، srun هیچ واکنشی روی آن انجام نمی‌دهد. نادیده گرفتن سیگنال‌ها ممکن است با سازوکارهای لغو یا سایر روش‌های کنترل رفتار کار تداخل پیدا کند. پیش از استفاده از این گزینه، جزئیات ذکر شده در زیر را با دقت بررسی کنید. سیگنال‌های معتبر و رفتار پیش‌فرض در برابر آنها به شرح زیر است:
- SIGINT
- یک توالی لغو تعاملی (interactive abort sequence) را آغاز می‌کند. نادیده گرفتن این سیگنال مانع از خاتمه srun با فشردن کلیدهای Ctrl+C خواهد شد.
- SIGQUIT
- به‌عنوان SIGKILL فوروارد می‌شود.
- SIGTERM
- به‌عنوان SIGKILL فوروارد می‌شود. نادیده گرفتن این سیگنال درون تخصیص‌های sbatch/salloc ممکن است خاتمه کار را در صورت اجرای scancel یا اتمام زمان (timeout) به تأخیر بیندازد.
- SIGHUP
- به‌عنوان SIGKILL فوروارد می‌شود. نادیده گرفتن این سیگنال ممکن است خاتمه کار را هنگام قطع اتصال پایانه (hangup) یا در انتهای یک تخصیص تعاملی salloc به تأخیر انداخته و در وظایف پاکسازی تداخل ایجاد کند.
- SIGUSR1
- عیناً به وظایف (tasks) فوروارد می‌شود.
- SIGUSR2
- عیناً به وظایف (tasks) فوروارد می‌شود.
- -I, --immediate[=<seconds>]
- در صورتی که منابع در بازه زمانی مشخص‌شده در دسترس نباشند، خارج می‌شود. اگر هیچ آرگومانی داده نشود (مقدار پیش‌فرض seconds برابر با ۱ است)، منابع باید بلافاصله در دسترس باشند تا درخواست موفق شود. اگر defer در SchedulerParameters پیکربندی شده باشد و seconds=1 باشد، درخواست تخصیص بلافاصله شکست خواهد خورد؛ defer با این گزینه تداخل داشته و بر آن اولویت دارد. به‌طور پیش‌فرض، --immediate خاموش است و دستور تا زمانی که منابع در دسترس قرار گیرند متوقف (block) خواهد شد. از آنجا که آرگومان این گزینه اختیاری است، برای تجزیه (parsing) صحیح، گزینه تک‌حرفی باید بلافاصله با مقدار همراه شود و بین آنها فاصله‌ای نباشد؛ به عنوان مثال «-I60» و نه «-I 60». این گزینه برای تخصیص‌های کار (job) و گام (step) اعمال می‌شود.
- -i, --input=<mode>
- نحوه تغییر مسیر ورودی استاندارد (stdin) را مشخص می‌کند. به‌طور پیش‌فرض، srun ورودی استاندارد stdin را از پایانه به تمام وظایف تغییر مسیر می‌دهد. برای گزینه‌های بیشتر بخش IO Redirection را در ادامه ببینید. در سیستم‌عامل OS X، تابع poll() از stdin پشتیبانی نمی‌کند، بنابراین دریافت ورودی از یک پایانه امکان‌پذیر نیست. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- -J, --job-name=<jobname>
- نامی را برای کار مشخص می‌کند. نام مشخص‌شده هنگام پرس‌وجوی کارهای در حال اجرا روی سیستم، در کنار شماره شناسه کار (job ID) نمایش داده خواهد شد. مقدار پیش‌فرض، نام فایل برنامه قابل‌اجرای (executable) ارائه‌شده است. نکته: این اطلاعات ممکن است در فایل slurm_jobacct.log نوشته شود. این فایل با فاصله (space) جدا می‌شود، بنابراین اگر در jobname از فاصله استفاده شود، هنگام استفاده از دستور sacct در نمایش مناسب محتویات فایل slurm_jobacct.log اختلال ایجاد خواهد شد. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --jobid=<jobid>
- یک گام کاری (job step) را تحت یک کارِ از پیش تخصیص‌یافته با شناسه id آغاز می‌کند. استفاده از این گزینه باعث می‌شود srun دقیقاً همانند زمانی رفتار کند که متغیر محیطی SLURM_JOB_ID تنظیم شده باشد. این گزینه برای تخصیص‌های گام (step allocations) اعمال می‌شود.
- -K, --kill-on-bad-exit[=0|1]
- تعیین می‌کند که آیا در صورت خروج هر یک از وظایف با یک کد خروج غیر صفر، گام کاری خاتمه یابد یا خیر. اگر این گزینه مشخص نشود، اقدام پیش‌فرض بر اساس پارامتر پیکربندی Slurm با عنوان KillOnBadExit انجام خواهد شد. اگر این گزینه مشخص شود، بر KillOnBadExit اولویت خواهد داشت. آرگومان صفر برای این گزینه کار را خاتمه نخواهد داد. یک آرگومان غیر صفر یا بدون آرگومان بودن آن، کار را خاتمه می‌دهد. نکته: این گزینه جهت خاتمه فوری کار در صورت خروج یک وظیفه با کد غیر صفر، بر گزینه -W, --wait اولویت دارد. از آنجا که آرگومان این گزینه اختیاری است، برای تجزیه مناسب، گزینه تک‌حرفی باید بلافاصله با مقدار همراه شود و بین آنها فاصله‌ای نباشد؛ به عنوان مثال «-K1» و نه «-K 1».
- -l, --label
- شماره وظیفه (task) را به ابتدای خطوط stdout/err اضافه می‌کند. گزینه --label خطوط خروجی را با شناسه وظیفه دوردست (remote task id) پیشوندگذاری می‌کند. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- -L, --licenses=<license>[@db][:count][,license[@db][:count]...]
- مشخص‌کردن
مجوزها (یا
سایر منابع
موجود در
تمام
گره‌های
کلاستر) که
باید به این
کار تخصیص
داده شوند.
نام‌های
مجوز
می‌توانند
با دونقطه
و تعداد
دنبال شوند
(تعداد
پیش‌فرض یک
است).
می‌توان
چندین مجوز
را درخواست
کرد. اگر
آنها با
کاما جدا
شده باشند (','
به معنای AND)،
آنگاه
تمامی
مجوزهای
درخواستی
برای کار
لازم
خواهند
بود؛ برای
مثال "--licenses=foo:4,bar".
اگر با یک
خط عمودی
جدا شوند ('|'
به معنای OR)،
آنگاه تنها
یکی از
مجوزهای
درخواستی
برای کار
لازم خواهد
بود؛ برای
مثال "--licenses=foo:4|bar".
امکان
استفاده
هم‌زمان از
AND و OR وجود
ندارد. برای
ارسال
کارها با
استفاده از
مجوزهای
دوردست
(آن‌هایی که
توسط slurmdbd
ارائه
می‌شوند)،
نام سرور
ارائه‌دهنده
مجوزها را
مشخص کنید؛
برای مثال
"--license=nastran@slurmdb:12". اگر
LicenseParameters=RemoteFuzzyMatch در slurm.conf
تنظیم شده
باشد، حذف
نام سرور
امکان‌پذیر
است.
نکته: هنگام ارسال کارهای ناهمگن (heterogeneous jobs)، درخواست‌های مجوز تنها می‌توانند روی اولین بخش کار (component job) اعمال شوند؛ برای مثال "srun -L ansys:2 : myexecutable".
نکته: اگر مجوزها در AccountingStorageTres ردیابی شوند و از OR استفاده شده باشد، ReqTRES تمام tresهای درخواستی را به صورت جداشده با کاما نمایش می‌دهد. AllocTRES تنها مجوزی را نمایش خواهد داد که به کار تخصیص یافته است.
نکته: هنگامی که یک کار مجوزهایی را با عملگر OR درخواست می‌کند، Slurm تلاش می‌کند مجوزها را به همان ترتیبی که درخواست شده‌اند تخصیص دهد. این ترتیبِ مشخص‌شده اولویت خواهد داشت، حتی اگر باقی مجوزهای درخواستی بتوانند روی یک رزروِ درخواستی برآورده شوند. این مورد برای برنامه‌ریزی backfill در زمانی که SchedulerParameters=bf_licenses پیکربندی شده باشد نیز صدق می‌کند.
- --mail-type=<type>
- هنگام وقوع انواع خاصی از رویدادها، کاربر را از طریق ایمیل مطلع می‌کند. مقادیر معتبر type عبارتند از NONE، BEGIN، END، FAIL، REQUEUE، ALL (معادل BEGIN، END، FAIL، INVALID_DEPEND، REQUEUE و STAGE_OUT)، INVALID_DEPEND (وابستگی هرگز برآورده نشد)، STAGE_OUT (خاتمه مرحله انتقال به بیرون بافر جهشی و آزادسازی آن)، TIME_LIMIT، TIME_LIMIT_90 (رسیدن به ۹۰ درصد محدودیت زمانی)، TIME_LIMIT_80 (رسیدن به ۸۰ درصد محدودیت زمانی) و TIME_LIMIT_50 (رسیدن به ۵۰ درصد محدودیت زمانی). چندین مقدار type می‌توانند در یک فهرست جداشده با کاما مشخص شوند. مقدار NONE تمام اعلان‌های رویدادها را متوقف کرده و سایر مقادیر مشخص‌شده را نادیده می‌گیرد. به‌طور پیش‌فرض هیچ اعلان ایمیلی ارسال نمی‌شود. کاربری که باید مطلع شود با --mail-user مشخص می‌گردد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --mail-user=<user>
- کاربری که باید اعلان ایمیلِ تغییرات وضعیت را بر اساس تعاریف --mail-type دریافت کند. این مقدار می‌تواند یک آدرس ایمیل کامل یا یک نام کاربری باشد. اگر یک نام کاربری مشخص شود، مقدار MailDomain در slurm.conf به آن افزوده می‌شود تا یک آدرس ایمیل ساخته شود. مقدار پیش‌فرض، کاربر ارسال‌کننده است. این گزینه برای تخصیص‌های کار اعمال می‌شود..IP
- --mcs-label=<mcs>
- تنها زمانی استفاده می‌شود که یک MCSPlugin سازگار فعال باشد. این پارامتر گروهی است که کاربر به آن تعلق دارد (mcs/group) یا یک رشته برچسب اختیاری (mcs/label). در هر دو حالت، به‌طور پیش‌فرض هیچ برچسبی تخصیص داده نخواهد شد. این گزینه برای تخصیص‌های کار (job) اعمال می‌شود. برای جزئیات بیشتر به مستندات MCS مراجعه کنید: https://slurm.schedmd.com/mcs.html
- --mem=<size>[units]
- حافظه
واقعی مورد
نیاز به
ازای هر گره
(node) را مشخص
می‌کند.
واحد
پیش‌فرض
مبی‌بایت
(mebibytes) است.
واحدهای
مختلف را
می‌توان با
استفاده از
پسوند [K|M|G|T]
مشخص کرد.
مقدار
پیش‌فرض
DefMemPerNode و
حداکثر
مقدار MaxMemPerNode
است. در
صورت
پیکربندی،
هر دو
پارامتر با
استفاده از
دستور scontrol show config
قابل
مشاهده
هستند. این
پارامتر
معمولاً در
صورتی
استفاده
می‌شود که
گره‌ها
به‌طور
کامل به
کارها
تخصیص داده
شوند (SelectType=select/linear).
تعیین
محدودیت
حافظه
برابر با
صفر برای یک
گام کار (job step)،
گام کار را
به میزان
حافظه
تخصیص‌یافته
به کار
محدود
می‌کند،
اما هیچ
بخشی از
تخصیص
حافظه کار
را از دسترس
سایر
گام‌های
کار خارج
نمی‌سازد.
همچنین --mem-per-cpu
و --mem-per-gpu را
ببینید.
گزینه‌های
--mem، --mem-per-cpu و --mem-per-gpu
مانعةالجمع
هستند. اگر
--mem، --mem-per-cpu یا
--mem-per-gpu به
عنوان
آرگومان‌های
خط فرمان
مشخص شوند،
بر
متغیرهای
محیطی (که
احتمالاً
از salloc یا sbatch
به ارث
رسیده‌اند)
اولویت
خواهند
داشت.
نکته: تعیین اندازه حافظه برابر با صفر به عنوان یک حالت خاص در نظر گرفته می‌شود و برای کارهای تازه ارسال‌شده، دسترسی به تمام حافظه هر گره و برای گام‌های کاری جدید، دسترسی به تمام حافظه در دسترس کار را اعطا می‌کند.
نکته: حافظه مصرفی توسط هر فرایند slurmstepd در کل مصرف حافظه کار لحاظ می‌شود. این مقدار معمولاً بین 20MiB تا 200MiB مصرف می‌کند، اگرچه بسته به پیکربندی سیستم و پلاگین‌های بارگذاری‌شده ممکن است متغیر باشد.
نکته: درخواست‌های حافظه به‌طور سخت‌گیرانه اعمال نخواهند شد مگر اینکه Slurm برای استفاده از یک سازوکار اعمال محدودیت پیکربندی شده باشد. برای جزئیات بیشتر به ConstrainRAMSpace در صفحه راهنمای cgroup.conf(5) و OverMemoryKill در صفحه راهنمای slurm.conf(5) مراجعه کنید.
این گزینه برای تخصیص‌های کار و گام کار اعمال می‌شود.
- --mem-bind=[{quiet|verbose},]<type>
- تسک‌ها را
به حافظه
مقید
می‌کند.
تنها زمانی
استفاده
می‌شود که
افزونه task/affinity
فعال بوده و
توابع
حافظه NUMA در
دسترس
باشند.
توجه
داشته
باشید که
دقت و
تفکیک‌پذیری
مقیدسازی CPU
و حافظه
ممکن است در
برخی
معماری‌ها
متفاوت
باشد. برای
مثال،
مقیدسازی CPU
ممکن است در
سطح
هسته‌های
درون یک
پردازنده
انجام شود،
در حالی که
مقیدسازی
حافظه در
سطح گره‌ها
انجام
خواهد شد،
جایی که
تعریف
«گره‌ها»
ممکن است از
سیستمی به
سیستم دیگر
متفاوت
باشد.
به‌طور
پیش‌فرض
هیچ
مقیدسازی
حافظه‌ای
انجام
نمی‌شود؛
هر تسکی با
استفاده از
هر CPU
می‌تواند
از هر
حافظه‌ای
استفاده
کند. این
گزینه
معمولاً
برای
اطمینان از
این به کار
می‌رود که
هر تسک به
نزدیک‌ترین
حافظه به CPU
تخصیص‌یافته
به آن مقید
شود.
استفاده
از هر نوعی
غیر از "none"
یا "local"
توصیه
نمی‌شود.
اگر کنترل
بیشتری
می‌خواهید،
یک کد
آزمایشی
ساده را با
گزینه‌های
"--cpu-bind=verbose,none --mem-bind=verbose,none"
اجرا کنید
تا
پیکربندی
دقیق مشخص
شود.
نکته: برای اینکه Slurm همیشه مقیدسازی حافظه انتخاب‌شده را برای همه دستورات اجراشده در یک پوسته گزارش کند، می‌توانید حالت پرگو را با تنظیم مقدار متغیر محیطی SLURM_MEM_BIND روی "verbose" فعال کنید.
متغیرهای محیطی اطلاعاتی زیر هنگام استفاده از --mem-bind تنظیم می‌شوند:
-
SLURM_MEM_BIND_LIST SLURM_MEM_BIND_PREFER SLURM_MEM_BIND_TYPE SLURM_MEM_BIND_VERBOSE
برای توضیحات دقیق‌تر درباره هر یک از متغیرهای individual SLURM_MEM_BIND*، بخش متغیرهای محیطی (ENVIRONMENT VARIABLES) را ببینید.
گزینه‌های پشتیبانی‌شده عبارتند از:
- help
- نمایش این پیام راهنما
- local
- استفاده از حافظه محلی برای پردازنده در حال استفاده
- map_mem:<list>
- مقیدسازی از طریق تعیین ماسک‌های حافظه روی تسک‌ها (یا رتبه‌ها) به گونه‌ای که <list> به صورت <numa_id_for_task_0>,<numa_id_for_task_1>,... مشخص شده است. نگاشت برای یک گره تعیین می‌شود و نگاشت یکسانی روی تسک‌های هر گره اعمال خواهد شد (یعنی کمترین شناسه تسک روی هر گره به نخستین شناسه تعیین‌شده در فهرست نگاشت می‌شود و غیره). شناسه‌های NUMA به صورت مقادیر ده‌دهی تفسیر می‌شوند، مگر اینکه قبل از آنها '0x' آمده باشد که در این صورت مقادیر هگزادسیمال در نظر گرفته می‌شوند. اگر تعداد تسک‌ها (یا رتبه‌ها) از تعداد عناصر موجود در این فهرست بیشتر باشد، عناصر فهرست در صورت نیاز با شروع مجدد از ابتدای فهرست بازیافت می‌شوند. برای تسهیل پشتیبانی از تعداد زیاد تسک‌ها، فهرست‌ها می‌توانند پس از یک نگاشت حاوی ستاره و تعداد تکرار باشند. به عنوان مثال "map_mem:0x0f*4,0xf0*4". برای دستیابی به نتایج مقیدسازی قابل پیش‌بینی، تمام CPUهای هر گرهِ درگیر در کار باید به کار تخصیص داده شوند.
- mask_mem:<list>
- مقیدسازی از طریق تنظیم ماسک‌های حافظه روی تسک‌ها (یا رتبه‌ها) به گونه‌ای که <list> به صورت <numa_mask_for_task_0>,<numa_mask_for_task_1>,... مشخص شده است. نگاشت برای یک گره تعیین می‌شود و نگاشت یکسانی روی تسک‌های هر گره اعمال خواهد شد (یعنی کمترین شناسه تسک روی هر گره به نخستین ماسک تعیین‌شده در فهرست نگاشت می‌شود و غیره). ماسک‌های NUMA همیشه به صورت مقادیر هگزادسیمال تفسیر می‌شوند. توجه داشته باشید که اگر ماسک‌ها با [0-9] آغاز نشوند، باید قبل از آنها یک '0x' قرار گیرد تا به عنوان مقادیر عددی شناخته شوند. اگر تعداد تسک‌ها (یا رتبه‌ها) از تعداد عناصر موجود در این فهرست بیشتر باشد، عناصر فهرست در صورت نیاز با شروع مجدد از ابتدای فهرست بازیافت می‌شوند. برای تسهیل پشتیبانی از تعداد زیاد تسک‌ها، فهرست‌ها می‌توانند پس از یک ماسک حاوی ستاره و تعداد تکرار باشند. به عنوان مثال "mask_mem:0*4,1*4". برای دستیابی به نتایج مقیدسازی قابل پیش‌بینی، تمام CPUهای هر گرهِ درگیر در کار باید به کار تخصیص داده شوند.
- no[ne]
- تسک‌ها به حافظه مقید نشوند (پیش‌فرض)
- p[refer]
- استفاده از نخستین گره NUMA مشخص‌شده ترجیح داده شود، اما استفاده از سایر گره‌های NUMA در دسترس نیز مجاز باشد.
- q[uiet]
- مقیدسازی در حالت خاموش و بی‌صدا پیش از اجرای تسک انجام شود (پیش‌فرض)
- rank
- مقیدسازی بر اساس رتبه تسک (توصیه نمی‌شود)
- v[erbose]
- گزارش پرگو و با جزئیات مقیدسازی پیش از اجرای تسک
- این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --mem-per-cpu=<size>[units]
- حداقل
حافظه مورد
نیاز به
ازای هر CPU
تخصیص‌یافته
قابل
استفاده.
واحد
پیش‌فرض
مبی‌بایت
است.
واحدهای
مختلف را
می‌توان با
استفاده از
پسوند [K|M|G|T]
تعیین کرد.
مقدار
پیش‌فرض
DefMemPerCPU و
حداکثر
مقدار MaxMemPerCPU
است
(استثنای
زیر را
ببینید). در
صورت
پیکربندی،
هر دو
پارامتر با
استفاده از
دستور scontrol show config
قابل
مشاهده
هستند. توجه
داشته
باشید که
اگر مقدار
--mem-per-cpu کار از
مقدار
پیکربندی‌شده
MaxMemPerCPU فراتر
رود،
محدودیت
کاربر به
عنوان یک
محدودیت
حافظه به
ازای هر تسک
تلقی خواهد
شد؛ --mem-per-cpu به
مقداری که
بزرگ‌تر از
MaxMemPerCPU نباشد
کاهش
می‌یابد؛
--cpus-per-task تنظیم
شده و
حاصل‌ضرب
مقدار --cpus-per-task
در مقدار
جدید --mem-per-cpu
برابر با
مقدار اصلی
--mem-per-cpu
مشخص‌شده
توسط کاربر
خواهد بود.
این
پارامتر
معمولاً
زمانی
استفاده
می‌شود که
پردازنده‌ها
به صورت
مجزا به
کارها
تخصیص داده
شوند (SelectType=select/cons_tres).
اگر منابع
بر اساس
هسته، سوکت
یا کل
گره‌ها
تخصیص
یابند،
ممکن است
تعداد CPUهای
تخصیص‌یافته
به یک کار
بیشتر از
تعداد
تسک‌ها
باشد و
مقدار --mem-per-cpu
باید بر این
اساس تنظیم
شود. تعیین
محدودیت
حافظه
برابر با
صفر برای یک
گام کار،
گام کار را
به میزان
حافظه
تخصیص‌یافته
به کار
محدود
می‌کند،
اما هیچ
بخشی از
حافظه
تخصیص‌یافته
به کار را
از دسترس
سایر
گام‌های
کار خارج
نمی‌سازد.
همچنین --mem و
--mem-per-gpu را
ببینید.
گزینه‌های
--mem، --mem-per-cpu و --mem-per-gpu
مانعةالجمع
هستند.
نکته: اگر مقدار نهایی حافظه درخواست‌شده توسط یک کار توسط هیچ‌یک از گره‌های پیکربندی‌شده در پارتیشن برآورده نشود، کار رد خواهد شد. این حالت زمانی رخ می‌دهد که --mem-per-cpu به همراه گزینه --exclusive برای یک تخصیص کار استفاده شود و حاصل‌ضرب --mem-per-cpu در تعداد CPUهای روی یک گره، از کل حافظه آن گره بیشتر باشد.
نکته: این مورد برای CPUهای تخصیص‌یافته قابل استفاده در یک تخصیص کار اعمال می‌شود. این نکته زمانی که بیش از یک ریسه (thread) به ازای هر هسته پیکربندی شده باشد حائز اهمیت است. اگر کاری --threads-per-core را با تعداد ریسه‌های کمتری از ریسه‌های موجود در هسته درخواست کند (یا --hint=nomultithread که به معنای --threads-per-core=1 است)، کار قادر به استفاده از آن ریسه‌های اضافی روی هسته نخواهد بود و آن ریسه‌ها در محاسبه حافظه به ازای هر CPU لحاظ نمی‌شوند. اما اگر کار به تمام ریسه‌های روی هسته دسترسی داشته باشد، آن ریسه‌ها در محاسبه حافظه به ازای هر CPU لحاظ خواهند شد، حتی اگر کار صراحتاً آن ریسه‌ها را درخواست نکرده باشد.
در مثال‌های زیر، هر هسته دارای دو ریسه است.
در این مثال نخست، دو تسک می‌توانند روی هایپرترِدهای مجزا در همان هسته اجرا شوند زیرا از --threads-per-core استفاده نشده است. تسک سوم از هر دو ریسه هسته دوم استفاده می‌کند. حافظه تخصیص‌یافته به ازای هر CPU شامل تمام ریسه‌ها می‌شود:.nf $ salloc -n3 --mem-per-cpu=100 salloc: Granted job allocation 17199 $ sacct -j $SLURM_JOB_ID -X -o jobid%7,reqtres%35,alloctres%35
JobID ReqTRES AllocTRES ------- ----------------------------------- -----------------------------------
17199 billing=3,cpu=3,mem=300M,node=1 billing=4,cpu=4,mem=400M,node=1
در این مثال دوم، به دلیل استفاده از --threads-per-core=1، به هر تسک یک هسته کامل اختصاص داده می‌شود اما تنها قادر است از یک رشته در هر هسته استفاده کند. پردازنده‌های (CPUs) تخصیص‌یافته شامل تمام رشته‌های هر هسته می‌شوند. با این حال، حافظه تخصیص‌یافته به ازای هر پردازنده تنها شامل رشته قابل استفاده در هر هسته است.
$ salloc -n3 --mem-per-cpu=100 --threads-per-core=1 salloc: Granted job allocation 17200 $ sacct -j $SLURM_JOB_ID -X -o jobid%7,reqtres%35,alloctres%35 JobID ReqTRES AllocTRES ------- ----------------------------------- ----------------------------------- 17200 billing=3,cpu=3,mem=300M,node=1 billing=6,cpu=6,mem=300M,node=1
- --mem-per-gpu=<size>[units]
- حداقل حافظه مورد نیاز به ازای هر GPU تخصیص‌یافته. واحد پیش‌فرض مبی‌بایت است. واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد. مقدار پیش‌فرض DefMemPerGPU است و هم در سطح سراسری و هم بر اساس هر پارتیشن در دسترس است. در صورت پیکربندی، این پارامترها با استفاده از دستورهای scontrol show config و scontrol show partition قابل مشاهده هستند. همچنین --mem را ببینید. گزینه‌های --mem، --mem-per-cpu و --mem-per-gpu مانعةالجمع هستند.
- --mem-update=<margin>@<delay>
- کاهش خودکار محدودیت حافظه کار پس از آنکه به مدت‌زمان مشخص‌شده توسط delay اجرا شد. حد جدید برابر با مصرف فعلی حافظه کار به علاوه margin درصد تنظیم می‌شود. مقدار margin یک درصد است (مثلاً ۲۰ به معنی ۲۰٪ بالاتر از مصرف فعلی است). پارامتر delay مشخص می‌کند چه مدت پس از شروع کار، نمونه‌برداری از مصرف حافظه انجام و کاهش اعمال شود. قالب‌های زمانی قابل قبول برای delay شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند. محدودیت حافظه فقط می‌تواند کاهش یابد، و هرگز افزایش نمی‌یابد. اگر حد جدید محاسبه‌شده کمتر از حد فعلی نباشد، تغییری ایجاد نمی‌شود. حداقل کف ۱۰٪ از درخواست اولیه حافظه اعمال می‌شود تا از کاهش محدودیت به یک مقدار غیرمنطقی و بیش از حد کوچک جلوگیری شود. مصرف حافظه تنها به صورت RSS (حافظه فیزیکی مقیم) اندازه‌گیری می‌شود؛ مصرف swap محاسبه نمی‌شود. هنگامی که ConstrainSwapSpace پیکربندی شده باشد، محدودیت swap نیز به طور متناسب با محدودیت حافظه کاهش می‌یابد. این گزینه هم برای کارهای دارای --mem و هم کارهای دارای --mem-per-cpu عمل می‌کند. برای کارهای دارای --mem-per-cpu، حد جدید به عنوان یک مقدار به ازای هر گره اعمال می‌شود که در مقایسه با بیشترین تخصیص به ازای هر گره در بین تمام گره‌ها سنجیده می‌شود. این یک عملیات یک‌باره است: کاهش حداکثر یک بار در هر اجرای کار اعمال می‌شود. در صورت بازگشت کار به صف (requeue)، کاهش خودکار ممکن است دوباره فعال شود. این گزینه برای تخصیص‌های کار اعمال می‌شود. این گزینه نیازمند پیکربندی SlurmctldParameters=enable_stepmgr و JobAcctGatherType=jobacct_gather/cgroup است.
- --mincpus=<n>
- تعداد حداقل پردازنده‌ها/پردازشگرهای منطقی به ازای هر گره را مشخص می‌کند. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --mpi=<mpi_type>
- نوع MPI مورد استفاده را مشخص می‌کند. ممکن است به رویه‌های راه‌اندازی منحصربه‌فردی منجر شود.
- cray_shasta
- برای فعال‌سازی پشتیبانی از Cray PMI. این گزینه برای برنامه‌های ساخته‌شده با Cray Programming Environment است. درگاه کنترل PMI را می‌توان با گزینه --resv-ports یا با پارامتر MpiParams=ports=<port range> در فایل slurm.conf مشخص کرد. این افزونه از کارهای ناهمگن پشتیبانی نمی‌کند. پشتیبانی از cray_shasta به طور پیش‌فرض گنجانده شده است.
- list
- نوع‌های MPI موجود را برای انتخاب فهرست می‌کند.
- pmi2
- برای فعال‌سازی پشتیبانی از PMI2. پشتیبانی PMI2 در Slurm تنها در صورتی کار می‌کند که پیاده‌سازی MPI از آن پشتیبانی کند، به عبارت دیگر اگر MPI رابط PMI2 را پیاده‌سازی کرده باشد. گزینه --mpi=pmi2 کتابخانه lib/slurm/mpi_pmi2.so را بارگذاری می‌کند که قابلیت سمت سرور را ارائه می‌دهد اما سمت کلاینت باید PMI2_Init() و سایر فراخوانی‌های رابط را پیاده‌سازی کرده باشد.
- pmix
- برای
فعال‌سازی
پشتیبانی
از PMIx (https://pmix.github.io).
پشتیبانی PMIx
در Slurm
می‌تواند
برای
راه‌اندازی
برنامه‌های
موازی
(مانند MPI) در
صورت
پشتیبانی
از PMIx، PMI2 یا PMI1
استفاده
شود. Slurm باید
با ارسال
گزینه "--with-pmix=<PMIx
installation path>"; به
اسکریپت
"./configure" با
پشتیبانی
از pmix
پیکربندی
شده باشد.
در زمان نگارش این متن، PMIx در Open MPI از نسخه 2.0 به بعد پشتیبانی می‌شود. PMIx همچنین از سازگاری رو به عقب با PMI1 و PMI2 پشتیبانی می‌کند و در صورتی که MPI با پشتیبانی از PMI2/PMI1 اشاره‌کننده به کتابخانه PMIx ("libpmix") پیکربندی شده باشد، می‌تواند مورد استفاده قرار گیرد. اگر MPI از PMI1/PMI2 پشتیبانی کند اما راهکاری برای اشاره به یک پیاده‌سازی خاص ارائه ندهد، می‌توان از یک راهکار ترفندآمیز با بهره‌گیری از LD_PRELOAD برای اجبار به استفاده از "libpmix" استفاده کرد.
- none
- بدون پردازش خاص MPI. این حالت پیش‌فرض است و با بسیاری از نسخه‌های دیگر MPI کار می‌کند.
- این گزینه برای تخصیص‌های گام اعمال می‌شود.
- --msg-timeout=<seconds>
- تغییر مهلت زمانی پیام راه‌اندازی کار. مقدار پیش‌فرض MessageTimeout در فایل پیکربندی Slurm یعنی slurm.conf است. تغییر این مقدار معمولاً توصیه نمی‌شود، اما می‌تواند برای تشخیص و عیب‌یابی مشکلات مفید باشد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --multi-prog
- اجرای یک کار با برنامه‌های مختلف و آرگومان‌های متفاوت برای هر تسک. در این حالت، برنامه اجرایی مشخص‌شده در واقع یک فایل پیکربندی است که برنامه اجرایی و آرگومان‌ها را برای هر تسک تعیین می‌کند. برای جزئیات محتوای فایل پیکربندی، بخش MULTIPLE PROGRAM CONFIGURATION را در زیر ببینید. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- --network=<type>
- مشخص کردن
اطلاعات
مربوط به
سوئیچ یا
شبکه. تفسیر
type وابسته
به سیستم
است.
گزینه network در سیستم‌های دارای شبکه‌های HPE Slingshot در دسترس است. می‌توان از آن برای درخواست یک VNI کار (جهت استفاده در ارتباط بین گام‌های کار در یک کار) استفاده کرد. همچنین می‌تواند برای بازنویسی منابع پیش‌فرض شبکه تخصیص‌یافته به گام کار به کار رود. مقادیر متعدد را می‌توان در یک فهرست جداشده با کاما مشخص کرد.
- tcs=<class1>[:<class2>]...
- مجموعه‌ای از کلاس‌های ترافیکی برای پیکربندی برنامه‌ها. کلاس‌های ترافیکی پشتیبانی‌شده عبارتند از DEDICATED_ACCESS، LOW_LATENCY، BULK_DATA و BEST_EFFORT. همچنین کلاس‌های ترافیکی می‌توانند به صورت TC_DEDICATED_ACCESS، TC_LOW_LATENCY، TC_BULK_DATA و TC_BEST_EFFORT مشخص شوند. این گزینه برای تخصیص کار اعمال می‌شود، اما برای تخصیص‌های گام خیر.
- no_vni
- هیچ VNIای برای این کار تخصیص داده نشود (حتی در صورت چندگره‌ای بودن).
- job_vni
- تخصیص یک VNI کار برای این کار..IP
- single_node_vni
- تخصیص یک VNI کار برای این کار، حتی اگر کاری تک‌گره‌ای باشد.
- adjust_limits
- در صورت تنظیم، slurmd با در نظر گرفتن حداکثر مقدار منبع به ازای هر کارت شبکه (NIC) و کسر مقادیر رزروشده یا استفاده‌شده (هر کدام بیشتر باشد) برای هر سرویس شبکهٔ سیستمی، کران بالایی برای رزرو منابع شبکه تعیین می‌کند؛ این حالت پیش‌فرض است.
- no_adjust_limits
- در صورت تنظیم، slurmd رزروهای منابع شبکه را صرفاً بر اساس پیش‌فرض پیکربندی هر منبع و تعداد وظایف (taskها) در برنامه محاسبه می‌کند؛ و کران بالایی برای آن درخواست‌های رزرو بر اساس مصرف منابع توسط سرویس‌های شبکهٔ سیستمیِ از پیش موجود تعیین نخواهد کرد. تنظیم این گزینه به این معنی است که اجرای برنامه‌های بیشتری ممکن است به دلیل اتمام منابع شبکه با شکست مواجه شود، اما اگر برنامه برای عملکرد خود قطعاً به مقدار مشخصی از منابع نیاز داشته باشد، این گزینه آن را تضمین خواهد کرد.
- disable_rdzv_get
- غیرفعال‌سازی rendezvous getها در NICهای Slingshot، که می‌تواند کارایی را برای برخی برنامه‌های خاص بهبود بخشد.
- nic_distribution_count=<val>
- تعداد NICهایی که کاربر وظایف خود را به‌طور یکنواخت روی آنها توزیع می‌کند. پیش‌فرض تعداد NICها در هر گره است.
- def_<rsrc>=<val>
- تخصیص رزروشدهٔ به ازای هر پردازنده برای این منبع.
- res_<rsrc>=<val>
- تخصیص رزروشدهٔ به ازای هر گره برای این منبع. در صورت تنظیم، تخصیص به ازای هر پردازنده را لغو و بازنویسی می‌کند.
- max_<rsrc>=<val>
- حداکثر محدودیت به ازای هر گره برای این منبع.
- depth=<depth>
- ضریب برای تخصیص منبع به ازای هر پردازنده. پیش‌فرض تعداد پردازنده‌های رزروشده در گره است.
-
منابعی که ممکن است درخواست شوند عبارتند از:
- txqs
- صف‌های فرمان ارسال (Transmit). پیش‌فرض ۲ به ازای هر پردازنده، حداکثر ۱۰۲۴ به ازای هر گره است.
- tgqs
- صف‌های فرمان هدف (Target). پیش‌فرض ۱ به ازای هر پردازنده، حداکثر ۵۱۲ به ازای هر گره است.
- eqs
- صف‌های رویداد (Event). پیش‌فرض ۲ به ازای هر پردازنده، حداکثر ۲۰۴۷ به ازای هر گره است.
- cts
- شمارنده‌ها. پیش‌فرض ۱ به ازای هر پردازنده، حداکثر ۲۰۴۷ به ازای هر گره است.
- tles
- مدخل‌های فهرست محرک (Trigger list entries). پیش‌فرض ۱ به ازای هر پردازنده، حداکثر ۲۰۴۸ به ازای هر گره است.
- ptes
- مدخل‌های جدول پرتابل (Portable table entries). پیش‌فرض ۶ به ازای هر پردازنده، حداکثر ۲۰۴۸ به ازای هر گره است.
- les
- مدخل‌های فهرست (List entries). پیش‌فرض ۱۶ به ازای هر پردازنده، حداکثر ۱۶۳۸۴ به ازای هر گره است.
- acs
- زمینه‌های آدرس‌دهی (Addressing contexts). پیش‌فرض ۲ به ازای هر پردازنده، حداکثر ۱۰۲۲ به ازای هر گره است.
-
در سامانه‌های پیکربندی‌شده با SwitchType=switch/nvidia_imex، گزینه‌های زیر پشتیبانی می‌شوند:
- unique-channel-per-segment
- به جای یک کانال برای کل کار، یک کانال به ازای هر بخش (segment) در کار تخصیص می‌دهد. این گزینه فقط زمانی اعمال می‌شود که topology/block پیکربندی شده باشد.
-
این گزینه برای تخصیص‌های کار و گام (job and step allocations) اعمال می‌شود.
- --nice[=adjustment]
- اجرای کار با اولویت زمان‌بندی تعدیل‌شده در Slurm. بدون مقدار تعدیل، اولویت زمان‌بندی به میزان ۱۰۰ واحد کاهش می‌یابد. یک مقدار nice منفی اولویت را افزایش می‌دهد، در غیر این صورت آن را کاهش می‌دهد. محدودهٔ تعدیل +/- 2147483645 است. فقط کاربران دارای امتیاز می‌توانند یک تعدیل منفی مشخص کنند.
- -Z, --no-allocate
- اجرای وظایف مشخص‌شده روی مجموعه‌ای از گره‌ها بدون ایجاد یک «کار» اسلورم در ساختار صف Slurm، که گام عادی تخصیص منابع را دور می‌زند. فهرست گره‌ها باید با گزینهٔ -w, --nodelist مشخص شود. این یک گزینهٔ ممتاز است که تنها برای کاربران "SlurmUser" و "root" در دسترس است. این گزینه برای تخصیص‌های کار اعمال می‌شود. اگر فضای نام‌های کاربری (user namespaces) فعال باشند، نگاشت کاربران در فضای نام باید با همان فضای نام MUNGE مطابقت داشته باشد. در غیر این صورت، کار توسط slurmd رد خواهد شد.
- -k, --no-kill[=off]
- در صورت از
کار افتادن
یکی از
گره‌های
تخصیص‌یافته
به کار، آن
را به‌طور
خودکار
خاتمه نده.
این گزینه
برای
تخصیص‌های
کار و گام
اعمال
می‌شود. کار
تمام
مسئولیت‌های
مربوط به
تحمل‌پذیری
خطا (fault-tolerance) را
بر عهده
خواهد گرفت.
وظایفی که
با استفاده
از این
گزینه
راه‌اندازی
شده‌اند،
خاتمه‌یافته
تلقی
نخواهند شد
(برای مثال
گزینه‌های
-K, --kill-on-bad-exit و -W, --wait
تأثیری بر
گام کار
نخواهند
داشت). گام
فعال کار
(کار MPI)
احتمالاً
دچار خطای
مهلکی
خواهد شد،
اما اگر این
گزینه مشخص
شده باشد،
ممکن است
گام‌های
بعدی کار
اجرا شوند.
برای غیرفعال کردن اثر متغیر محیطی SLURM_NO_KILL، آرگومان اختیاری "off" را مشخص کنید.
اقدام پیش‌فرض، خاتمه دادن به کار در صورت خرابی گره است.
- -F, --nodefile=<node_file>
- بسیار شبیه به --nodelist است، با این تفاوت که فهرست درون فایلی به نام node file قرار دارد. نام گره‌های موجود در فهرست همچنین می‌توانند در چندین خط در فایل گسترش یابند. نام‌های تکراری گره در فایل نادیده گرفته خواهند شد. ترتیب نام گره‌ها در فهرست مهم نیست؛ نام گره‌ها توسط Slurm مرتب‌سازی خواهد شد.
- -w, --nodelist={<node_name_list>|<filename>}
- درخواست
فهرستی
مشخص از
گره‌ها. کار
بر اساس
نیازمندی‌های
منابع، تا
جای ممکن
شامل این
گره‌ها
خواهد بود و
در صورت
نیاز، اجرا
را برای در
دسترس قرار
گرفتن
منابع به
تعویق
می‌اندازد.
اگر حداقل تعداد گره یا پردازنده‌ای بیشتر از آنچه که فهرست گره‌های ارائه‌شده بتواند برآورده کند مشخص کنید، در صورت نیاز منابع اضافی در گره‌های دیگر تخصیص داده خواهد شد (مگر اینکه از --segment نیز استفاده شده باشد). برعکس، تعداد کمتر گره یا پردازنده ممکن است تنها به زیرمجموعه‌ای از فهرست گره‌های ارائه‌شده نیاز داشته باشد.
فهرست می‌تواند به صورت فهرستی از گره‌ها که با کاما از هم جدا شده‌اند، دامنه‌ای از گره‌ها (مانند node[1-5,7,...])، یا یک نام فایل مشخص شود. اگر فهرست گره‌ها حاوی نویسهٔ "/" باشد، یک نام فایل در نظر گرفته خواهد شد. ترتیب نام گره‌ها در فهرست اهمیتی ندارد؛ نام گره‌ها توسط Slurm مرتب خواهد شد.
نام‌های تکراری گره ممکن است هنگام استفاده از --distribution=arbitrary مفید باشد. می‌توان یک علامت ستاره و تعداد تکرار را به نام گره پیوست کرد. برای مثال، "node1,node1" و "node1*2" معادل هستند. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود..IP
- -N, --nodes=<minnodes>[-maxnodes]|<size_string>
- درخواست
تخصیص
حداقل minnodes
گره به این
کار. همچنین
می‌توان با
maxnodes حداکثر
تعداد گره
را مشخص
کرد. اگر
فقط یک عدد
مشخص شود،
هم به عنوان
حداقل و هم
به عنوان
حداکثر
تعداد گره
استفاده
می‌شود.
تعداد
گره‌ها را
می‌توان به
عنوان size_string
نیز مشخص
کرد. مشخصه
size_string تعیین
می‌کند که
چه مقادیری
برای
گره‌ها
باید
استفاده
شوند.
مقادیر
چندگانه را
می‌توان با
استفاده از
یک فهرست
جدا شده با
کاما، یا با
یک تابع گام
(step function) به همراه
پسوندی
شامل
دونقطه و
مقادیر
عددی با
جداکننده
«-» مشخص
کرد. برای
مثال، «--nodes=1-15:4»
معادل «--nodes=1,5,9,13»
است.
محدودیت‌های
گره در
پارتیشن،
بر
محدودیت‌های
کار اولویت
دارند. اگر
محدودیت‌های
گره یک کار
خارج از
بازه مجاز
برای
پارتیشن
مرتبط با آن
باشد، کار
در وضعیت PENDING
باقی خواهد
ماند. این
امر امکان
اجرای کار
را در زمان
دیگری که
محدودیت
پارتیشن
تغییر کند،
فراهم
می‌سازد.
اگر
محدودیت
گره کار از
تعداد
گره‌های
پیکربندی‌شده
در پارتیشن
فراتر رود،
کار رد
خواهد شد.
توجه داشته
باشید که
متغیر
محیطی SLURM_JOB_NUM_NODES
(و برای
سازگاری با
نسخه‌های
پیشین SLURM_NNODES)
به تعداد
گره‌های
اختصاص‌یافته
واقعی به
کار تنظیم
خواهد شد.
برای
اطلاعات
بیشتر بخش
ENVIRONMENT VARIABLES را
ببینید. اگر
-N مشخص
نشود،
رفتار
پیش‌فرض
این است که
گره‌های
کافی برای
برآورده
کردن منابع
درخواستی
که توسط
گزینه‌های
مشخصه کار
بیان
شده‌اند،
مانند -n، -c
و --gpus، تخصیص
یابد. به
کار تا حد
امکان در
بازه
مشخص‌شده و
بدون به
تأخیر
انداختن
شروع کار،
گره اختصاص
داده خواهد
شد. اگر
تعداد
تسک‌ها و
همچنین
تعداد
گره‌های
درخواستی
داده شده
باشد، در
صورتی که
تعداد
گره‌ها در
درخواست
بیشتر از
تعداد
تسک‌ها
باشد،
تعداد
گره‌های
استفاده‌شده
از آن
درخواست
کاهش یافته
تا با تعداد
تسک‌ها
مطابقت
پیدا کند.
مشخصه
تعداد گره
می‌تواند
شامل یک
مقدار عددی
و به دنبال
آن پسوند
«k» (ضرب
مقدار عددی
در ۱٬۰۲۴)
یا «m» (ضرب
مقدار عددی
در
۱٬۰۴۸٬۵۷۶)
باشد. این
گزینه برای
تخصیص‌های
کار و گام (step)
اعمال
می‌شود.
NOTE: این گزینه نمی‌تواند همراه با توزیع دلخواه (arbitrary distribution) استفاده شود.
- -n, --ntasks=<number>
- تعداد تسک‌ها برای اجرا را مشخص می‌کند. از srun درخواست می‌کند تا منابع را برای ntasks تسک تخصیص دهد. پیش‌فرض یک تسک به ازای هر گره است، اما توجه داشته باشید که گزینه --cpus-per-task این پیش‌فرض را تغییر خواهد داد. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --ntasks-per-core=<ntasks>
- درخواست
می‌کند
حداکثر ntasks
تسک روی هر
هسته
فراخوانی
شود. این
گزینه برای
تخصیص‌های
کار و گام
اعمال
می‌شود.
برای
استفاده به
همراه
گزینه --ntasks در
نظر گرفته
شده است.
مشابه --ntasks-per-node
است، با این
تفاوت که به
جای سطح
گره، در سطح
هسته اعمال
می‌شود. اگر
روی ۱ تنظیم
شود، به
معنای --cpu-bind=cores
خواهد بود.
در غیر این
صورت، اگر
روی مقداری
بزرگ‌تر از
۱ تنظیم
شود، به
معنای --cpu-bind=threads
خواهد بود.
با مشخص
کردن گزینه
--cpu-bind=none
می‌توان از
رفتار
پیوند
خودکار (automatic binding)
جلوگیری
کرد. ممکن
است Slurm برای
رعایت این
گزینه،
پردازنده‌های
بیشتری
نسبت به
آنچه
درخواست
شده است
تخصیص دهد.
NOTE: این گزینه هنگام استفاده از SelectType=select/linear پشتیبانی نمی‌شود. این مقدار نمی‌تواند بزرگ‌تر از --threads-per-core باشد.
- --ntasks-per-gpu=<ntasks>
- درخواست می‌کند به ازای هر GPU تعداد ntasks تسک فراخوانی شود. این گزینه می‌تواند به دو روش کار کند: ۱) مشخص کردن --ntasks علاوه بر این گزینه، که در این حالت یک مشخصه GPU بدون نوع به صورت خودکار تعیین می‌شود تا --ntasks-per-gpu برآورده شود، یا ۲) مشخص کردن GPUهای مورد نظر (مثلاً از طریق --gpus یا --gres) بدون مشخص کردن --ntasks، که در این حالت تعداد کل تسک‌ها به طور خودکار تعیین خواهد شد. در صورت نیاز، تعداد پردازنده‌های مورد نیاز به طور خودکار افزایش می‌یابد تا تعداد تسک‌های محاسبه‌شده را پوشش دهد. این گزینه به طور ضمنی --tres-bind=gres/gpu:single:<ntasks> را تنظیم می‌کند، اما می‌توان آن را با یک مشخصه صریح --tres-bind=gres/gpu بازنویسی کرد. این گزینه با بازه گره (یعنی -N<minnodes-maxnodes>) سازگار نیست. این گزینه با --gpus-per-task، --gpus-per-socket یا --ntasks-per-node سازگار نیست. این گزینه پشتیبانی نمی‌شود مگر اینکه SelectType=cons_tres پیکربندی شده باشد (به صورت مستقیم یا غیرمستقیم در سیستم‌های Cray).
- --ntasks-per-node=<ntasks>
- درخواست می‌کند ntasks تسک روی هر گره فراخوانی شود. اگر همراه با گزینه --ntasks استفاده شود، گزینه --ntasks اولویت خواهد داشت و --ntasks-per-node به عنوان حداکثر تعداد تسک‌ها در هر گره در نظر گرفته خواهد شد. برای استفاده به همراه گزینه --nodes در نظر گرفته شده است. این گزینه با --cpus-per-task=ncpus مرتبط است، اما نیازی به آگاهی از تعداد واقعی پردازنده‌ها در هر گره ندارد. در برخی موارد، راحت‌تر است که درخواست شود حداکثر تعداد مشخصی تسک بر روی هر گره اجرا شوند. نمونه‌هایی از این موارد عبارتند از ارسال یک برنامه ترکیبی MPI/OpenMP که در آن فقط یک «تسک/رتبه» (task/rank) MPI باید به هر گره اختصاص یابد و در عین حال به بخش OpenMP اجازه داده شود از تمام ظرفیت موازی‌سازی موجود در گره استفاده کند، یا ارسال یک کار آماده‌سازی/پاکسازی/پایش (setup/cleanup/monitoring) تکی به هر گره از یک تخصیص از پیش موجود به عنوان یک گام در یک اسکریپت کار بزرگ‌تر. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --ntasks-per-socket=<ntasks>
- درخواست می‌کند حداکثر ntasks تسک روی هر سوکت فراخوانی شود. این گزینه برای تخصیص کار اعمال می‌شود، اما برای تخصیص‌های گام اعمال نمی‌شود. برای استفاده به همراه گزینه --ntasks در نظر گرفته شده است. مشابه --ntasks-per-node است، با این تفاوت که به جای سطح گره، در سطح سوکت اعمال می‌شود. ماسک‌ها به طور خودکار برای پیوند دادن تسک‌ها به سوکت‌های مشخص ایجاد می‌شوند، مگر اینکه --cpu-bind=none مشخص شده باشد. NOTE: این گزینه هنگام استفاده از SelectType=select/linear پشتیبانی نمی‌شود.
- --oom-kill-step[={0|1}]
- مشخص می‌کند که آیا در صورت شناسایی یک رخداد OOM در هر تسک از گام، کل گام متوقف (kill) شود یا خیر. این گزینه تنظیم «OOMKillStep» را در TaskPluginParam از slurm.conf و تنظیمات تخصیص بازنویسی می‌کند. وقتی تنظیم نشده باشد، از مقدار slurm.conf استفاده خواهد کرد. در صورت تنظیم، مقدار «0» متوقف کردن کل گام را غیرفعال کرده و مقدار «1» آن را فعال می‌کند. در صورتی که گزینه بدون مقدار مشخص شود، پیش‌فرض «1» (فعال) است.
- --open-mode={append|truncate}
- فایل‌های خروجی و خطا را با استفاده از حالت append یا truncate مطابق مقدار مشخص‌شده باز می‌کند. برای گام‌های کار ناهمگن (heterogeneous) مقدار پیش‌فرض «append» است. در غیر این صورت مقدار پیش‌فرض توسط پارامتر پیکربندی سیستم JobFileAppend مشخص می‌شود. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
-
بخش EXAMPLE را در زیر ببینید.
- -o, --output=<filename_pattern>
- مشخص کردن
«filename pattern» برای
تغییر مسیر
stdout. به طور
پیش‌فرض در
حالت
تعاملی، srun
خروجی stdout را
از تمام
تسک‌ها
جمع‌آوری
کرده و این
خروجی را از
طریق TCP/IP به
ترمینال
متصل
می‌فرستد.
با --output،
می‌توان stdout
را به یک
فایل، به یک
فایل به
ازای هر
تسک، یا به
/dev/null تغییر
مسیر داد.
برای
اَشکال
مختلف filename pattern
بخش IO Redirection را
در زیر
ببینید. اگر
فایل
مشخص‌شده
از قبل وجود
داشته
باشد،
بازنویسی
خواهد شد.
اگر --error نیز در خط فرمان مشخص نشده باشد، هر دو خروجی stdout و stderr به فایل مشخص‌شده با --output هدایت خواهند شد. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- -O, --overcommit
- تخصیص بیش
از ظرفیت
منابع (Overcommit resources).
این گزینه
برای
تخصیص‌های
کار و گام
اعمال
می‌شود.
هنگامی که برای یک تخصیص کار اعمال می‌شود (به استثنای کارهایی که درخواست دسترسی اختصاصی به گره‌ها را دارند)، منابع طوری تخصیص داده می‌شوند که گویی فقط یک تسک در هر گره درخواست شده است. این بدان معناست که تعداد پردازنده‌های درخواستی به ازای هر تسک (-c، --cpus-per-task) به ازای هر گره تخصیص می‌یابد، نه اینکه در تعداد تسک‌ها ضرب شود. گزینه‌هایی که برای تعیین تعداد تسک‌ها در هر گره، سوکت، هسته و غیره استفاده می‌شوند نادیده گرفته خواهند شد.
هنگامی که برای تخصیص‌های گام کار اعمال شود (دستور srun زمانی که در یک تخصیص کار موجود اجرا می‌شود)، این گزینه می‌تواند برای اجرای بیش از یک تسک در هر CPU استفاده شود. به طور معمول، srun بیش از یک فرایند به ازای هر CPU تخصیص نخواهد داد. با مشخص کردن --overcommit، شما صریحاً به بیش از یک فرایند در هر CPU اجازه اجرا می‌دهید. با این حال اجرای بیش از MAX_TASKS_PER_NODE تسک به ازای هر گره مجاز نیست. NOTE: مقدار MAX_TASKS_PER_NODE در فایل slurm.h تعریف شده است و یک متغیر نیست، بلکه در زمان ساخت Slurm تنظیم می‌شود. --overlap مشخص کردن --overlap به گام‌ها اجازه می‌دهد تمام منابع (پردازنده‌ها، حافظه و GRES) را با سایر گام‌ها به اشتراک بگذارند. گامی که از این گزینه استفاده می‌کند با تمام گام‌های دیگر همپوشانی خواهد داشت، حتی گام‌هایی که --overlap را مشخص نکرده‌اند.
به‌طور پیش‌فرض، گام‌ها منابع را با سایر گام‌های موازی به اشتراک نمی‌گذارند. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- -s, --oversubscribe
- تخصیص کار
می‌تواند
منابع را با
سایر
کارهای در
حال اجرا به
اشتراک
بیش‌ازحد
(over-subscribe) بگذارد.
منابعی که
به اشتراک
گذاشته
می‌شوند
بسته به
پیکربندی
می‌توانند
گره‌ها،
سوکت‌ها،
هسته‌ها
و/یا
رشته‌های
پردازشی (hyperthreads)
باشند.
رفتار
پیش‌فرض
اشتراک
بیش‌ازحد
به
پیکربندی
سیستم
بستگی دارد
و گزینهٔ
OverSubscribe
پارتیشن بر
گزینهٔ کار
ارجحیت
دارد. این
گزینه ممکن
است منجر به
اعطای
سریع‌تر
تخصیص نسبت
به زمانی
شود که
گزینهٔ --oversubscribe
تنظیم نشده
باشد و
اجازهٔ
بهره‌وری
بالاتری از
سیستم را
بدهد، اما
به دلیل
رقابت بر سر
منابع،
کارایی
برنامه
احتمالاً
دچار افت
خواهد شد.
این گزینه
برای
تخصیص‌های
کار اعمال
می‌شود.
NOTE: این گزینه با --exclusive ناسازگار و مانعةالجمع است.
- --parsable
- تنها شناسهٔ گام (<jobid>.<stepid>) را در یک سطر تکی در خروجی استاندارد (stdout) نمایش می‌دهد. متن ابتدایی "Submitted step " را حذف می‌کند. مشابه با sbatch --parsable است، اما شناسهٔ گام را در کنار شناسهٔ کار در بر دارد. خطاها همچنان طبق معمول در خروجی خطای استاندارد (stderr) چاپ می‌شوند. نیازمند --async است. توجه داشته باشید که --quiet شناسهٔ گام را به همراه سایر پیام‌های اطلاع‌رسانی حذف می‌کند.
- -p, --partition=<partition_names>
- درخواست یک پارتیشن خاص برای تخصیص منابع. در صورت مشخص نشدن، رفتار پیش‌فرض این است که به کنترلر Slurm اجازه داده شود تا پارتیشن پیش‌فرض تعیین‌شده توسط مدیر سیستم را انتخاب کند. اگر کار بتواند از بیش از یک پارتیشن استفاده کند، نام آنها را در فهرستی جداشده با کاما مشخص کنید؛ در این صورت پارتیشنی که زودترین زمان آغاز را ارائه دهد، بدون توجه به ترتیب نام پارتیشن‌ها (اگرچه پارتیشن‌های با اولویت بالاتر ابتدا در نظر گرفته می‌شوند) استفاده خواهد شد. هنگام آغاز کار، نام پارتیشن استفاده‌شده در ابتدای رشتهٔ پارتیشن رکورد کار قرار خواهد گرفت. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --prefer=<list>
- گره‌ها می‌توانند features (ویژگی‌هایی) داشته باشند که توسط مدیر Slurm به آنها اختصاص داده شده است. کاربران با استفاده از گزینهٔ prefer می‌توانند مشخص کنند که کدام‌یک از این features برای کارشان مطلوب است اما الزامی نیست. این گزینه مستقل از --constraint عمل کرده و در صورت امکان آنچه در آنجا تنظیم شده است را لغو و بازنویسی (override) می‌کند. هنگام زمان‌بندی، ویژگی‌های موجود در --prefer ابتدا بررسی می‌شوند. اگر مجموعه‌ای از گره‌ها با آن ویژگی‌ها در دسترس نباشد، سپس --constraint ارزیابی می‌شود. برای اطلاعات بیشتر --constraint را ببینید؛ این گزینه به همان صورت رفتار می‌کند.
- -E, --preserve-env
- مقادیر فعلی متغیرهای محیطی SLURM_JOB_NUM_NODES و SLURM_NTASKS را به‌جای محاسبه از روی پارامترهای خط فرمان، به executable منتقل می‌کند. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --priority=<value>
- درخواست یک اولویت مشخص برای کار. ممکن است مشمول محدودیت‌های خاص پیکربندی باشد. مقدار value باید یک مقدار عددی یا "TOP" (برای بالاترین مقدار ممکن) باشد. فقط اپراتورها و مدیران Slurm می‌توانند اولویت یک کار را تنظیم کنند. این گزینه تنها برای تخصیص‌های کار اعمال می‌شود.
- --profile={all|none|<type>[,<type>...]}
- جمع‌آوری دقیق داده‌ها را توسط پلاگین acct_gather_profile فعال می‌کند. داده‌های دقیق معمولاً سری‌های زمانی هستند که بسته به پلاگین پیکربندی‌شده، در یک فایل HDF5 برای کار یا یک پایگاه دادهٔ InfluxDB ذخیره می‌شوند. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- All
- تمام انواع داده جمع‌آوری می‌شوند. (نمی‌تواند با مقادیر دیگر ترکیب شود.)
- None
- هیچ نوع داده‌ای جمع‌آوری نمی‌شود. این حالت پیش‌فرض است. (نمی‌تواند با مقادیر دیگر ترکیب شود.)
مقادیر معتبر type عبارت‌اند از:
- Energy
- داده‌های مصرف انرژی (Energy) جمع‌آوری می‌شوند.
- Task
- داده‌های وظیفه (ورودی/خروجی، حافظه، ...) جمع‌آوری می‌شوند.
- Filesystem
- داده‌های فایل‌سیستم جمع‌آوری می‌شوند.
- Network
- داده‌های شبکه (InfiniBand) جمع‌آوری می‌شوند.
- --prolog=<executable>
- دستور srun دقیقاً پیش از راه‌اندازی گام کار، executable را اجرا خواهد کرد. آرگومان‌های خط فرمان برای executable همان دستور و آرگومان‌های گام کار خواهند بود. اگر مقدار executable برابر "none" باشد، هیچ پرولوگ srun اجرا نخواهد شد. این پارامتر مقدار پارامتر SrunProlog را در slurm.conf بازنویسی می‌کند. این پارامتر کاملاً مستقل از پارامتر Prolog در slurm.conf است. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --propagate[=rlimit[,rlimit...]]
- به کاربران اجازه می‌دهد مشخص کنند کدام‌یک از محدودیت‌های منابعِ قابل‌تغییر (soft) به گره‌های محاسباتی منتشر شده و بر کارهایشان اعمال شود. اگر هیچ rlimit مشخص نشود، تمام محدودیت‌های منابع منتشر خواهند شد. نام‌های rlimit زیر توسط Slurm پشتیبانی می‌شوند (اگرچه برخی گزینه‌ها ممکن است در برخی سیستم‌ها پشتیبانی نشوند):
- ALL
- تمام محدودیت‌های فهرست‌شده در زیر (پیش‌فرض)
- NONE
- هیچ‌یک از محدودیت‌های فهرست‌شده در زیر
- AS
- حداکثر فضای آدرس‌دهی (حافظهٔ مجازی) برای یک فرایند.
- CORE
- حداکثر اندازهٔ فایل core
- CPU
- حداکثر میزان زمان CPU
- DATA
- حداکثر اندازهٔ سگمنت دادهٔ یک فرایند
- FSIZE
- حداکثر اندازهٔ فایل‌های ایجادشده. توجه داشته باشید که اگر کاربر FSIZE را کمتر از اندازهٔ فعلی slurmd.log تنظیم کند، راه‌اندازی کار با خطای 'File size limit exceeded' شکست خواهد خورد.
- MEMLOCK
- حداکثر مقداری که می‌تواند در حافظه قفل شود NOFILE حداکثر تعداد فایل‌های باز
- NPROC
- حداکثر تعداد فرایندهای موجود
- RSS
- حداکثر اندازه مجموعه مقیم (resident set size). توجه داشته باشید که این گزینه فقط در هسته‌های لینوکس 2.4.30 یا قدیمی‌تر و یا BSD تأثیر دارد.
- STACK
- حداکثر اندازه پشته
- این گزینه بر تخصیص‌های کار (job) اعمال می‌شود.
- --pty, --pty=<File Descriptor>
- اجرای تسک صفر با حالت شبه‌پایانه (pseudo terminal) یا با استفاده از شبه‌پایانه مشخص‌شده توسط <File Descriptor>. به‌طور ضمنی --unbuffered را تنظیم می‌کند. به‌طور ضمنی --error و --output را برای تمامی تسک‌ها به‌جز تسک صفر روی /dev/null قرار می‌دهد که ممکن است باعث خروج فوری آن تسک‌ها شود (برای نمونه، پوسته‌ها معمولاً در این وضعیت بلافاصله خارج می‌شوند). این گزینه بر تخصیص‌های گام (step) اعمال می‌شود.
- -q, --qos=<qos>
- درخواست یک کیفیت سرویس برای کار، یا فهرستی از QOS که با کاما از هم جدا شده‌اند. در صورت درخواست یک فهرست، ترتیب‌بندی بر اساس اولویت QOSهای ارائه‌شده خواهد بود که اولین مورد دارای بالاترین اولویت است. مقادیر QOS را می‌توان برای هر پیوند (association) کاربر/کلاستر/حساب کاربری در پایگاه‌داده Slurm تعریف کرد. هنگامی که پارامتر پیکربندی Slurm یعنی AccountingStorageEnforce در تعریف خود شامل "qos" باشد، کاربران به مجموعه qosهای تعریف‌شده برای پیوند خود محدود خواهند شد. این گزینه بر تخصیص‌های کار اعمال می‌شود.
- -Q, --quiet
- نادیده‌گرفتن پیام‌های اطلاعاتی از srun. خطاها همچنان نمایش داده خواهند شد. این گزینه بر تخصیص‌های کار و گام اعمال می‌شود.
- --quit-on-interrupt
- خروج فوری با یک سیگنال SIGINT (Ctrl-C) تکی. استفاده از این گزینه، ویژگی نمایش وضعیتی را که معمولاً هنگام دریافت یک Ctrl-C در srun در دسترس است غیرفعال کرده و باعث می‌شود srun در عوض کارِ در حال اجرا را فوراً پایان دهد. این گزینه بر تخصیص‌های گام اعمال می‌شود.
- --reboot
- راه‌اندازی مجدد (reboot) اجباری گره‌های تخصیص‌یافته پیش از آغاز کار. این قابلیت تنها در برخی از پیکربندی‌های سیستم پشتیبانی می‌شود و در غیر این صورت بدون اعلان نادیده گرفته خواهد شد. تنها کاربر root، SlurmUser یا مدیران سیستم می‌توانند گره‌ها را راه‌اندازی مجدد کنند. این گزینه بر تخصیص‌های کار اعمال می‌شود.
- -r, --relative=<n>
- اجرای یک گام کار به‌صورت نسبی نسبت به گره n از تخصیص فعلی. از این گزینه می‌توان برای توزیع چند گام کار در میان گره‌های کار جاری استفاده کرد. اگر -r استفاده شود، گام کار جاری از گره n فهرست گره‌های تخصیص‌یافته شروع می‌شود، که در آن نخستین گره برابر با گره 0 در نظر گرفته می‌شود. استفاده از گزینه -r همراه با گزینه‌های -w یا -x مجاز نیست و در صورت اجرا نشدن درون یک تخصیص قبلی (یعنی زمانی که SLURM_JOB_ID تنظیم نشده باشد) منجر به خطای مهلک خواهد شد. مقدار پیش‌فرض برای n برابر 0 است. اگر مقدار --nodes از تعداد گره‌های مشخص‌شده با گزینه --relative بیشتر باشد، یک پیام هشدار چاپ شده و گزینه --relative تقدم خواهد داشت. این گزینه بر تخصیص‌های گام اعمال می‌شود.
- --reservation=<reservation_names>
- تخصیص منابع برای کار از طریق رزرو نام‌برده‌شده. اگر کار بتواند از بیش از یک رزرو استفاده کند، نام آنها را در یک فهرست جداشده با کاما مشخص کنید تا موردی که زودترین زمان آغاز را فراهم می‌کند استفاده شود. هر رزرو به ترتیبی که درخواست شده است بررسی خواهد شد. تمام رزروها در طول دوره حیات کار در scontrol/squeue فهرست خواهند شد. در سیستم حسابداری (accounting)، ابتدا رزرو اول دیده می‌شود و پس از آغاز کار، رزروِ استفاده‌شده جایگزین آن خواهد شد.
- --resources=<resource_names>
- تعیین
منابع
سلسله‌مراتبی
که باید به
این کار
تخصیص داده
شوند. نام
منابع
می‌تواند
با یک
دونقطه و
تعداد
همراه باشد
(تعداد
پیش‌فرض یک
است). چندین
منبع در Mode 1 و Mode 2
را می‌توان
در یک فهرست
جداشده با
کاما
درخواست
کرد، اما
تنها یک
مورد از Mode 3
قابل
درخواست
است. برای
مثال،
"--resources=flat:2,natural:1".
برای اطلاعات بیشتر درباره استفاده از منابع سلسله‌مراتبی در Slurm به https://slurm.schedmd.com/hres.html مراجعه کنید.
- --resv-ports[=count]
- رزرو پورت‌های ارتباطی برای این کار. کاربران می‌توانند تعداد پورت‌هایی را که می‌خواهند رزرو کنند مشخص نمایند. پارامتر MpiParams=ports=12000-12999 باید در slurm.conf تعریف شده باشد. اگر تعداد پورت‌های رزروشده صفر باشد، هیچ پورتی رزرو نخواهد شد. فقط برای PMI بومی Cray استفاده می‌شود. این گزینه بر تخصیص‌های کار و گام اعمال می‌شود.
- --segment=<segment_size>
- هنگامی که
توپولوژی
بلوکی یا
حلقه‌ای (ring)
استفاده
می‌شود،
اندازه
قطعه‌هایی
(segments) را که
برای ایجاد
تخصیص کار
به کار
می‌روند
مشخص
می‌کند. هیچ
الزامی
مبنی بر
قرارگیری
تمام
قطعه‌های
یک کار در
همان بلوک
سطح بالاتر
اعمال
نخواهد شد.
NOTE: اگر تعداد گره‌های درخواستی (--nodes) بزرگ‌تر از اندازه قطعه درخواستی باشد، باید به‌طور دقیق بر اندازه قطعه بخش‌پذیر باشد. اگر تمام گره‌ها در یک قطعه جای گیرند، این گزینه هیچ اثری نخواهد داشت.
NOTE: در صورت استفاده هم‌زمان با --nodelist=<node_list>: تعداد گره‌های درخواستی باید کمتر یا مساوی با تعداد کل گره‌های یکتای مشخص‌شده در آرگومان --nodelist باشد. درخواست گره‌هایی بیشتر از گره‌های یکتای موجود در --nodelist ارائه‌شده منجر به رد شدن کار توسط slurmctld خواهد شد.
- --send-libs[=yes|no]
- در صورت تنظیم روی yes (یا بدون آرگومان)، وابستگی‌های اشیاء اشتراکی (shared object) فایل اجرایی را به‌طور خودکار تشخیص داده و به گره‌های محاسباتی تخصیص‌یافته ارسال (broadcast) می‌کند. فایل‌ها در یک دایرکتوری در کنار فایل اجرایی قرار می‌گیرند. متغیر محیطی LD_LIBRARY_PATH نیز به‌طور خودکار به‌روزرسانی می‌شود تا این دایرکتوری کش را نیز در بر بگیرد. این گزینه رفتار پیش‌فرضِ پیکربندی‌شده در SbcastParameters send_libs در فایل slurm.conf را لغو می‌کند. این گزینه فقط در ترکیب با --bcast عمل می‌کند. همچنین --bcast-exclude را ببینید.
- --signal=[R:]<sig_num>[@sig_time]
- هنگامی که کار در فاصله زمانی sig_time ثانیه تا زمان پایان خود قرار دارد، سیگنال sig_num را به آن ارسال می‌کند. با توجه به دقت زمانی پردازش رویدادها توسط Slurm، سیگنال ممکن است تا ۶۰ ثانیه زودتر از زمان مشخص‌شده ارسال شود. sig_num می‌تواند شماره یا نام سیگنال باشد (مانند "10" یا "USR1"). sig_time باید یک مقدار عدد صحیح بین 0 و 65535 باشد. به‌طور پیش‌فرض، پیش از زمان پایان کار هیچ سیگنالی ارسال نمی‌شود. اگر یک sig_num بدون هیچ sig_time مشخص شود، زمان پیش‌فرض ۶۰ ثانیه خواهد بود. این گزینه بر تخصیص‌های کار اعمال می‌شود. از گزینه "R:" استفاده کنید تا به این کار اجازه داده شود با رزروی که MaxStartDelay برای آن تنظیم شده همپوشانی داشته باشد. در صورت استفاده از گزینه "R:"، قابلیت قبضه‌کردن (preemption) باید در سیستم فعال باشد، و در صورتی که کار قبضه شود، چنانچه مجاز باشد دوباره به صف بازگردانده می‌شود (requeue) وگرنه کار لغو خواهد شد. برای ارسال سیگنال در زمان قبضه‌شدن، به send_user_signal در PreemptParameter مراجعه کنید.
- --slurmd-debug=<level>
- تعیین سطح اشکال‌زدایی (debug) برای این گام. level را می‌توان به‌صورت یک مقدار عددی صحیح بین 2 [error] و 6 [debug2] یا به‌عنوان یکی از برچسب‌های SlurmdDebug مشخص کرد.
- error
- فقط خطاها ثبت شوند info ثبت خطاها و پیام‌های اطلاعاتی عمومی
- verbose
- ثبت خطاها و پیام‌های اطلاعاتی پرجزئیات
- debug
- ثبت خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی
- debug2
- ثبت خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی بیشتر
-
اطلاعات اشکال‌زدایی slurmd بر روی stderr کار کپی می‌شود. به‌طور پیش‌فرض تنها خطاها نمایش داده می‌شوند. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --sockets-per-node=<sockets>
- محدود کردن
انتخاب گره
به
گره‌هایی
با حداقل
تعداد
سوکت‌های
مشخص‌شده.
هنگامی که
افزونه task/affinity
فعال است،
اطلاعات
تکمیلی زیر
گزینه -B در
بالا را
مشاهده
کنید. این
گزینه برای
تخصیص‌های
کار اعمال
می‌شود.
نکته: این گزینه ممکن است در صورت مشخص نشدن -n، به‌طور ضمنی بر تعداد وظایف تأثیر بگذارد.
- --spread-job
- توزیع تخصیص کار روی بیشترین تعداد ممکن از گره‌ها و تلاش برای توزیع یکنواخت وظایف در میان گره‌های تخصیص‌یافته. این گزینه افزونه topology/tree را غیرفعال می‌کند. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --spread-segments
- جلوگیری از
تخصیص
گره‌های
درون یک
بلوک پایه (base
block) یکسان به
قطعه‌های
(segments) مجزا
درون همان
بلوک.
این گزینه برای تخصیص‌های کار اعمال می‌شود. نکته: این گزینه تنها با افزونه topology/block کار خواهد کرد.
- --stepmgr
- فعال‌سازی مدیریت گام slurmstepd به ازای هر کار، در صورتی که در سطح کل سیستم فعال نشده باشد. این قابلیت امکان مدیریت گام‌های کار را توسط یک slurmstepd بیرونی (extern) منفرد مرتبط با کار فراهم می‌کند. این امر برای کارهایی که گام‌های متعددی را درون تخصیص‌های خود ارسال می‌کنند سودمند است. PrologFlags=contain باید تنظیم شده باشد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --switches=<count>[@max-time]
- هنگامی که از یک توپولوژی درختی (tree topology) استفاده می‌شود، این گزینه حداکثر تعداد سوییچ‌های برگ (leaf switches) مورد نظر برای تخصیص کار و به‌صورت اختیاری حداکثر زمان انتظار برای آن تعداد سوییچ را تعریف می‌کند. اگر Slurm تخصیصی حاوی سوییچ‌هایی بیش از تعداد مشخص‌شده پیدا کند، کار در وضعیت معلق (pending) باقی می‌ماند تا زمانی که یا تخصیصی با تعداد سوییچ مورد نظر پیدا شود یا مهلت زمانی به پایان برسد. اگر محدودیتی برای تعداد سوییچ وجود نداشته باشد، هیچ تاخیری در آغاز کار وجود نخواهد داشت. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند. حداکثر تاخیر زمانی کار ممکن است توسط مدیر سیستم با استفاده از پارامتر پیکربندی SchedulerParameters به همراه گزینه پارامتری max_switch_wait محدود شود. روی یک شبکه dragonfly تنها تعداد سوییچ پشتیبانی‌شده ۱ است، زیرا کارایی ارتباطی زمانی در بالاترین حد خواهد بود که منابع به یک کار روی یک سوییچ برگ یا بیش از ۲ سوییچ برگ تخصیص داده شوند. مقدار پیش‌فرض max-time برابر با مقدار max_switch_wait در SchedulerParameters است. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --task-epilog=<executable>
- دیمن slurmstepd بلافاصله پس از خاتمه هر وظیفه، فایل اجرایی executable را اجرا خواهد کرد. این برنامه پیش از اجرای هر پارامتر TaskEpilog در slurm.conf اجرا می‌شود. این برنامه باید بسیار کوتاه‌عمر باشد. اگر نتواند ظرف چند ثانیه خاتمه یابد، به همراه تمام فرآیندهای فرزند (descendant) خود کشته خواهد شد. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- --task-prolog=<executable>
- دیمن slurmstepd دقیقاً پیش از راه‌اندازی هر وظیفه، فایل اجرایی executable را اجرا خواهد کرد. این برنامه پس از اجرای هر پارامتر TaskProlog در slurm.conf اجرا خواهد شد. علاوه بر متغیرهای محیطی معمولی، متغیر SLURM_TASK_PID نیز برای شناسایی شناسه فرآیند وظیفه‌ای که در حال آغاز است در دسترس خواهد بود. خروجی استاندارد این برنامه به شکل "export NAME=value" برای تنظیم متغیرهای محیطی برای وظیفه‌ای که ایجاد می‌شود به کار خواهد رفت. این گزینه برای تخصیص‌های گام اعمال می‌شود.
- --test-only
- با در نظر گرفتن صف فعلی کارها و تمام آرگومان‌های دیگر srun که کار را مشخص می‌کنند، تخمینی از زمان زمان‌بندی اجرای کار را بازمی‌گرداند. این گزینه رفتار srun را تنها به بازگرداندن اطلاعات محدود می‌کند؛ هیچ کاری در واقع ارسال نمی‌شود. این گزینه برای تخصیص‌های کار اعمال می‌شود. این گزینه می‌تواند با --jobid ترکیب شود تا زمان تخمینی شروع یک کار در حال انتظار (pending) را به دست آورد.
- --thread-spec=<num>
- تعداد threadهای
تخصصی به
ازای هر گره
که توسط کار
برای
عملیات
سیستمی
رزرو شده و
توسط
برنامه
استفاده
نمی‌شوند.
برنامه
کاربردی از
این threadها
استفاده
نخواهد
کرد، اما
هزینه
تخصیص
آنها
محاسبه
خواهد شد.
این گزینه
نمی‌تواند
همراه با
گزینه --core-spec
استفاده
شود. این
گزینه برای
تخصیص‌های
کار اعمال
می‌شود.
نکته: تنظیم صریح مقدار thread تخصصی برای یک کار، به‌طور ضمنی گزینه --exclusive آن را فعال کرده و کل گره‌ها را برای کار رزرو می‌کند.
- -T, --threads=<nthreads>
- امکان محدود کردن تعداد threadهای هم‌روند مورد استفاده برای ارسال درخواست کار از فرآیند srun به فرآیندهای slurmd در گره‌های تخصیص‌یافته را فراهم می‌کند. پیش‌فرض، استفاده از یک thread به ازای هر گره تخصیص‌یافته تا حداکثر ۶۰ thread هم‌روند است. مشخص کردن این گزینه تعداد threadهای هم‌روند را به nthreads (کمتر یا مساوی ۶۰) محدود می‌کند. این گزینه تنها باید برای تنظیم تعداد thread پایین جهت آزمایش روی رایانه‌هایی با حافظه بسیار کم استفاده شود.
- --threads-per-core=<threads>
- محدود کردن
انتخاب گره
به
گره‌هایی
با حداقل
تعداد
مشخص‌شده thread
به ازای هر
هسته. در
چیدمان
وظایف، از
حداکثر
تعداد
مشخص‌شده thread
به ازای هر
هسته
استفاده
می‌شود. این
گزینه
متضمن --cpu-bind=threads
است مگر
اینکه توسط
گزینه‌های
خط فرمان یا
متغیرهای
محیطی لغو
شود. نکته:
واژه "Threads" به
تعداد
واحدهای
پردازشی
روی هر هسته
اشاره دارد
و نه تعداد
وظایف
برنامه‌ای
که قرار است
در هر هسته
اجرا شوند.
هنگامی که
افزونه task/affinity
فعال است،
اطلاعات
تکمیلی زیر
گزینه -B در
بالا را
مشاهده
کنید. این
گزینه برای
تخصیص‌های
کار و گام
اعمال
می‌شود.
نکته: این گزینه ممکن است در صورت مشخص نشدن -n، به‌طور ضمنی بر تعداد وظایف تأثیر بگذارد.
- -t, --time=<time>
- تنظیم
محدودیت
برای کل
زمان اجرای
تخصیص کار.
اگر
محدودیت
زمانی
درخواستی
از محدودیت
زمانی
افراز (partition)
فراتر رود،
کار در
وضعیت PENDING
باقی خواهد
ماند
(احتمالاً
برای
همیشه).
محدودیت
زمانی
پیش‌فرض،
همان
محدودیت
زمانی
پیش‌فرض
افراز است.
هنگامی که
محدودیت
زمانی به
پایان
برسد، به هر
وظیفه در هر
گام کار
ابتدا SIGTERM و
سپس SIGKILL ارسال
می‌شود.
فاصله
زمانی میان
سیگنال‌ها
با پارامتر
پیکربندی Slurm
یعنی KillWait
مشخص
می‌شود.
پارامتر
پیکربندی
OverTimeLimit ممکن
است به کار
اجازه دهد
طولانی‌تر
از زمان
زمان‌بندی‌شده
اجرا شود.
دقت زمان یک
دقیقه است و
مقادیر
ثانیه به
دقیقه بعدی
گرد
می‌شوند.
محدودیت زمانی صفر درخواست می‌کند که هیچ محدودیت زمانی اعمال نشود. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- --time-min=<time>
- تنظیم حداقل محدودیت زمانی برای تخصیص کار. در صورت مشخص شدن، اگر کاهش محدودیت --time به مقداری نه کمتر از --time-min باعث شود کار زودتر از حالت معمول آغاز به اجرا کند، ممکن است این محدودیت کاهش یابد. محدودیت زمانی کار پس از تخصیص منابع به آن تغییر نخواهد کرد. این عمل توسط یک الگوریتم زمان‌بندی backfill انجام می‌شود تا منابعی را تخصیص دهد که در غیر این صورت برای کارهای با اولویت بالاتر رزرو شده بودند. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند. این گزینه برای تخصیص‌های کار اعمال می‌شود..IP
- --tmp=<size>[units]
- حداقل مقدار فضای دیسک موقت برای هر گره را مشخص می‌کند. واحد پیش‌فرض مبی‌بایت (mebibytes) است. واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --treewidth=<size>
- عرض انشعاب (fanout) را مشخص می‌کند. مقدار پیش‌فرض همان TreeWidth مشخص‌شده در slurm.conf است. مقدار نمی‌تواند از ۶۵۵۳۳ تجاوز کند. مقدار «off» انشعاب را غیرفعال می‌کند.
- --tres-bind=<tres>:[verbose,]<type>[+<tres>:
- [verbose,]<type>...]
فهرستی از tres
را به همراه
گزینه‌های
اتصال به
وظیفه (task binding)
مشخص
می‌کند. در
حال حاضر gres
تنها tres
پشتیبانی‌شده
برای این
گزینه است. gres
را به‌صورت
«gres/<gres_name>» مشخص
کنید (مانند
gres/gpu).
مثال: --tres-bind=gres/gpu:verbose,map:0,1,2,3+gres/nic:closest
به‌طور پیش‌فرض، بیشتر tresها به وظایف تکی متصل نمی‌شوند.
گزینه‌های پشتیبانی‌شده type اتصال برای gres:
- closest
- هر وظیفه را به نزدیک‌ترین gres(ها) متصل می‌کند. در یک محیط NUMA، هر وظیفه ممکن است به بیش از یک gres متصل شود (یعنی تمام gresهای موجود در آن محیط NUMA).
- map:<list>
- با تنظیم ماسک‌های gres بر روی وظایف (یا rankها) طبق آنچه در <list> مشخص شده متصل می‌کند؛ جایی که <list> به‌صورت <gres_id_for_task_0>,<gres_id_for_task_1>,... است. شناسه‌های gres به‌صورت مقادیر ده‌دهی تفسیر می‌شوند. اگر تعداد وظایف (یا rankها) از تعداد عناصر موجود در این فهرست بیشتر شود، عناصر فهرست برحسب نیاز و با شروع از ابتدای فهرست دوباره استفاده خواهند شد. برای ساده‌سازی پشتیبانی از تعداد وظایف زیاد، فهرست‌ها می‌توانند پس از یک نگاشت حاوی ستاره و تعداد تکرار باشند؛ برای مثال «map:0*4,1*4». اگر پلاگین task/cgroup استفاده شود و ConstrainDevices در cgroup.conf تنظیم شده باشد، شناسه‌های gres نمایه‌های مبتنی بر صفر نسبت به gresهای تخصیص‌یافته به کار خواهند بود (مثلاً اولین gres برابر با ۰ است، حتی اگر شناسه سراسری آن ۳ باشد). در غیر این صورت، شناسه‌های gres همان شناسه‌های سراسری هستند و برای به‌دست آوردن نتایج اتصال قابل پیش‌بینی، تمام gresهای روی هر گره در کار باید تخصیص داده شوند.
- mask:<list>
- با تنظیم ماسک‌های gres بر روی وظایف (یا rankها) مطابق با <list> متصل می‌کند؛ جایی که <list> به‌صورت <gres_mask_for_task_0>,<gres_mask_for_task_1>,... است. نگاشت برای یک گره مشخص می‌شود و نگاشت یکسانی بر روی وظایف هر گره اعمال می‌گردد (یعنی کمترین شناسه وظیفه در هر گره به نخستین ماسک مشخص‌شده در فهرست نگاشت می‌شود، و الی آخر). ماسک‌های gres همیشه به‌عنوان مقادیر شانزده‌شانزدهی تفسیر می‌شوند اما می‌توانند با یک «0x» اختیاری آغاز شوند. برای ساده‌سازی پشتیبانی از تعداد وظایف زیاد، فهرست‌ها می‌توانند حاوی ستاره و تعداد تکرار باشند؛ برای مثال «mask:0x0f*4,0xf0*4». اگر پلاگین task/cgroup استفاده شود و ConstrainDevices در cgroup.conf تنظیم شده باشد، شناسه‌های gres نمایه‌های مبتنی بر صفر نسبت به gres تخصیص‌یافته به کار هستند (مثلاً نخستین gres برابر با ۰ است، حتی اگر شناسه سراسری ۳ باشد). در غیر این صورت، شناسه‌های gres همان شناسه‌های سراسری هستند و برای دریافت نتایج اتصال قابل پیش‌بینی، تمام gresهای هر گره در کار باید تخصیص داده شوند.
- none
- وظایف را به این gres متصل نمی‌کند (اتصال ضمنی حاصل از --tres-per-task و --gpus-per-task را غیرفعال می‌کند).
- per_task:<gres_per_task>
- هر وظیفه به تعداد gres مشخص‌شده در <gres_per_task> متصل خواهد شد. وظایف ترجیحاً به gresهایی با وابستگی (affinity) به هسته‌ها در تخصیص خود تخصیص داده می‌شوند (مشابه closest)، اگرچه در صورت در دسترس نبودن، هر gres دیگری را دریافت خواهند کرد. اگر هیچ وابستگی‌ای وجود نداشته باشد، به نخستین وظیفه x تعداد gres اول روی گره تخصیص می‌یابد و به همین ترتیب. gres اشتراکی (Shared gres) در صورت امکان ترجیح می‌دهد که برای هر وظیفه یک دستگاه اشتراکی متصل کند.
- single:<tasks_per_gres>
- مشابه closest است، با این تفاوت که هر وظیفه تنها می‌تواند به یک gres متصل شود، حتی زمانی که بتواند به چندین gres که به یک اندازه نزدیک هستند متصل گردد. gres مورد نظر برای اتصال توسط <tasks_per_gres> تعیین می‌شود؛ به طوری که نخستین <tasks_per_gres> وظیفه به اولین gres در دسترس متصل می‌شوند، دومین <tasks_per_gres> وظیفه به دومین gres در دسترس متصل می‌شوند، و الی آخر. این در اصل یک توزیع بلوکی وظایف بر روی gresهای موجود است، که در آن gresهای موجود بر اساس وابستگی سوکت وظیفه و وابستگی سوکت gres طبق پارامتر Cores در gres.conf تعیین می‌شوند.
-
NOTE: اتصال gres اشتراکی در حال حاضر به per_task یا none محدود است.
- --tres-per-task=<list>
- فهرستی
جداشده با
کاما از
منابع قابل
ردیابی (trackable resources)
مورد نیاز
کار را برای
هر
وظیفه‌ای
که قرار است
در تخصیص
منبع کار
ایجاد شود،
مشخص
می‌کند.
قالب هر
مدخل در
فهرست
به‌صورت
«trestype[/tresname]=count» است.
مقدار trestype
نوع منبع
قابل
ردیابی
درخواست‌شده
است (مانند
cpu، gres، license و
غیره).
مقدار tresname
نام منبع
قابل
ردیابی
است،
همانطور
که می‌توان
با sacctmgr show tres
مشاهده کرد.
این مورد
زمانی لازم
است که برای
انواع tres
مانند gres، license و
غیره وجود
داشته باشد
(مانند gpu، gpu:a100).
به منظور
درخواست
مجوز با این
گزینه،
مجوز(ها)
باید در
پارامتر
AccountingStorageTRES در slurm.conf
تعریف شده
باشند.
مقدار count
تعداد آن
منابع است.
شمارنده می‌تواند یکی از پسوندهای زیر را داشته باشد:
«k» یا «K» (ضریبی از ۱۰۲۴)،
«m» یا «M» (ضریبی از ۱۰۲۴ × ۱۰۲۴)،
«g» یا «G» (ضریبی از ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
«t» یا «T» (ضریبی از ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
«p» یا «P» (ضریبی از ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴).
مثال‌ها:--tres-per-task=cpu=4 --tres-per-task=cpu=8,license/ansys=1 --tres-per-task=gres/gpu=1 --tres-per-task=gres/gpu:a100=2
منابع مشخص‌شده بر روی هر گره به کار تخصیص داده خواهند شد. منابع قابل ردیابیِ موجود توسط مدیر سیستم قابل پیکربندی هستند.
NOTE: این گزینه به همراه gres/gpu یا gres/shard به‌طور ضمنی --tres-bind=gres/[gpu|shard]:per_task:<tres_per_task> را تنظیم می‌کند، یا اگر چندین نوع gpu مشخص شده باشد، --tres-bind=gres/gpu:per_task:<gpus_per_task_type_sum> را تنظیم خواهد کرد. این رفتار را می‌توان با تعیین صریح --tres-bind لغو کرد.
NOTE: مقادیر نامعتبر TRES برای --tres-per-task شامل موارد زیر هستند: bb,billing,energy,fs,mem,node,pages,vmem.
- -u, --unbuffered
- به‌طور پیش‌فرض، ارتباط میان slurmstepd و برنامه‌ای که توسط کاربر اجرا شده از طریق یک pipe انجام می‌شود. خروجی stdio نوشته‌شده توسط برنامه توسط glibc بافر می‌شود تا زمانی که فلاش (flush) شود یا خروجی به‌عنوان بدون بافر تنظیم گردد. به setbuf(3) مراجعه کنید. اگر این گزینه مشخص شود، وظایف با یک شبه‌ترمینال (pseudo terminal) اجرا می‌شوند تا خروجی برنامه بدون بافر باشد. این گزینه برای تخصیص‌های گام (step allocations) اعمال می‌شود.
- --usage
- نمایش پیام کوتاه راهنما و خروج.
- --use-min-nodes
- اگر بازه‌ای از تعداد گره‌ها داده شود، تعداد کمتر را ترجیح می‌دهد.
- -v, --verbose
- افزایش میزان جزئیات پیام‌های اطلاعاتی srun. استفاده چندباره از -v پرگویی srun را بیشتر افزایش می‌دهد. به‌طور پیش‌فرض تنها خطاها نمایش داده خواهند شد. این گزینه برای تخصیص‌های کار و گام اعمال می‌شود.
- -V, --version
- نمایش
اطلاعات
نسخه و
خروج. --wait-for-children
پیش از
خاتمه‌یافته
تلقی کردن
یک تسک،
منتظر به
پایان
رسیدن تمام
فرایندهای
موجود در هر
تسک
می‌ماند.
رفتار
پیش‌فرض
بدون این
گزینه این
است که تنها
منتظر
پایان
فرایند
والد (parent) در
هر تسک
بماند.
بسته به تنظیمات --kill-on-bad-exit، چنانچه فرایند والد با یک کد خروج غیرصفر خارج شود، ممکن است تسک پایان یابد. اگر --kill-on-bad-exit=1 باشد و فرایند والد با کد خروج غیرصفر خاتمه یابد، تسک به پایان خواهد رسید. اگر --kill-on-bad-exit=0 باشد و فرایند والد با کد خروج غیرصفر خارج شود، تسک تا زمان خروج تمام فرایندهای فرزند ادامه خواهد یافت.
این گزینه نیازمند proctrack/cgroup و cgroup/v2 است.
- -W, --wait=<seconds>
- مشخص می‌کند که پس از خاتمه نخستین تسک، چه مدت قبل از خاتمه دادن به تمام تسک‌های باقی‌مانده صبر شود. مقدار 0 نشان‌دهنده انتظار نامحدود است (پس از ۶۰ ثانیه هشداری صادر خواهد شد). مقدار پیش‌فرض توسط پارامتر WaitTime در فایل پیکربندی slurm تنظیم می‌شود (نگاه کنید به slurm.conf(5)). این گزینه می‌تواند برای اطمینان از خاتمه به‌موقع کار در صورت پایان زودهنگام یک یا چند تسک مفید باشد. توجه: در صورتی که تسکی با یک کد خروج غیرصفر خارج شود، گزینه -K، --kill-on-bad-exit نسبت به -W، --wait برای خاتمه فوری کار اولویت دارد. این گزینه برای تخصیص‌های کار (job allocations) اعمال می‌شود.
- --wckey=<wckey>
- مقدار wckey را برای استفاده به همراه کار مشخص می‌کند. اگر در slurm.conf مقدار TrackWCKey=no (پیش‌فرض) باشد، این مقدار نادیده گرفته می‌شود. این گزینه برای تخصیص‌های کار اعمال می‌شود.
- --x11[={all|first|last}]
- قابلیت
بازفرست X11
(هدایت X11 forwarding) را
روی
گره(های)
«all»، «first» یا
«last» تخصیص
برپا
می‌کند. این
گزینه تنها
در صورتی
فعال است که
Slurm با
پشتیبانی
از X11
کامپایل
شده باشد و
PrologFlags=x11 در slurm.conf
تعریف شده
باشد. مقدار
پیش‌فرض
«all» است.
NOTE: این گزینه در صورت ارائه هم‌زمان --clusters ممکن است کار نکند. چنین کارهایی (با یک هشدار) پذیرفته می‌شوند، اما کارکرد X11 forwarding تضمین نمی‌شود.
دستور srun درخواست کار را به کنترل‌کننده کار slurm ارسال می‌کند، سپس تمام فرایندها را روی گره‌های راه دور آغاز می‌نماید. اگر درخواست نتواند بلافاصله برآورده شود، srun تا زمان آزادسازی منابع برای اجرای کار، متوقف (مسدود) خواهد شد. اگر گزینه -I (--immediate) مشخص شده باشد، در صورتی که منابع بلافاصله در دسترس نباشند، srun خاتمه خواهد یافت.
هنگام آغاز فرایندهای راه دور، srun دایرکتوری کاری جاری را منتقل می‌کند، مگر اینکه --chdir=<path> مشخص شده باشد که در این حالت path دایرکتوری کاری برای فرایندهای راه دور خواهد شد.
گزینه‌های -n، -c و -N نحوه تخصیص پردازنده‌ها (CPUs) و گره‌ها به کار را کنترل می‌کنند. هنگام تعیین تنها تعداد فرایندهای قابل اجرا با -n، به‌طور پیش‌فرض یک CPU به ازای هر فرایند تخصیص داده می‌شود. با تعیین تعداد CPU مورد نیاز به ازای هر تسک (-c)، ممکن است بیش از یک CPU به ازای هر فرایند تخصیص یابد. اگر تعداد گره‌ها با -N مشخص شود، srun تلاش خواهد کرد حداقل به تعداد مشخص‌شده گره تخصیص دهد.
ترکیبی از سه گزینه بالا می‌تواند برای تغییر چگونگی توزیع فرایندها بین گره‌ها و پردازنده‌ها به کار رود. برای نمونه، با مشخص کردن هم تعداد فرایندها و هم تعداد گره‌هایی که کار روی آنها اجرا می‌شود، تعداد فرایندها در هر گره به‌صورت ضمنی مشخص می‌گردد. با این حال، اگر تعداد پردازنده‌ها به ازای هر فرایند اهمیت بیشتری داشته باشد، باید تعداد فرایندها (-n) و تعداد CPU به ازای هر فرایند (-c) مشخص شوند.
دستور srun از تخصیص بیش از یک فرایند به ازای هر CPU خودداری خواهد کرد مگر اینکه --overcommit (-O) نیز مشخص شده باشد.
دستور srun تلاش خواهد کرد مشخصات فوق را «در حداقل حالت» برآورده کند. به این معنا که اگر ۱۶ گره برای ۳۲ فرایند درخواست شود، و برخی گره‌ها دارای ۲ پردازنده نباشند، تخصیص گره‌ها افزایش خواهد یافت تا تقاضا برای پردازنده‌ها برآورده شود. به بیان دیگر، حداقل ۱۶ گره درخواست شده است. اما اگر ۱۶ گره برای ۱۵ فرایند درخواست شود، srun این مورد را خطا در نظر می‌گیرد، زیرا ۱۵ فرایند نمی‌توانند روی ۱۶ گره اجرا شوند.
تغییر مسیر ورودی/خروجی (IO Redirection)
به‌طور پیش‌فرض، stdout و stderr از تمام تسک‌ها به stdout و stderr دستور srun تغییر مسیر می‌یابند، و stdin از ورودی استاندارد srun به تمام تسک‌های راه دور تغییر مسیر داده می‌شود. اگر قرار است stdin تنها توسط زیرمجموعه‌ای از تسک‌های راه‌اندازی‌شده خوانده شود، مشخص کردن فایلی برای خواندن، به‌جای بازفرستادن stdin از دستور srun ترجیح داده می‌شود، زیرا از جابه‌جایی و ذخیره‌سازی داده‌هایی که هرگز خوانده نخواهند شد جلوگیری می‌کند.
برای OS X، تابع poll() از stdin پشتیبانی نمی‌کند، بنابراین ورودی گرفتن از یک ترمینال امکان‌پذیر نیست.
این رفتار را می‌توان با گزینه‌های --output، --error و --input (-o، -e، -i) تغییر داد. توجه داشته باشید که --error خروجی خطای استاندارد (stderr) خود srun را تغییر مسیر نمی‌دهد، بلکه تنها stderr ناشی از تسک‌ها را تغییر مسیر خواهد داد. مشخصات قالب معتبر برای این گزینه‌ها عبارتند از:
- all
- خروجی stdout و stderr از تمام تسک‌ها به srun تغییر مسیر می‌یابد. ورودی stdin به تمام تسک‌های راه دور همه‌پخشی (broadcast) می‌شود. (این رفتار پیش‌فرض است)
- none
- خروجی stdout و stderr از هیچ تسکی دریافت نمی‌شود. ورودی stdin به هیچ تسکی ارسال نمی‌گردد (stdin بسته است).
- taskid
- خروجی stdout و/یا stderr تنها از تسکی تغییر مسیر می‌یابد که شناسه نسبی آن برابر با taskid باشد، که در آن 0 <= taskid <= ntasks است و ntasks تعداد کل تسک‌ها در گام کاری (job step) جاری می‌باشد. ورودی stdin از stdin دستور srun به همین تسک تغییر مسیر داده می‌شود. این فایل روی گره‌ای که تسک را اجرا می‌کند نوشته خواهد شد.
- filename
- دستور srun خروجی stdout و/یا stderr تمام تسک‌ها را به فایل نام‌برده تغییر مسیر می‌دهد. ورودی stdin از فایل مشخص‌شده تغییر مسیر یافته و به تمام تسک‌های کار همه‌پخشی می‌شود. filename به مسیری در میزبانِ اجراکننده srun اشاره دارد. بسته به ساختار سیستم فایل خوشه، این امر می‌تواند باعث شود بسته به اینکه کار در حالت دسته‌ای (batch mode) اجرا می‌شود یا خیر، خروجی در مکان‌های متفاوتی ظاهر گردد.
- filename pattern
- دستور srun اجازه می‌دهد از یک الگوی نام فایل (filename pattern) برای تولید فایل ورودی/خروجی نام‌برده در بالا استفاده شود. فهرست مشخص‌کننده‌های قالب زیر می‌تواند در رشته قالب جهت ایجاد نام فایلی که برای یک jobid، stepid، گره یا تسک معین یکتا باشد، به کار رود. در هر مورد، تعداد مناسبی فایل باز شده و با تسک‌های مربوطه پیوند می‌یابند. توجه داشته باشید که هر رشته قالب حاوی %t، %n، و/یا %N روی گره مجری تسک نوشته خواهد شد، نه روی گره‌ای که srun در آن اجرا می‌شود.
- \\
- هیچ‌یک از نمادهای جایگزینی را پردازش نکن.
- %%
- نویسه «%».
- %A
- شماره تخصیص کار اصلیِ آرایه کار (job array).
- %a
- شماره شناسه (شاخص) آرایه کار (job array).
- %J
- مقدار jobid.stepid کارِ در حال اجرا (مانند «128.0»). مقدار stepid تنها برای گام‌های عادی بسط داده می‌شود، نه برای گام‌های خاص مانند «batch» یا «extern»..IP
- %j
- شناسه کار (jobid) مربوط به کارِ در حال اجرا.
- %S
- شناسه SLUID مربوط به کارِ در حال اجرا.
- %s
- شناسه گام (stepid) مربوط به کارِ در حال اجرا.
- %N
- نام کوتاه‌شده میزبان (hostname). این مورد یک فایل ورودی/خروجی (IO) جداگانه به ازای هر گره ایجاد خواهد کرد.
- %n
- شناسه گره نسبت به کار جاری (برای نمونه "0" نخستین گره از کارِ در حال اجرا است). این مورد یک فایل ورودی/خروجی (IO) جداگانه به ازای هر گره ایجاد خواهد کرد.
- %t
- شناسه وظیفه (رتبه یا rank) نسبت به کار جاری. این مورد یک فایل ورودی/خروجی (IO) جداگانه به ازای هر وظیفه ایجاد خواهد کرد.
- %u
- نام کاربری.
- %x
- نام کار.
عددی که بین نویسه درصد و مشخص‌کننده قالب قرار می‌گیرد، می‌تواند برای پُر کردن نتیجه با صفر (zero-pad) در نام فایل ورودی/خروجی، دست‌کم به اندازه ارقام مشخص‌شده به کار رود. اگر مشخص‌کننده قالب مربوط به داده‌های غیرعددی باشد (برای نمونه %N)، این عدد نادیده گرفته می‌شود. بیشینه این عدد ۱۰ است؛ اگر مقداری بزرگ‌تر از ۱۰ مشخص شود، نتیجه حداکثر تا ۱۰ نویسه با صفر پُر می‌شود. چند نمونه از نحوه به‌کارگیری رشته قالب برای یک گام کاریِ ۴ وظیفه‌ای با JobID برابر با 128 و step id برابر با 0 در زیر آورده شده است:
- job%J.out
- job128.0.out
- job%4j.out
- job0128.out
- job%2j-%2t.out
- job128-00.out, job128-01.out, ...
کارایی (PERFORMANCE)
اجرای srun یک فراخوانی روال از راه دور (RPC) را به slurmctld می‌فرستد. چنانچه فراخوانی‌های بسیاری از جانب srun یا دیگر دستورهای کلاینت Slurm که فراخوانی روال از راه دور به دیمن slurmctld ارسال می‌کنند به یک‌باره وارد شوند، ممکن است موجب افت کارایی دیمن slurmctld شده و احتمالاً به منع خدمت (denial of service) بیانجامد.
از اجرای srun یا دیگر دستورهای کلاینت Slurm که فراخوانی‌های روال از راه دور به slurmctld می‌فرستند در حلقه‌های اسکریپت‌های شل یا دیگر برنامه‌ها خودداری کنید. اطمینان یابید که برنامه‌ها، فراخوانی‌های srun را به حداقل میزان لازم برای گردآوری اطلاعات مورد نیاز محدود می‌سازند..SH "متغیرهای محیطی ورودی (INPUT ENVIRONMENT VARIABLES)"
در هنگام
راه‌اندازی،
srun
گزینه‌های
تنظیم‌شده
در
متغیرهای
محیطی زیر
را خوانده و
پردازش
می‌کند.
بیشتر این
متغیرها به
همان
شیوه‌ای که
گزینه‌ها
در بالا
تعریف
شده‌اند،
مقداردهی
می‌شوند.
برای
گزینه‌های
پرچمی که
به‌گونه‌ای
تعریف
شده‌اند که
هیچ
آرگومانی
نمی‌پذیرند،
می‌توان
گزینه را با
تنظیم
متغیر
محیطی بدون
مقدار (رشته
خالی یا NULL)،
رشته «yes» یا
یک عدد
غیرصفر
فعال کرد. هر
مقدار
دیگری برای
متغیر
محیطی منجر
به فعال
نشدن آن
گزینه
خواهد شد.
چند استثنا
برای این
قوانین
وجود دارد
که در زیر به
آنها
اشاره شده
است.
نکته:
گزینه‌های
خط فرمان
همواره بر
تنظیمات
متغیرهای
محیطی
اولویت
دارند.
- PMI_FANOUT
- این متغیر منحصراً همراه با PMI (شامل MPICH2 و MVAPICH2) استفاده می‌شود و انشعاب (fanout) ارتباطات داده را کنترل می‌کند. دستور srun پیام‌ها را (از طریق کتابخانه PMI) به برنامه‌های کاربردی ارسال می‌کند و این برنامه‌ها ممکن است موظف شوند آن داده‌ها را حداکثر تا این تعداد تسک اضافی هدایت (forward) کنند. مقادیر بالاتر بار کاری را از دستور srun بر دوش برنامه‌ها منتقل می‌کند و احتمال آسیب‌پذیری در برابر خطاها و خرابی‌ها را افزایش می‌دهد. مقدار پیش‌فرض 32 است.
- PMI_FANOUT_OFF_HOST
- این متغیر منحصراً همراه با PMI (شامل MPICH2 و MVAPICH2) استفاده می‌شود و انشعاب ارتباطات داده را کنترل می‌کند. دستور srun پیام‌ها را (از طریق کتابخانه PMI) به برنامه‌های کاربردی ارسال می‌کند و این برنامه‌ها ممکن است موظف شوند آن داده‌ها را به تسک‌های اضافی هدایت کنند. به‌طور پیش‌فرض، srun برای هر میزبان یک پیام ارسال می‌کند و یک تسک روی آن میزبان، داده‌ها را حداکثر تا میزان PMI_FANOUT به دیگر تسک‌های موجود روی همان میزبان هدایت می‌کند. اگر PMI_FANOUT_OFF_HOST تعریف شده باشد، ممکن است از تسک کاربر خواسته شود تا داده‌ها را به تسک‌های موجود روی دیگر میزبان‌ها هدایت کند. تنظیم PMI_FANOUT_OFF_HOST ممکن است کارایی را افزایش دهد. از آنجا که کار بیشتری توسط کتابخانه PMI بارگذاری‌شده توسط برنامه کاربر انجام می‌شود، بروز خرابی‌ها نیز می‌تواند شایع‌تر بوده و عیب‌یابی آنها دشوارتر گردد. این متغیر باید با مقدار 0 یا 1 غیرفعال یا فعال شود.
- PMI_TIME
- این متغیر منحصراً همراه با PMI (شامل MPICH2 و MVAPICH2) استفاده می‌شود و کنترل می‌کند که ارتباطات تسک‌ها با srun تا چه اندازه در طول زمان توزیع شوند تا از ایجاد بار اضافی و سرریز کاری دستور srun جلوگیری شود. مقدار پیش‌فرض 500 (میکروثانیه) به ازای هر تسک است. روی پردازنده‌های نسبتاً کند یا سیستم‌هایی با تعداد بسیار زیاد پردازنده (و مجموعه‌داده‌های بزرگ PMI)، ممکن است مقادیر بالاتری مورد نیاز باشد.
- SLURM_ACCOUNT
- مشابه -A, --account
- SLURM_ACCTG_FREQ
- مشابه --acctg-freq
- SLURM_BCAST
- مشابه --bcast
- SLURM_BCAST_EXCLUDE
- مشابه --bcast-exclude
- SLURM_BURST_BUFFER
- مشابه --bb
- SLURM_CLUSTERS
- مشابه -M، --clusters
- SLURM_COMPRESS
- مشابه --compress
- SLURM_CONF
- مکان فایل پیکربندی Slurm.
- SLURM_CONSTRAINT
- مشابه -C، --constraint
- SLURM_CORE_SPEC
- مشابه --core-spec
- SLURM_CPU_BIND
- مشابه --cpu-bind
- SLURM_CPU_FREQ_REQ
- مشابه --cpu-freq.
- SLURM_CPUS_PER_GPU
- مشابه --cpus-per-gpu
- SLURM_CPUS_PER_TASK
- مشابه -c, --cpus-per-task یا --tres-per-task=cpu=#
- SLURM_DEBUG
- مشابه -v, --verbose در صورت تنظیم روی 1؛ در صورت تنظیم روی 2 مقدار -vv را ارائه می‌دهد، و غیره.
- SLURM_DEBUG_FLAGS
- پرچم‌های اشکال‌زدایی را برای استفاده توسط srun مشخص می‌کند. برای فهرست کامل پرچم‌ها، DebugFlags را در صفحه راهنمای slurm.conf(5) ببینید. این متغیر محیطی بر تنظیمات موجود در slurm.conf اولویت دارد.
- SLURM_DELAY_BOOT
- مشابه --delay-boot
- SLURM_DEPENDENCY
- مشابه -d, --dependency=<jobid>
- SLURM_DISABLE_STATUS
- مشابه -X, --disable-status
- SLURM_DIST_PLANESIZE
- اندازه توزیع صفحه‌ای (Plane). تنها در صورتی استفاده می‌شود که --distribution=plane بدون =<size> تنظیم شده باشد.
- SLURM_DISTRIBUTION
- مشابه -m, --distribution
- SLURM_EPILOG
- مشابه --epilog
- SLURM_EXACT
- مشابه --exact
- SLURM_EXCLUSIVE
- مشابه --exclusive
- SLURM_EXIT_ERROR
- کد خروجی ایجادشده هنگام رخ دادن خطای Slurm (مانند گزینه‌های نامعتبر) را مشخص می‌کند. اسکریپت‌ها می‌توانند از این مقدار برای تمایز قائل شدن میان کدهای خروجی برنامه و شرایط گوناگون خطای Slurm استفاده کنند. همچنین نگاه کنید به SLURM_EXIT_IMMEDIATE..IP
- SLURM_EXIT_IMMEDIATE
- کد خروجی تولید شده هنگام استفاده از گزینهٔ --immediate در شرایطی که منابع در حال حاضر در دسترس نیستند را مشخص می‌کند. این متغیر می‌تواند توسط اسکریپت‌ها برای تمایز کدهای خروجی برنامه از شرایط خطای مختلف Slurm استفاده شود. همچنین SLURM_EXIT_ERROR را ببینید.
- SLURM_EXPORT_ENV
- یکسان با --export
- SLURM_GPU_BIND
- یکسان با --gpu-bind
- SLURM_GPU_FREQ
- یکسان با --gpu-freq
- SLURM_GPUS
- یکسان با -G, --gpus
- SLURM_GPUS_PER_NODE
- یکسان با --gpus-per-node، مگر در یک تخصیص موجود، که در آن صورت اگر --gpus مشخص شده باشد، نادیده گرفته خواهد شد.
- SLURM_GPUS_PER_TASK
- یکسان با --gpus-per-task
- SLURM_GRES
- یکسان با --gres. همچنین SLURM_STEP_GRES را ببینید.
- SLURM_GRES_FLAGS
- یکسان با --gres-flags
- SLURM_HINT
- یکسان با --hint
- SLURM_IMMEDIATE
- یکسان با -I, --immediate
- SLURM_JOB_ID
- یکسان با --jobid
- SLURM_JOB_NAME
- یکسان با -J, --job-name، مگر در یک تخصیص موجود، که در آن صورت نادیده گرفته می‌شود تا از نام کار دسته‌ای (batch job) به عنوان نام هر گام کار (job step) استفاده نشود.
- SLURM_JOB_NUM_NODES
- یکسان با -N, --nodes. تعداد کل گره‌ها در تخصیص منابع کار.
- SLURM_KILL_BAD_EXIT
- یکسان با -K, --kill-on-bad-exit. برای غیرفعال یا فعال کردن این گزینه باید روی 0 یا 1 تنظیم شود.
- SLURM_LABELIO
- یکسان با -l, --label
- SLURM_MEM_BIND
- یکسان با --mem-bind
- SLURM_MEM_PER_CPU
- یکسان با --mem-per-cpu
- SLURM_MEM_PER_GPU
- یکسان با --mem-per-gpu
- SLURM_MEM_PER_NODE
- یکسان با --mem
- SLURM_MPI_TYPE
- یکسان با --mpi
- SLURM_NETWORK
- یکسان با --network
- SLURM_NNODES
- یکسان با -N, --nodes. تعداد کل گره‌ها در تخصیص منابع کار. SLURM_JOB_NUM_NODES را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
- SLURM_NO_KILL
- یکسان با -k، --no-kill
- SLURM_NPROCS
- یکسان با -n, --ntasks. SLURM_NTASKS را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
- SLURM_NTASKS
- یکسان با -n, --ntasks
- SLURM_NTASKS_PER_CORE
- یکسان با --ntasks-per-core
- SLURM_NTASKS_PER_GPU
- یکسان با --ntasks-per-gpu
- SLURM_NTASKS_PER_NODE
- یکسان با --ntasks-per-node
- SLURM_NTASKS_PER_SOCKET
- یکسان با --ntasks-per-socket
- SLURM_OOMKILLSTEP
- یکسان با --oom-kill-step
- SLURM_OPEN_MODE
- یکسان با --open-mode
- SLURM_OVERCOMMIT
- یکسان با -O, --overcommit
- SLURM_OVERLAP
- یکسان با --overlap.IP
- SLURM_PARTITION
- مشابه -p, --partition
- SLURM_PMI_KVS_NO_DUP_KEYS
- اگر تنظیم شود، جفت‌کلیدهای PMI حاوی هیچ کلید تکراری نخواهند بود. MPI می‌تواند از این متغیر برای مطلع کردن کتابخانهٔ PMI استفاده کند که از کلیدهای تکراری استفاده نخواهد کرد، تا بدین ترتیب PMI بررسی کلیدهای تکراری را نادیده بگیرد. این مورد برای MPICH2 صادق است و بار پردازشی ناشی از بررسی تکراری‌ها را جهت بهبود کارایی کاهش می‌دهد.
- SLURM_POWER
- مشابه --power
- SLURM_PROFILE
- مشابه --profile
- SLURM_PROLOG
- مشابه --prolog
- SLURM_QOS
- مشابه --qos
- SLURM_REMOTE_CWD
- مشابه -D, --chdir=
- SLURM_REQ_SWITCH
- هنگامی که از یک توپولوژی درختی استفاده می‌شود، این متغیر بیشینهٔ تعداد سوییچ‌های مورد نظر برای تخصیص کار و به صورت اختیاری حداکثر زمان انتظار برای آن تعداد سوییچ را مشخص می‌کند. به --switches مراجعه کنید.
- SLURM_RESERVATION
- مشابه --reservation
- SLURM_RESV_PORTS
- مشابه --resv-ports
- SLURM_SEND_LIBS
- مشابه --send-libs
- SLURM_SIGNAL
- مشابه --signal
- SLURM_SPREAD_JOB
- مشابه --spread-job
- SLURM_SRUN_REDUCE_TASK_EXIT_MSG
- اگر تنظیم شده و غیرصفر باشد، پیام‌های خروج وظایف متوالی با کد خروج یکسان تنها یک بار چاپ خواهند شد.
- SRUN_ERROR
- مشابه -e, --error
- SRUN_INPUT
- مشابه -i, --input
- SRUN_OUTPUT
- مشابه -o, --output
- SLURM_STEP_GRES
- مشابه --gres (تنها برای گام‌های کار اعمال می‌شود، نه برای تخصیص‌های کار). همچنین به SLURM_GRES مراجعه کنید.
- SLURM_STEP_KILLED_MSG_NODE_ID=ID
- اگر تنظیم شود، تنها گره مشخص‌شده هنگام کشته شدن کار یا گام توسط یک سیگنال، گزارش ثبت خواهد کرد.
- SLURM_TASK_EPILOG
- مشابه --task-epilog
- SLURM_TASK_PROLOG
- مشابه --task-prolog
- SLURM_TEST_EXEC
- در صورت تعریف شدن، srun پیش از اقدام برای اجرای برنامه روی گره‌های موجود در گام، وجود برنامهٔ اجرایی و مجوز اجرای کاربر را روی گره‌ای که srun از آن فراخوانی شده بررسی می‌کند.
- SLURM_THREAD_SPEC
- مشابه --thread-spec
- SLURM_THREADS
- مشابه -T, --threads
- SLURM_THREADS_PER_CORE
- مشابه --threads-per-core
- SLURM_TIMELIMIT
- مشابه -t, --time
- SLURM_TRES_BIND
- مشابه --tres-bind. اگر --gpu-bind مشخص شده باشد، همانند این است که در --tres-bind مشخص شده باشد و در SLURM_TRES_BIND نیز تنظیم خواهد شد.
- SLURM_TRES_PER_TASK
- مشابه --tres-per-task.
- SLURM_UMASK
- در صورت تعریف شدن، Slurm هنگام ایجاد فایل‌های خروجی/خطای کار، از umask تعریف‌شده برای تنظیم مجوزها استفاده خواهد کرد.
- SLURM_UNBUFFEREDIO
- مشابه -u, --unbuffered
- SLURM_USE_MIN_NODES
- مشابه --use-min-nodes
- SLURM_WAIT
- مشابه -W, --wait
- SLURM_WAIT4SWITCH
- حداکثر زمان انتظار برای سوییچ‌های درخواستی. به --switches مراجعه کنید. SLURM_WCKEY مشابه -W, --wckey.
- SLURM_WORKING_DIR
- -D, --chdir
- SLURMD_DEBUG
- مشابه --slurmd-debug.
- SRUN_CONTAINER
- مشابه --container.
- SRUN_CONTAINER_ID
- مشابه --container-id.
- SRUN_CONTAINER_TYPE
- مشابه --container-type.
- SRUN_EXPORT_ENV
- مشابه --export است و هرگونه مقداردهی برای SLURM_EXPORT_ENV را بازنویسی می‌کند.
- SRUN_SEGMENT_SIZE
- مشابه --segment.
متغیرهای محیطی خروجی (OUTPUT ENVIRONMENT VARIABLES)
دستور srun تعدادی متغیر محیطی را در محیط وظایف در حال اجرا روی گره‌های محاسباتی دوردست تنظیم می‌کند. این متغیرهای محیطی عبارتند از:
- SLURM_*_HET_GROUP_#
- برای یک تخصیص کار ناهمگن (heterogeneous job)، متغیرهای محیطی به طور جداگانه برای هر مؤلفه تنظیم می‌شوند.
- SLURM_CLUSTER_NAME
- نام خوشه‌ای که کار روی آن در حال اجرا است.
- SLURM_CPU_BIND_LIST
- فهرست نگاشت (map) یا ماسک --cpu-bind (فهرستی از شناسه‌های CPU یا ماسک‌های Slurm برای این گره، CPU_ID = Board_ID x threads_per_board + Socket_ID x threads_per_socket + Core_ID x threads_per_core + Thread_ID).
- SLURM_CPU_BIND_TYPE
- نوع --cpu-bind (مقادیر none، map_cpu:، mask_cpu:، rank_ldom، map_ldom:، mask_ldom:).
- SLURM_CPU_BIND_VERBOSE
- میزان پرگویی --cpu-bind (مقادیر quiet، verbose).
- SLURM_CPU_FREQ_REQ
- شامل مقدار درخواست‌شده برای بسامد پردازنده در دستور srun به صورت یک بسامد عددی بر حسب کیلوهرتز، یا یک مقدار کدگذاری‌شده برای درخواست low، medium، highm1 یا high برای بسامد است. توضیحات گزینه --cpu-freq یا متغیر محیطی ورودی SLURM_CPU_FREQ_REQ را ببینید.
- SLURM_CPUS_ON_NODE
- تعداد CPUهای دردسترس برای گام (step) روی این گره. نکته: افزونه select/linear کل گره‌ها را به کارها تخصیص می‌دهد، بنابراین این مقدار بیانگر تعداد کل CPUهای موجود روی گره است. برای افزونه cons/tres، این مقدار بیانگر تعداد CPUهای تخصیص‌یافته به این گام روی این گره است.
- SLURM_CPUS_PER_TASK
- تعداد CPUهای درخواست‌شده به ازای هر وظیفه (task). تنها در صورتی مقداردهی می‌شود که گزینه --cpus-per-task یا گزینه --tres-per-task=cpu=# مشخص شده باشد.
- SLURM_DISTRIBUTION
- نوع توزیع برای کارهای تخصیص‌یافته. توزیع با -m، --distribution تنظیم می‌شود.
- SLURM_GPUS_ON_NODE
- تعداد GPUهای دردسترس برای گام روی این گره.
- SLURM_GTIDS
- شناسه‌های سراسری وظایف (Global task IDs) در حال اجرا روی این گره. مبتنی بر صفر و جداشده با کاما. در صورتی که Slurm با پشتیبانی از pmi ساخته شده باشد، این متغیر به صورت داخلی توسط pmi خوانده می‌شود. فعال گذاشتن این متغیر ممکن است هنگام استفاده از بسته‌های خارجی از درون کار مشکلاتی ایجاد کند (گزارش شده که Abaqus و Ansys در صورت مقداردهی بودن آن دچار مشکل می‌شوند - به مستندات نرم‌افزار ثالث مربوطه مراجعه کنید).
- SLURM_HET_SIZE
- روی تعداد مؤلفه‌ها در کار ناهمگن تنظیم می‌شود.
- SLURM_JOB_ACCOUNT
- نام حساب مرتبط با تخصیص کار.
- SLURM_JOB_CPUS_PER_NODE
- تعداد CPUهای دردسترس برای کار روی گره‌های موجود در تخصیص، با استفاده از قالب CPU_count[(xnumber_of_nodes)][,CPU_count[(xnumber_of_nodes)] ...]. برای مثال: مقدار SLURM_JOB_CPUS_PER_NODE='72(x2),36' نشان می‌دهد که در گره اول و دوم (همانطور که توسط SLURM_JOB_NODELIST فهرست شده است) تخصیص دارای ۷۲ پردازنده است، در حالی که گره سوم ۳۶ پردازنده دارد. نکته: افزونه select/linear کل گره‌ها را به کارها تخصیص می‌دهد، بنابراین این مقدار بیانگر تعداد کل CPUها روی گره‌های تخصیص‌یافته است. افزونه select/cons_tres پردازنده‌ها را به صورت انفرادی به کارها تخصیص می‌دهد، بنابراین این عدد بیانگر تعداد پردازنده‌های تخصیص‌یافته به کار است.
- SLURM_JOB_DEPENDENCY
- روی مقدار گزینه --dependency تنظیم می‌شود.
- SLURM_JOB_END_TIME
- برچسب زمانی یونیکس (UNIX timestamp) برای زمان تخمینی پایان کار.
- SLURM_JOB_GPUS
- شناسه‌های سراسری GPU برای GPUهای تخصیص‌یافته به این کار. شناسه‌های GPU وابسته به هیچ دستگاه cgroup نیستند، حتی اگر دستگاه‌ها با task/cgroup محدود شده باشند. تنها در کارهای دسته‌ای (batch) و تعاملی (interactive) تنظیم می‌شود.
- SLURM_JOB_ID
- شناسه کار (Job ID) در حال اجرا.
- SLURM_JOB_LICENSES
- نام و تعداد مجوز(های) درخواست‌شده.
- SLURM_JOB_NAME
- هنگامی که srun برای ایجاد یک تخصیص کار جدید استفاده می‌شود، با مقدار گزینه --job-name یا نام دستور تنظیم می‌شود. در حالتی که srun تنها برای ایجاد یک گام کار (یعنی درون یک تخصیص کار موجود) به کار رود، تنظیم نمی‌شود. SLURM_JOB_NODELIST فهرست گره‌های تخصیص‌یافته به کار.
- SLURM_JOB_NODES
- تعداد کل گره‌ها در تخصیص منابع کار.
- SLURM_JOB_PARTITION
- نام پارتیشنی که کار در آن در حال اجرا است.
- SLURM_JOB_QOS
- کیفیت خدمات (QOS) مربوط به تخصیص کار.
- SLURM_JOB_RESERVATION
- رزرو پیشرفته (reservation) شامل تخصیص کار، در صورت وجود.
- SLURM_JOB_SEGMENT_SIZE
- اندازه قطعه‌هایی (segments) که برای ایجاد تخصیص کار استفاده شده است. تنها در صورتی تنظیم می‌شود که --segment مشخص شده باشد.
- SLURM_JOB_START_TIME
- برچسب زمانی یونیکس (UNIX timestamp) برای زمان شروع کار.
- SLURM_JOBID
- شناسه کار در حال اجرا. SLURM_JOB_ID را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
- SLURM_LAUNCH_NODE_IPADDR
- نشانی IP گره‌ای که راه‌اندازی وظیفه از آن آغاز شده است (جایی که دستور srun از آن اجرا شد).
- SLURM_LOCALID
- شناسه وظیفه محلی گره برای فرایند درون یک کار.
- SLURM_MEM_BIND_LIST
- فهرست نگاشت یا ماسک --mem-bind (<فهرست شناسه‌ها یا ماسک‌ها برای این گره>).
- SLURM_MEM_BIND_PREFER
- ترجیح --mem-bind (مقدار prefer).
- SLURM_MEM_BIND_TYPE
- نوع --mem-bind (شامل none,rank,map_mem:,mask_mem:,local).
- SLURM_MEM_BIND_VERBOSE
- میزان پرگویی --mem-bind (شامل quiet,verbose).
- SLURM_NETWORK
- در صورت مشخص شدن، روی مقدار گزینهٔ --network تنظیم می‌شود.
- SLURM_NODEID
- شناسه نسبی گره (node ID) مربوط به گره کنونی.
- SLURM_NPROCS
- تعداد کل فرایندها در کار یا گام کار فعلی. SLURM_NTASKS را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
- SLURM_NTASKS
- تعداد کل فرایندها در کار یا گام کار فعلی.
- SLURM_OVERCOMMIT
- اگر --overcommit مشخص شده باشد، روی 1 تنظیم می‌شود.
- SLURM_PRIO_PROCESS
- اولویت زمان‌بندی (مقدار nice) در زمان ثبت کار. این مقدار به فرایندهای ایجادشده (spawned) انتشار می‌یابد.
- SLURM_PROCID
- رتبه MPI (یا شناسه نسبی فرایند) برای فرایند فعلی.
- SLURM_SRUN_COMM_HOST
- نشانی IP میزبان ارتباطی srun.
- SLURM_SRUN_COMM_PORT
- درگاه ارتباطی srun.
- SLURM_CONTAINER
- بسته OCI (یا OCI Bundle) برای کار. تنها در صورتی تنظیم می‌شود که --container مشخص شده باشد.
- SLURM_CONTAINER_ID
- شناسه OCI برای کار. تنها در صورتی تنظیم می‌شود که --container_id مشخص شده باشد.
- SLURM_CONTAINER_TYPE
- نوع کانتینر برای کار. تنها در صورتی تنظیم می‌شود که --container_type مشخص شده باشد.
- SLURM_SHARDS_ON_NODE
- تعداد GPU Shardهای در دسترس برای گام روی این گره.
- SLURM_STEP_GPUS
- شناسه‌های سراسری GPU برای پردازنده‌های گرافیکی تخصیص‌یافته به این گام (به‌جز گام‌های دسته‌ای (batch) و تعاملی). شناسه‌های GPU وابسته به هیچ cgroup دستگاهی نیستند، حتی اگر دستگاه‌ها توسط task/cgroup محدود شده باشند.
- SLURM_STEP_ID
- شناسه گام (step ID) در کار فعلی.
- SLURM_STEP_LAUNCHER_PORT
- درگاه راه‌انداز گام.
- SLURM_STEP_NODELIST
- فهرست گره‌های تخصیص‌یافته به گام.
- SLURM_STEP_NUM_NODES
- تعداد گره‌های تخصیص‌یافته به گام.
- SLURM_STEP_NUM_TASKS
- تعداد فرایندها در گام کار یا کل گام کار ناهمگن (heterogeneous).
- SLURM_STEP_TASKS_PER_NODE
- تعداد فرایندها در هر گره درون گام. SLURM_STEPID شناسه مرحله (step ID) کار جاری. به SLURM_STEP_ID مراجعه کنید. جهت سازگاری با نسخه‌های پیشین گنجانده شده است.
- SLURM_SUBMIT_DIR
- دایرکتوری‌ای که تخصیص منابع از آن فراخوانی شده است.
- SLURM_SUBMIT_HOST
- نام میزبان (hostname) رایانه‌ای که تخصیص منابع از آن فراخوانی شده است.
- SLURM_TASK_PID
- شناسه فرایند (PID) وظیفه‌ای که در حال آغاز است.
- SLURM_TASKS_PER_NODE
- تعداد وظایفی که باید روی هر گره آغاز شوند. مقادیر با کاما جدا شده و به همان ترتیبی هستند که در SLURM_JOB_NODELIST آمده است. اگر دو یا چند گره متوالی تعداد وظایف یکسانی داشته باشند، آن تعداد با «(x#)» مشخص می‌شود که در آن «#» تعداد تکرار است. برای مثال، «SLURM_TASKS_PER_NODE=2(x3),1» نشان می‌دهد که سه گره نخست هرکدام دو وظیفه و گره چهارم یک وظیفه را اجرا خواهند کرد.
- SLURM_TOPOLOGY_ADDR
- تنها در صورتی تنظیم می‌شود که افزونه topology/tree روی سامانه پیکربندی شده باشد. مقدار آن روی نام سوئیچ‌های شبکه‌ای که ممکن است در ارتباطات کار دخیل باشند، از بالاترین سطح سوئیچ سیستم تا سوئیچ برگ (leaf) و در انتها نام گره تنظیم خواهد شد. یک نقطه برای جدا کردن نام هر جزء سخت‌افزاری استفاده می‌شود.
- SLURM_TOPOLOGY_ADDR_PATTERN
- تنها در صورتی تنظیم می‌شود که افزونه topology/tree روی سامانه پیکربندی شده باشد. مقدار آن روی انواع اجزای فهرست‌شده در SLURM_TOPOLOGY_ADDR تنظیم خواهد شد. هر جزء به عنوان "switch" یا "node" شناسایی می‌شود. یک نقطه برای جدا کردن نوع هر جزء سخت‌افزاری به کار می‌رود.
- SLURM_TRES_PER_TASK
- روی مقدار --tres-per-task تنظیم می‌شود. اگر --cpus-per-task یا --gpus-per-task مشخص شده باشد، به گونه‌ای در SLURM_TRES_PER_TASK نیز تنظیم می‌گردد که گویی در --tres-per-task تعیین شده است.
- SLURM_UMASK
- مقدار umask معتبر در زمان ارسال کار.
- SLURMD_NODENAME
- نام گره‌ای که وظیفه را اجرا می‌کند. در مورد یک کار موازی که روی چندین گره محاسباتی اجرا می‌شود، این متغیر محیطی برای وظایف مختلف، روی هر گره محاسباتی مقادیر متفاوتی خواهد داشت.
- SRUN_DEBUG
- روی سطح ثبت وقایع (logging) دستور srun تنظیم می‌شود. مقدار پیش‌فرض ۳ است (سطح info). این مقدار بر اساس گزینه‌های --verbose و --quiet افزایش یا کاهش می‌یابد.
سیگنال‌ها و دنباله‌های گریز (SIGNALS AND ESCAPE SEQUENCES)
سیگنال‌های ارسال‌شده به دستور srun، به جز چند مورد استثنا، به طور خودکار به وظایفی که در حال کنترل آن‌هاست فوروارد می‌شوند. دنباله گریز <control-c> وضعیت تمام وظایف مرتبط با دستور srun را گزارش می‌دهد. اگر <control-c> دو بار در عرض یک ثانیه وارد شود، سیگنال SIGINT مربوطه به تمام وظایف ارسال شده و یک دنباله خاتمه آغاز می‌گردد که سیگنال‌های SIGCONT، SIGTERM و SIGKILL را به تمامی وظایف ایجادشده ارسال می‌کند. اگر برای بار سوم <control-c> دریافت شود، برنامه srun بدون منتظر ماندن برای خروج وظایف دوردست یا اتمام I/O آنها خاتمه می‌یابد.
دنباله گریز <control-z> در حال حاضر نادیده گرفته می‌شود.
فوروارد سیگنال برای مراحل ناهمگام (--async) در دسترس نیست؛ srun پیش از آغاز مرحله خارج می‌شود و هیچ اتصالی به وظایف در حال اجرا نگه نمی‌دارد. از scancel --signal برای ارسال سیگنال‌ها به یک مرحله ناهمگام استفاده کنید..SH "پشتیبانی از MPI (MPI SUPPORT)" استفاده از MPI به نوع MPI مورد استفاده بستگی دارد. سه حالت عملکردی اساساً متفاوت وجود دارد که توسط این پیاده‌سازی‌های گوناگون MPI به کار گرفته می‌شوند.
1. Slurm وظایف را مستقیماً راه‌اندازی کرده و مقداردهی اولیه ارتباطات را از طریق رابط‌های برنامه‌نویسی کاربردی (API) PMI2 یا PMIx انجام می‌دهد. برای نمونه: "srun -n16 a.out";.
2. Slurm یک تخصیص منبع برای کار ایجاد می‌کند و سپس mpirun وظایف را با استفاده از زیرساخت Slurm اجرا می‌نماید (OpenMPI).
3. Slurm یک تخصیص منبع برای کار ایجاد می‌کند و سپس mpirun وظایف را با استفاده از سازوکاری غیر از Slurm، مانند SSH یا RSH اجرا می‌کند. این وظایف خارج از پایش یا کنترل Slurm راه‌اندازی می‌شوند. اسکریپت epilog در Slurm باید طوری پیکربندی شود که هنگام رهاسازی تخصیص کار، این وظایف را پاکسازی کند، یا استفاده از pam_slurm_adopt به‌شدت توصیه می‌شود.
برای اطلاعات بیشتر در مورد استفاده از این پیاده‌سازی‌های مختلف MPI با Slurm، به https://slurm.schedmd.com/mpi_guide.html مراجعه کنید.
پیکربندی چندبرنامه‌ای (MULTIPLE PROGRAM CONFIGURATION)
کامنت‌ها در فایل پیکربندی باید یک "#" در ستون اول داشته باشند. فایل پیکربندی شامل فیلدهای زیر است که با فاصله‌های خالی (white space) از هم جدا می‌شوند:
- رتبه وظیفه (Task rank)
- یک یا چند رتبه وظیفه برای استفاده از این پیکربندی. مقادیر چندگانه را می‌توان با کاما از هم جدا کرد. محدوده‌ها را می‌توان با دو عدد که با یک '-' جدا شده‌اند مشخص کرد، به‌طوری که عدد کوچک‌تر ابتدا بیاید (برای نمونه "0-4" و نه "4-0"). برای مشخص کردن تمام وظایفی که به شکل دیگری مشخص نشده‌اند، رتبه '*' را به عنوان آخرین خط فایل مشخص کنید. اگر تلاشی برای راه‌اندازی وظیفه‌ای صورت گیرد که هیچ برنامه اجرایی برای آن تعریف نشده باشد، پیام خطای زیر تولید خواهد شد: "No executable program specified for this task".
- برنامه اجرایی (Executable)
- نام برنامه‌ای که باید اجرا شود. در صورت تمایل می‌تواند مسیر کامل (fully qualified pathname) باشد.
- آرگومان‌ها (Arguments)
- آرگومان‌های برنامه. عبارت "%t" با شماره وظیفه جایگزین خواهد شد. عبارت "%o" با افست وظیفه درون این محدوده جایگزین خواهد شد (برای نمونه مقدار رتبه وظیفه پیکربندی‌شده‌ی "1-5" مقادیر افست "0-4" را خواهد داشت). برای جلوگیری از تفسیر مقادیر محصورشده، می‌توان از علامت‌های نقل‌قول تکی (single quotes) استفاده کرد. این فیلد اختیاری است. هر آرگومانی برای برنامه که در خط فرمان وارد شود، به آرگومان‌های مشخص‌شده در فایل پیکربندی افزوده خواهد شد.
برای نمونه:
$ cat silly.conf ################################################################### # srun multiple program configuration file # # srun -n8 -l --multi-prog silly.conf ################################################################### 4-6 hostname 1,7 echo task:%t 0,2-3 echo offset:%o $ srun -n8 -l --multi-prog silly.conf 0: offset:0 1: task:1 2: offset:1 3: offset:2 4: linux15.llnl.gov 5: linux16.llnl.gov 6: linux17.llnl.gov 7: task:7
- مثال ۱:
-
این مثال ساده نحوه اجرای دستور hostname را در هشت تسک (task) نشان می‌دهد. دست‌کم هشت پردازنده به این کار (job) اختصاص داده خواهد شد (برابر با تعداد تسک‌ها) روی هر تعداد نودی که برای برآورده کردن این درخواست لازم باشد. خروجی هر تسک با شماره تسک مربوطه آغاز می‌شود. (ماشین «dev» در مثال زیر در مجموع دارای دو پردازنده به ازای هر نود است)
-
$ srun -n8 -l hostname 0: dev0 1: dev0 2: dev1 3: dev1 4: dev2 5: dev2 6: dev3 7: dev3
- مثال ۲:
- در مثال زیر، گزینه -r در دستور srun درون یک اسکریپت کار (job script) برای اجرای دو مرحله کار (job step) روی نودهای مجزا به کار رفته است. اسکریپت در این حالت به جای اجرا به عنوان یک کار دسته‌ای (batch job)، با استفاده از حالت تخصیص (allocate mode) اجرا می‌شود.
-
$ cat test.sh #!/bin/sh echo $SLURM_JOB_NODELIST srun -lN2 -r2 hostname srun -lN2 hostname $ salloc -N4 test.sh dev[7-10] 0: dev9 1: dev10 0: dev7 1: dev8
- مثال ۳:
- اسکریپت زیر دو مرحله کار را به‌صورت موازی در مجموعه‌ای از نودهای تخصیص‌یافته اجرا می‌کند.
-
$ cat test.sh #!/bin/bash srun -lN2 -n4 -r 2 sleep 60 & srun -lN2 -r 0 sleep 60 & sleep 1 squeue squeue -s wait $ salloc -N4 test.sh JOBID PARTITION NAME USER ST TIME NODES NODELIST 65641 batch test.sh grondo R 0:01 4 dev[7-10] STEPID PARTITION USER TIME NODELIST 65641.0 batch grondo 0:01 dev[7-8] 65641.1 batch grondo 0:01 dev[9-10]
- مثال ۴:
- این مثال نحوه اجرای یک کار ساده MPI را نشان می‌دهد. ما از srun برای ساخت فهرستی از ماشین‌ها (نودها) در قالب مورد نیاز mpirun استفاده می‌کنیم. در ادامه یک نمونه خط فرمان و اسکریپتی که باید اجرا شود آورده شده است.
-
$ cat test.sh #!/bin/sh MACHINEFILE="nodes.$SLURM_JOB_ID" # Generate Machinefile for mpi such that hosts are in the same # order as if run via srun # srun -l /bin/hostname | sort -n | awk '{print $2}' > $MACHINEFILE # Run using generated Machine file: mpirun -np $SLURM_NTASKS -machinefile $MACHINEFILE mpi-app rm $MACHINEFILE $ salloc -N2 -n4 test.sh
- مثال ۵:
- این مثال ساده اجرای کارهای مختلف روی نودهای متفاوت را در یک دستور srun یکسان نشان می‌دهد. شما می‌توانید این کار را برای هر تعداد نود یا هر تعداد کار انجام دهید. فایل‌های اجرایی روی نودهایی قرار می‌گیرند که توسط متغیر محیطی SLURM_NODEID مشخص شده‌اند؛ این مقادیر از 0 آغاز شده و تا عدد مشخص‌شده در خط فرمان srun ادامه می‌یابند.
-
$ cat test.sh case $SLURM_NODEID in 0) echo "I am running on " hostname ;; 1) hostname echo "is where I am running" ;; esac $ srun -N2 test.sh dev0 is where I am running I am running on dev1
- مثال ۶:
- این مثال نحوه استفاده از گزینه‌های چند‌هسته‌ای (multi-core) را برای کنترل چینش تسک‌ها نشان می‌دهد. ما درخواست می‌کنیم که چهار سوکت به ازای هر نود و دو هسته به ازای هر سوکت به این کار اختصاص یابد.
-
$ srun -N2 -B 4-4:2-2 a.out
- مثال ۷:
- این مثال اسکریپتی را نشان می‌دهد که در آن از Slurm برای مدیریت منابع یک کار استفاده شده است؛ بدین صورت که با در دسترس قرار گرفتن پردازنده‌ها برای استفاده اختصاصی، مراحل مختلف کار به ترتیب اجرا می‌شوند.
-
$ cat my.script #!/bin/bash srun -n4 prog1 & srun -n3 prog2 & srun -n1 prog3 & srun -n1 prog4 & wait
- مثال ۸:
- این مثال نحوه اجرای برنامه‌ای به نام «server» با ۱ تسک، ۸ پردازنده (CPU) و ۱۶ گیبی‌بایت (GiB) حافظه (۲ GiB به ازای هر پردازنده) را به همراه برنامه دیگری به نام «client» با ۱۶ تسک، ۱ پردازنده به ازای هر تسک (پیش‌فرض) و ۱ GiB حافظه به ازای هر تسک نشان می‌دهد.
-
$ srun -n1 -c8 --mem-per-cpu=2gb server : -n16 --mem-per-cpu=1gb client
- مثال ۹:
- این مثال تفاوت رفتار پرچم‌های --exclusive و --overlap را در دستور srun هنگام اجرا از داخل یک تخصیص کار (job allocation) نشان می‌دهد. پرچم --overlap به هر دو مرحله اجازه می‌دهد هم‌زمان آغاز شوند. در مقابل، پرچم --exclusive باعث می‌شود مرحله دوم تا پایان یافتن مرحله نخست منتظر بماند.
-
$ salloc -n1 salloc: Granted job allocation 9553 salloc: Waiting for resource configuration salloc: Nodes node01 are ready for job $ date +%T; srun -n1 --overlap -l sleep 3 & $ srun -n1 --overlap -l date +%T & 14:36:04 [1] 144341 [2] 144342 0: 14:36:04 [2]+ Done srun -n1 --overlap -l date +%T [1]+ Done srun -n1 --overlap -l sleep 3 $ date +%T; srun -n1 --exclusive -l sleep 3 & $ srun -n1 --exclusive -l date +%T & 14:36:17 [1] 144429 [2] 144430 srun: Job 9553 step creation temporarily disabled, retrying (Requested nodes are busy) srun: Step created for job 9553 0: 14:36:20 [1]- Done srun -n1 --exclusive -l sleep 3 [2]+ Done srun -n1 --exclusive -l date +%T مثال ۱۰: این مثال نشان می‌دهد چگونه کارهایی که به‌طور یکنواخت میان چندین گره تقسیم نشده‌اند، می‌توانند با مشکل عدم توانایی تسک‌ها در اجرا مواجه شوند، در حالی که پردازنده‌های آزاد کافی برای اجرای آن تسک روی یک گره منفرد وجود دارد. این مثال کاری را نشان می‌دهد که ۲ پردازنده روی یک گره و ۲۴ پردازنده روی گره دیگر به آن تخصیص یافته است.
-
$ echo $SLURM_NODELIST; echo $SLURM_JOB_CPUS_PER_NODE node[01-02] 2,24
اگر تسکی آغاز شود که پردازنده‌های گرهِ دارای پردازنده‌های کمتر را اشغال کند، آنگاه تسک بعدی که باید قادر به اجرا روی گره دیگر باشد، آغاز نخواهد شد؛ زیرا نیازمندی تعداد گره‌ها را از تخصیص کار به ارث می‌برد. گام کار تا زمانی که نخستین گام کار کامل شود یا لغو گردد، در وضعیت تعلیق (pending) باقی خواهد ماند.
$ srun -n4 --exact sleep 1800 & [1] 151837 $ srun -n2 --exact hostname ^Csrun: Cancelled pending job step with signal 2 srun: error: Unable to create step for job 2677: Job/step already completing or completed
اگر گام کار با درخواست صریح یک گره منفرد آغاز شود، قادر به اجرا خواهد بود.
$ srun -n2 -N1 --exact hostname node02 node02
این رفتار را می‌توان با افزودن SelectTypeParameters=CR_Pack_Nodes به فایل slurm.conf تغییر داد. منطق انباشتن گره‌ها به گام‌های کار اجازه می‌دهد بدون نیاز به درخواست صریح یک گره، روی یک گره منفرد آغاز شوند.
- مثال ۱۱:
- این مثال
نشان
می‌دهد که
افزودن
پرچم --exclusive به
درخواست‌های
تخصیص کار
می‌تواند
بسته به
اینکه آیا
تعداد
مشخصی تسک
را نیز
درخواست
کرده‌اید
یا خیر،
نتایج
متفاوتی در
پی داشته
باشد.
درخواست دسترسی انحصاری (exclusive) بدون نیازمندی‌های اضافه، به فرایند اجازه می‌دهد به تمام پردازنده‌های گرهِ تخصیص‌یافته دسترسی داشته باشد.
$ srun -l --exclusive bash -c 'grep Cpus_allowed_list /proc/self/status' 0: Cpus_allowed_list: 0-23
افزودن درخواستی برای تعداد مشخصی تسک، باعث می‌شود هر تسک تنها به یک پردازنده دسترسی داشته باشد.
$ srun -l --exclusive -n2 bash -c 'grep Cpus_allowed_list /proc/self/status' 0: Cpus_allowed_list: 0 1: Cpus_allowed_list: 12
اگر می‌خواهید به تسک‌ها امکان دسترسی به بیش از یک پردازنده را بدهید، می‌توانید تعداد پردازنده‌ها به ازای هر تسک را مشخص کنید.
$ srun -l --exclusive -n2 --cpus-per-task=12 bash -c 'grep Cpus_allowed_list /proc/self/status' 0: Cpus_allowed_list: 0-5,12-17 1: Cpus_allowed_list: 6-11,18-23
کپی‌رایت و تکثیر (COPYING)
Copyright (C) 2006-2007 The Regents of the University of
California. Produced at Lawrence Livermore National Laboratory (cf,
DISCLAIMER).
Copyright (C) 2008-2010 Lawrence Livermore National Security.
Copyright (C) 2010-2022 SchedMD LLC.
این فایل بخشی از Slurm است؛ یک برنامه مدیریت منابع. برای جزئیات بیشتر، https://slurm.schedmd.com را ببینید.
نرم‌افزار Slurm یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط «پروانه عمومی همگانی گنو» (GNU General Public License) که توسط بنیاد نرم‌افزارهای آزاد منتشر شده است، چه نسخه ۲ پروانه و یا (به انتخاب خودتان) هر نسخه بالاتری، بازتوزیع کرده و/یا تغییر دهید.
نرم‌افزار Slurm به این امید توزیع شده است که سودمند باشد، اما بدون هرگونه ضمانت؛ حتی بدون ضمانت ضمنی «قابل فروش بودن» یا «مناسب بودن برای یک هدف خاص». برای جزئیات بیشتر، «پروانه عمومی همگانی گنو» را ببینید..SH "همچنین ببینید (SEE ALSO)" salloc(1), sattach(1), sbatch(1), sbcast(1), scancel(1), scontrol(1), squeue(1), slurm.conf(5), sched_setaffinity (2), numa (3) getrlimit (2)
| Slurm Commands | Slurm 26.05 |