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 با کار را کاهش می‌دهد).
مقادیر کوچک‌تر (غیر صفر) تأثیر بیشتری بر عملکرد کار دارند، اما مقدار ۳۰ ثانیه بعید است برای برنامه‌هایی با کمتر از 10,000 وظیفه محسوس باشد.

نکاتی دربارهٔ مشخصات تاریخ/زمان:
- اگرچه فیلد 'seconds' (ثانیه) در قالب زمانی HH:MM:SS توسط کد مجاز دانسته شده است، اما توجه داشته باشید که زمان بررسی (poll time) زمان‌بند Slurm آن‌قدر دقیق نیست که اعزام کار را در همان ثانیهٔ دقیق تضمین کند. این کار در بررسی بعدی پس از زمان مشخص‌شده واجد شرایط شروع خواهد بود. بازهٔ دقیق بررسی به زمان‌بند Slurm بستگی دارد (برای نمونه، ۶۰ ثانیه در sched/builtin پیش‌فرض).
- اگر زمانی (HH:MM:SS) مشخص نشود، مقدار پیش‌فرض (00:00:00) است.
- اگر تاریخی بدون سال مشخص شود (مانند MM/DD)، سال جاری فرض می‌شود؛ مگر اینکه ترکیب MM/DD و HH:MM:SS برای آن سال گذشته باشد، که در این صورت سال بعد استفاده خواهد شد.

نام تکی (Single Name)

تنها گره‌هایی که دارای ویژگی مشخص‌شده باشند استفاده خواهند شد. برای نمونه، --constraint="intel"

تعداد گره (Node Count)

یک درخواست می‌تواند با افزودن یک ستاره و تعداد پس از نام ویژگی، تعداد گره‌های مورد نیاز با یک ویژگی خاص را مشخص کند. برای نمونه، --nodes=16 --constraint="graphics*4" نشان می‌دهد که کار به ۱۶ گره نیاز دارد و حداقل چهار گره از آن گره‌ها باید دارای ویژگی «graphics» باشند. اگر بیش از یک ویژگی درخواست شود و از شمارش گره‌ها استفاده شود، درخواست باید داخل کروشه قرار گیرد.

نکته: این گزینه توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شود. به جای آن می‌توان از کارهای ناهمگن (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]" ممکن است برای مشخص کردن این استفاده شود که تمام گره‌ها باید روی یک رَک واحد از خوشه تخصیص داده شوند، اما از هر یک از آن چهار رک می‌توان استفاده کرد.

تعداد چندگانه (Multiple Counts)

تعداد مشخصی از منابع چندگانه را می‌توان با استفاده از عملگر AND و قرار دادن گزینه‌ها داخل کروشه مشخص کرد. برای نمونه، --constraint="[rack1*2&rack2*4]" ممکن است برای مشخص کردن این استفاده شود که دو گره باید از گره‌های دارای ویژگی «rack1» و چهار گره از گره‌های دارای ویژگی «rack2» تخصیص داده شوند.

نکته: این گزینه توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شود.

نکته: تعداد چندگانه (Multiple Counts) می‌تواند باعث شود کارها با چیدمان شبکه‌ای غیربهینه تخصیص یابند.

کروشه‌ها (Brackets)

کروشه‌ها را می‌توان برای نشان دادن این استفاده کرد که شما به دنبال مجموعه‌ای از گره‌ها با نیازمندی‌های متفاوتی هستید که درون کروشه قرار دارند. برای نمونه، --constraint="[(rack1|rack2)*1&(rack3)*2]" یک گره با یکی از ویژگی‌های «rack1» یا «rack2» و دو گره با ویژگی «rack3» برای شما فراهم می‌کند. اگر بیش از یک ویژگی درخواست شود و از شمارش گره‌ها استفاده شود، درخواست باید داخل کروشه احاطه شود.

نکته: کروشه‌ها تنها برای نحو Multiple Counts و Matching OR اختصاص یافته‌اند. عملگرهای AND نیازمند شمارش برای هر ویژگی درون کروشه هستند (یعنی «[quad*2&hemi*1]»). سامانه Slurm تنها یک مجموعه از محدودیت‌های درون کروشه را برای هر کار مجاز می‌داند.

نکته: کروشه‌ها توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شوند. Matching 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 درون پرانتز نباید با پلاگین KNL NodeFeatures استفاده شود، اما توسط پلاگین helpers NodeFeatures پشتیبانی می‌شود.

after:job_id[[+time][:jobid[+time]...]]

پس از شروع یا لغو کارهای مشخص‌شده و سپری شدن زمان 'time' به دقیقه از شروع یا لغو کار، این کار می‌تواند اجرای خود را آغاز کند. اگر مقداری برای 'time' داده نشود، هیچ تاخیری پس از شروع یا لغو اعمال نمی‌شود.

afterany:job_id[:jobid...]

این کار می‌تواند پس از خاتمه یافتن کارهای مشخص‌شده، اجرای خود را آغاز کند. این نوع، وابستگی پیش‌فرض است.

afterburstbuffer:job_id[:jobid...]

این کار می‌تواند پس از خاتمهٔ کارهای مشخص‌شده و تکمیل هرگونه عملیات مرتبط با انتقال دادهٔ خروجیِ بافر انفجاری (burst buffer stage out)، اجرای خود را آغاز کند.

aftercorr:job_id[:jobid...]

یک تسک (تکلیف) از این آرایه کار (job array) می‌تواند پس از اینکه شناسهٔ تسک متناظر در کار مشخص‌شده با موفقیت کامل شد (با کد خروج صفر به پایان رسید)، اجرای خود را آغاز کند. اگر کار مشخص‌شده یک آرایه نباشد، همانند afterok با آن رفتار می‌شود.

afternotok:job_id[:jobid...]

این کار می‌تواند پس از اینکه کارهای مشخص‌شده در یک وضعیت ناموفق (کد خروج غیرصفر، خرابی گره، اتمام مهلت زمانی، و غیره) خاتمه یافتند، اجرای خود را آغاز کند. این کار باید زمانی ارسال شود که کار مشخص‌شده همچنان فعال باشد، یا در بازهٔ MinJobAge ثانیه پس از پایان کار مشخص‌شده ارسال گردد. اگر شناسهٔ کار وابسته یافت نشود و در همان کلاستری باشد که کار در آن ارسال شده است، کار رد می‌شود. اگر شناسهٔ کار وابسته یافت نشود و در کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق (failed) علامت‌گذاری می‌گردد.

afterok:job_id[:jobid...]

این کار می‌تواند پس از اینکه کارهای مشخص‌شده با موفقیت اجرا شدند (با کد خروج صفر به پایان رسیدند)، اجرای خود را آغاز کند. این کار باید زمانی ارسال شود که کار مشخص‌شده همچنان فعال باشد، یا در بازهٔ MinJobAge ثانیه پس از پایان کار مشخص‌شده ارسال گردد. اگر شناسهٔ کار وابسته یافت نشود و در همان کلاستری باشد که کار در آن ارسال شده است، کار رد می‌شود. اگر شناسهٔ کار وابسته یافت نشود و در کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق (failed) علامت‌گذاری می‌گردد.

singleton

این کار می‌تواند پس از خاتمه یافتن هر کار اجراشدهٔ قبلی که دارای نام کار و کاربر یکسانی است، اجرای خود را آغاز کند. به عبارت دیگر، در هر مقطع زمانی تنها یک کار با آن نام و متعلق به آن کاربر می‌تواند در حال اجرا یا تعلیق باشد. در یک فدراسیون، وابستگی singleton باید در تمام کلاسترها برآورده شود مگر اینکه از DependencyParameters=disable_remote_singleton در slurm.conf استفاده شده باشد.

روش توزیع اول (توزیع تسک‌ها در سراسر گره‌ها):

*

از روش پیش‌فرض برای توزیع تسک‌ها روی گره‌ها (block) استفاده می‌کند. اگر یک افزونهٔ توپولوژی پیکربندی شده باشد و کاربر روش توزیعی را مشخص نکند، تسک‌ها به جای ترتیب نمایهٔ گره، بر اساس ترتیب توپولوژی توزیع می‌شوند. برای غیرفعال کردن این رفتار، به CR_NO_DIST_TOPO_BLOCK در SelectTypeParameters مراجعه کنید.

block

روش توزیع بلوکی (block) تسک‌ها را طوری روی یک گره توزیع می‌کند که تسک‌های متوالی یک گره را به اشتراک بگذارند. به عنوان مثال، تخصیص سه گره را در نظر بگیرید که هر یک دارای دو پردازنده هستند. یک درخواست توزیع بلوکی چهار تسکی، این تسک‌ها را طوری روی گره‌ها توزیع می‌کند که تسک‌های یک و دو روی گره اول، تسک سه روی گره دوم، و تسک چهار روی گره سوم قرار گیرند. اگر تعداد تسک‌ها از تعداد گره‌های تخصیص‌یافته فراتر رود، توزیع بلوکی رفتار پیش‌فرض خواهد بود.

cyclic

روش توزیع چرخشی (cyclic) تسک‌ها را طوری روی گره‌ها توزیع می‌کند که تسک‌های متوالی روی گره‌های متوالی توزیع شوند (به روش نوبت‌گردشی یا round-robin). به عنوان مثال، تخصیص سه گره را در نظر بگیرید که هر یک دارای دو پردازنده هستند. یک درخواست توزیع چرخشی چهار تسکی، تسک‌ها را طوری توزیع خواهد کرد که تسک‌های یک و چهار روی گره اول، تسک دو روی گره دوم، و تسک سه روی گره سوم قرار گیرند. توجه داشته باشید که اگر SelectType برابر با select/cons_tres باشد، ممکن است تعداد پردازنده‌های تخصیص‌یافته روی هر گره یکسان نباشد. توزیع تسک‌ها به صورت نوبت‌گردشی در میان تمام گره‌هایی خواهد بود که هنوز پردازنده‌هایی برای واگذاری به تسک‌ها دارند. اگر تعداد تسک‌ها بزرگ‌تر از تعداد گره‌های تخصیص‌یافته نباشد، توزیع چرخشی رفتار پیش‌فرض است.

plane

تسک‌ها در بلوک‌هایی به اندازهٔ <size> توزیع می‌شوند. اندازه باید مشخص شود یا اینکه متغیر SLURM_DIST_PLANESIZE مقداردهی شده باشد. تعداد تسک‌های توزیع‌شده روی هر گره همانند توزیع چرخشی است، اما شناسه‌های تسک (taskid) اختصاص‌یافته به هر گره به اندازهٔ plane بستگی دارد. مشخصات توزیع بیشتر را نمی‌توان با این گزینه ترکیب کرد. برای جزئیات بیشتر (شامل مثال‌ها و نمودارها)، لطفاً به https://slurm.schedmd.com/mc_support.html و https://slurm.schedmd.com/dist_plane.html مراجعه فرمایید.

arbitrary

روش توزیع دلخواه (arbitrary) فرایندها را به ترتیب بر اساس ترتیبی که در فایل مشخص‌شده توسط متغیر محیطی SLURM_HOSTFILE فهرست شده‌اند، تخصیص می‌دهد. اگر این متغیر تعریف شده باشد، بر هر روش مشخص‌شدهٔ دیگری اولویت خواهد داشت. در صورت عدم تنظیم، روش به طور پیش‌فرض به block برمی‌گردد. محتوای درون hostfile باید حداقل شامل تعداد میزبان‌های درخواست‌شده به صورت یک مورد در هر خط یا جداشده با ویرگول باشد. در صورت تعیین تعداد تسک (-n, --ntasks=<number>)، تسک‌های شما به ترتیب فایل روی گره‌ها مستقر خواهند شد.
نکته: گزینهٔ توزیع دلخواه تنها با روش تخصیص عمومی (generic) پشتیبانی می‌شود و با ویژگی‌هایی نظیر توپولوژی، CR_LLN، CR_Pack_Nodes یا pack_serial_at_end قابل استفاده نیست. هدف اصلی این گزینه کنترل نحوهٔ چیدمان تسک‌های یک مرحله از کار (job step) در یک تخصیص کار موجود برای دستور srun است.
نکته: اگر تعداد تسک‌ها مشخص شده و فهرستی از گره‌های درخواستی نیز ارائه شده باشد، در صورتی که تعداد گره‌های موجود در فهرست بیشتر از تعداد تسک‌ها باشد، تعداد گره‌های مورد استفاده از آن فهرست کاهش می‌یابد تا با تعداد تسک‌ها همخوانی پیدا کند..IP

روش توزیع دوم (توزیع پردازنده‌ها میان سوکت‌ها برای مقیدسازی):

*

استفاده از روش پیش‌فرض برای توزیع پردازنده‌ها میان سوکت‌ها (cyclic).

block

روش توزیع block پردازنده‌های تخصیص‌یافته را پیش از استفاده از سوکت متوالی بعدی، به‌صورت پیاپی از همان سوکت برای مقیدسازی به تسک‌ها توزیع می‌کند.

cyclic

روش توزیع cyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به یک تسک مشخص را به‌صورت پیاپی از همان سوکت، و برای تسک بعدی از سوکت متوالی بعدی، به شیوهٔ گردشی (round-robin) در میان سوکت‌ها توزیع می‌کند. برای تسک‌هایی که به بیش از یک پردازنده نیاز دارند، در صورت امکان تمام آن پردازنده‌ها روی یک سوکت واحد تخصیص داده خواهند شد.
نکته: در گره‌هایی که hyper-threading در آن‌ها فعال است، تسکی که کل هسته‌ها را درخواست نکرده باشد ممکن است میان سوکت‌ها توزیع شود. می‌توان با مشخص کردن --ntasks-per-core=1 از این امر جلوگیری کرد، که تسک‌ها را مجبور به تخصیص هسته‌های کامل می‌کند.

fcyclic

روش توزیع fcyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به تسک‌ها را از سوکت‌های متوالی به شیوهٔ گردشی (round-robin) در میان سوکت‌ها توزیع می‌کند. برای تسک‌هایی که به بیش از یک پردازنده نیاز دارند، هر یک از پردازنده‌ها به‌صورت چرخشی (cyclic) میان سوکت‌ها تخصیص می‌یابند.

روش توزیع سوم (توزیع پردازنده‌ها میان هسته‌ها برای مقیدسازی):

*

استفاده از روش پیش‌فرض برای توزیع پردازنده‌ها میان هسته‌ها (به ارث رسیده از روش توزیع دوم).

block

روش توزیع block پردازنده‌های تخصیص‌یافته را پیش از استفاده از هستهٔ متوالی بعدی، به‌صورت پیاپی از همان هسته برای مقیدسازی به تسک‌ها توزیع می‌کند.

cyclic

روش توزیع cyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به یک تسک مشخص را به‌صورت پیاپی از همان هسته، و برای تسک بعدی از هستهٔ متوالی بعدی، به شیوهٔ گردشی (round-robin) در میان هسته‌ها توزیع می‌کند.

fcyclic

روش توزیع fcyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به تسک‌ها را از هسته‌های متوالی به شیوهٔ گردشی (round-robin) در میان هسته‌ها توزیع می‌کند.

کنترل اختیاری برای توزیع تسک‌ها روی گره‌ها:

Pack

به‌جای توزیع یکنواخت تسک‌های یک مرحله از کار روی گره‌های تخصیص‌یافته، آن‌ها را تا حد امکان فشرده روی گره‌ها قرار می‌دهد. این گزینه تنها زمانی اعمال می‌شود که از روش توزیع تسک «block» استفاده شده باشد.

NoPack

به‌جای قرار دادن تسک‌های یک مرحله از کار به فشرده‌ترین شکل ممکن روی گره‌ها، آن‌ها را به‌طور یکنواخت توزیع می‌کند. این گزینهٔ کاربری بر پارامتر پیکربندی SelectTypeParameters CR_Pack_Nodes اولویت خواهد داشت.

--export=ALL

حالت پیش‌فرض در صورتی که --export مشخص نشده باشد. تمام متغیرهای محیطی کاربر بارگذاری خواهند شد (یا از محیط فراخواننده، یا در صورت مشخص بودن --get-user-env از یک محیط تمیز).

--export=NIL

تنها متغیرهای SLURM_* و متغیرهای گزینهٔ SPANK از محیط کاربر تعریف خواهند شد. کاربر باید از مسیر مطلق برای باینری اجرایی استفاده کند که محیط را تعریف خواهد کرد. کاربر نمی‌تواند با "NIL" متغیرهای محیطی صریحی را تعیین کند.

برخلاف NONE، مقدار NIL به‌طور خودکار محیط کاربر را با استفاده از سازوکار --get-user-env ایجاد نخواهد کرد.

--export=NONE

تنها متغیرهای SLURM_* و متغیرهای گزینهٔ SPANK از محیط کاربر تعریف خواهند شد. کاربر باید از مسیر مطلق برای باینری اجرایی استفاده کند که محیط را تعریف خواهد کرد. کاربر نمی‌تواند با "NONE" متغیرهای محیطی صریحی را تعیین کند. با این حال، Slurm سپس به‌طور ضمنی تلاش می‌کند تا محیط کاربر را روی گره‌ای که اسکریپت در حال اجرا روی آن است بارگذاری کند، گویی --get-user-env مشخص شده است.

این گزینه به‌ویژه برای کارهایی اهمیت دارد که روی یک کلاستر ارسال شده و روی کلاستر دیگری اجرا می‌شوند (مثلاً با مسیرهای متفاوت). جهت جلوگیری از به ارث بردن تنظیمات صدور متغیرهای محیطی (مانند "NONE") از دستور sbatch توسط مراحل کار، متغیر محیطی SLURM_EXPORT_ENV باید در اسکریپت کار روی "ALL" تنظیم شود.

--export=[ALL,]<environment_variables>

تمام متغیرهای محیطی SLURM_* و گزینه‌های SPANK را به همراه متغیرهای مشخص‌شده به‌طور صریح صادر می‌کند. نام چند متغیر محیطی باید با کاما از یکدیگر جدا شوند. نام متغیرهای محیطی را می‌توان برای انتقال مقدار فعلی مشخص کرد (مانند "--export=EDITOR") یا مقادیر خاصی را صادر کرد (مانند "--export=EDITOR=/bin/emacs"). اگر "ALL" تعیین شود، تمام متغیرهای محیطی کاربر بارگذاری شده و بر هر متغیر محیطی که به‌صراحت داده شده اولویت خواهند داشت.

نکته: حالت‌های NONE و [ALL,]<environment_variables> به‌طور ضمنی به گونه‌ای کار می‌کنند که گویی --get-user-env تعریف شده است. لطفاً برای پیامدهای این امر، بخش مربوط به آن را ببینید.

--export-file={<filename>|<fd>}

اگر عددی بین 3 و OPEN_MAX به عنوان آرگومان این گزینه مشخص شود، یک توصیف‌گر فایل (file descriptor) خواندنی در نظر گرفته می‌شود (STDIN و STDOUT به عنوان آرگومان‌های معتبر پشتیبانی نمی‌شوند). در غیر این صورت یک نام فایل در نظر گرفته می‌شود. متغیرهای محیطی تعریف‌شده در <filename> یا خوانده‌شده از <fd> را به محیط اجرای کار (job) صادر می‌کند. محتوا شامل یک یا چند تعریف متغیر محیطی به فرم NAME=value است که هر یک با یک نویسه تهی (null) از دیگری جدا شده‌اند. این امر امکان استفاده از نویسه‌های خاص را در تعاریف محیطی فراهم می‌کند.

--extra=<string>

یک رشته دلخواه که در صورت استفاده از فاصله یا برخی نویسه‌های خاص، باید در علامت‌های نقل‌قول تکی یا دوتایی محصور شود.

اگر SchedulerParameters=extra_constraints فعال باشد، این رشته برای فیلتر کردن گره‌ها بر اساس فیلد Extra در هر گره استفاده می‌شود.

-B, --extra-node-info=<sockets>[:cores[:threads]]

انتخاب گره را به گره‌هایی با دست‌کم تعداد مشخص‌شده از سوکت‌ها، هسته‌ها به ازای هر سوکت و/یا رشته‌ها (threads) به ازای هر هسته محدود می‌کند.
نکته: این گزینه‌ها اندازه تخصیص منبع را مشخص نمی‌کنند. هر مقدار مشخص‌شده به عنوان یک حداقل در نظر گرفته می‌شود. از یک ستاره (*) می‌توان به عنوان جای‌نگهدار بدون محدود کردن انتخاب گره برای آن نوع استفاده کرد. سطوح مجزا را می‌توان در صورت تمایل در گزینه‌های جداگانه نیز مشخص نمود:

--sockets-per-node=<sockets>
--cores-per-socket=<cores>
--threads-per-core=<threads>

اگر افزونه task/affinity فعال باشد، مشخص کردن تخصیص به این شیوه همچنین منجر به مقید شدن تسک‌های راه‌اندازی‌شده بعدی به threadها می‌شود، البته در صورتی که گزینه -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 مانعة‌الجمع است (نمی‌توانند هم‌زمان استفاده شوند).
نکته: این گزینه ممکن است به صورت ضمنی تعداد تسک‌ها را (در صورتی که -n مشخص نشده باشد) به صورت یک تسک به ازای هر رشته درخواستی تنظیم کند.

--get-user-env

این گزینه به sbatch می‌گوید که متغیرهای محیط ورود به سیستم (login environment) را برای کاربر مشخص‌شده در گزینه --uid بازیابی کند. متغیرهای محیطی با اجرای فرمانی مانند "su - <username> -c /usr/bin/env"; و تجزیه خروجی آن به دست می‌آیند. توجه داشته باشید که هر متغیر محیطی که از پیش در محیط sbatch تنظیم شده باشد، بر متغیرهای محیط ورود کاربر اولویت خواهد داشت. متغیرهای محیطی را که نمی‌خواهید به برنامه اجراشده منتقل شوند، پیش از فراخوانی sbatch پاک کنید. اگر بازیابی محیط کاربر با شکست مواجه شود یا مهلت زمانی آن به پایان برسد، کار لغو شده، مجدداً در صف قرار می‌گیرد و نگه داشته می‌شود (held).

نکته: استفاده صریح یا ضمنی از --get-user-env به توانایی ایجاد فضاهای نام (namespaces) برای PID و mount متکی است. اکیداً توصیه می‌شود بررسی کنید که قابلیت ایجاد فضای نام PID و mount فعال بوده و محدود نشده باشد (بررسی کنید که /proc/sys/user/max_[pid|mnt]_namespaces مقدار 0 نباشد). اگرچه این موارد برای عملکرد --get-user-env کاملاً اجباری نیستند، اما تضمین می‌کنند که پس از بازیابی محیط، هیچ فرآیند یتیمی (orphan process) باقی نماند.

--gid=<group>

اگر sbatch به عنوان کاربر ریشه (root) اجرا شود و از گزینه --gid استفاده شده باشد، کار با دسترسی‌های گروهیِ group ارسال (submit) می‌شود. group می‌تواند نام گروه یا شناسه عددی گروه باشد.
نکته: آرگومان --gid منسوخ شده است و در نسخه‌های آینده حذف خواهد شد.

--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 ثبت (log) شود. نمونه‌های استفاده شامل "--gpu-freq=medium,memory=high" و "--gpu-freq=450" است.

تعاریف پشتیبانی‌شده برای value:

-G, --gpus=[type:]<number>

تعداد کل GPUهای مورد نیاز برای کار را مشخص می‌کند. مشخص کردن نوع GPU به صورت اختیاری امکان‌پذیر است. برای مثال "--gpus=volta:3". همچنین به گزینه‌های --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 مراجعه کنید.

--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 تعداد آن منابع با مقدار پیش‌فرض 1 است. شمارنده می‌تواند پسوندی از "k" یا "K" (مضربی از 1024)، "m" یا "M" (مضربی از 1024 × 1024)، "g" یا "G" (مضربی از 1024 × 1024 × 1024)، "t" یا "T" (مضربی از 1024 × 1024 × 1024 × 1024)، "p" یا "P" (مضربی از 1024 × 1024 × 1024 × 1024 × 1024) داشته باشد. منابع مشخص‌شده در هر گره به کار تخصیص داده می‌شوند. منابع مصرفی عمومی موجود توسط مدیر سیستم قابل پیکربندی است. اگر آرگومان گزینه "help" باشد، فهرستی از منابع مصرفی عمومی موجود چاپ شده و دستور خارج می‌شود. نمونه‌های استفاده شامل "--gres=gpu:2"، "--gres=gpu:kepler:2" و "--gres=help" است.

نکته: این گزینه با --gpus-per-node مانعة‌الجمع است (نمی‌توانند هم‌زمان استفاده شوند)..IP

--gres-flags=<type>

گزینه‌های مقیدسازی وظیفه به منابع عمومی (GRES) را مشخص می‌کند.

-h, --help

اطلاعات راهنما را نمایش داده و خارج می‌شود.

--hint=<type>

وظایف را با توجه به رهنمودهای برنامه (application hints) مقید می‌کند.
نکته: این گزینه متضمن مقادیر خاصی برای برخی گزینه‌های مرتبط است، که مانع از استفادهٔ هم‌زمان آن با هر مقدار تعیین‌شده توسط کاربر برای --ntasks-per-core، --cores-per-socket، --sockets-per-node، --threads-per-core یا -B می‌شود. این گزینه‌های متعارض در صورت مشخص شدن به عنوان آرگومان‌های خط فرمان، بر --hint تقدم خواهند داشت و آن را بازنویسی می‌کنند. اگر یک گزینهٔ متعارض به عنوان متغیر محیطی تعیین شده باشد، --hint به عنوان آرگومان خط فرمان اولویت خواهد داشت.

-H, --hold

مشخص می‌کند که کار باید در وضعیت نگه‌داشته‌شده (held با اولویت صفر) ارسال شود. یک کار نگه‌داشته‌شده می‌تواند بعداً با استفاده از scontrol برای بازنشانی اولویتش آزاد شود (مانند «scontrol release <job_id>»).

--ignore-pbs

تمامی گزینه‌های «#PBS» و «#BSUB» مشخص‌شده در اسکریپت دسته‌ای (batch script) را نادیده می‌گیرد.

-i, --input=<filename_pattern>

به Slurm دستور می‌دهد تا ورودی استاندارد اسکریپت دسته‌ای را مستقیماً به نام فایل مشخص‌شده در «filename pattern» متصل کند.

به‌طور پیش‌فرض، «/dev/null» روی ورودی استاندارد اسکریپت دسته‌ای باز است و خروجی استاندارد و خطای استاندارد هر دو به فایلی با نام «slurm-%j.out» هدایت می‌شوند که در آن «%j» با شمارهٔ تخصیص کار جایگزین می‌شود، همان‌طور که در ادامه در بخش filename pattern شرح داده شده است.

-J, --job-name=<jobname>

نامی را برای تخصیص کار مشخص می‌کند. نام تعیین‌شده هنگام استعلام کارهای در حال اجرا در سیستم، در کنار شمارهٔ شناسهٔ کار (job ID) نمایش داده خواهد شد. مقدار پیش‌فرض، نام اسکریپت دسته‌ای است یا در صورتی که اسکریپت از ورودی استاندارد sbatch خوانده شود، صرفاً «sbatch» خواهد بود.

--kill-on-invalid-dep=<yes|no>

اگر کاری وابستگی نامعتبری داشته باشد و هرگز نتواند اجرا شود، این پارامتر به Slurm مشخص می‌کند که آن را خاتمه دهد یا خیر. وضعیت یک کار خاتمه‌یافته JOB_CANCELLED خواهد بود. اگر این گزینه مشخص نشود، رفتار سراسری سیستم اعمال می‌شود. به‌طور پیش‌فرض، کار با علت DependencyNeverSatisfied در حالت معلق (pending) باقی می‌ماند، یا اگر kill_invalid_depend در slurm.conf مشخص شده باشد، کار خاتمه می‌یابد.

-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)، درخواست مجوز فقط می‌تواند روی مؤلفهٔ نخست کار انجام شود؛ برای مثال «sbatch -L ansys:2 : script.sh».

نکته: اگر مجوزها در 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 (مرحله‌بندی خروجی و آزادسازی burst buffer کامل شود)، TIME_LIMIT، TIME_LIMIT_90 (رسیدن به ۹۰ درصد محدودیت زمانی)، TIME_LIMIT_80 (رسیدن به ۸۰ درصد محدودیت زمانی)، TIME_LIMIT_50 (رسیدن به ۵۰ درصد محدودیت زمانی) و ARRAY_TASKS (ارسال ایمیل برای هر وظیفه از آرایه). چندین مقدار type را می‌توان در یک فهرست جداشده با ویرگول مشخص کرد. مقدار NONE تمام اعلان‌های رویداد را سرکوب کرده و هر مقدار دیگر مشخص‌شده را نادیده می‌گیرد. به‌طور پیش‌فرض هیچ اعلان ایمیلی ارسال نمی‌شود. کاربری که باید مطلع شود با --mail-user مشخص می‌گردد.

مگر اینکه گزینهٔ ARRAY_TASKS مشخص شده باشد، اعلان‌های ایمیلی هنگام BEGIN، END، FAIL و REQUEUE کار، به کل آرایهٔ کاری (job array) اعمال می‌شوند نه اینکه برای هر وظیفه در آرایهٔ کاری ایمیل‌های جداگانه‌ای ایجاد کنند.

--mail-user=<user>

کاربری که اعلان ایمیلی تغییرات وضعیت را مطابق با تعریف --mail-type دریافت می‌کند. این مقدار می‌تواند یک نشانی ایمیل کامل یا یک نام کاربری باشد. اگر یک نام کاربری مشخص شود، مقدار MailDomain در slurm.conf برای ایجاد یک نشانی ایمیل به انتهای آن اضافه خواهد شد. مقدار پیش‌فرض، کاربر ارسال‌کننده است..IP

--mcs-label=<mcs>

تنها زمانی استفاده می‌شود که یک MCSPlugin سازگار فعال باشد. این پارامتر گروهی است که کاربر به آن تعلق دارد (mcs/group) یا یک رشته برچسب دلخواه (mcs/label). در هر دو حالت، به‌طور پیش‌فرض هیچ برچسبی اختصاص داده نخواهد شد. برای جزئیات بیشتر به مستندات MCS مراجعه کنید: https://slurm.schedmd.com/mcs.html

--mem=<size>[units]

حافظه واقعی مورد نیاز به ازای هر گره (node) را مشخص می‌کند. واحدهای پیش‌فرض مبی‌بایت (mebibytes) هستند. واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد. مقدار پیش‌فرض DefMemPerNode و حداکثر مقدار MaxMemPerNode است. در صورت پیکربندی، هر دو پارامتر را می‌توان با استفاده از دستور scontrol show config مشاهده کرد. این پارامتر عموماً زمانی استفاده می‌شود که کل گره‌ها به کارها اختصاص داده شوند (SelectType=select/linear). همچنین به --mem-per-cpu و --mem-per-gpu مراجعه کنید. گزینه‌های --mem، --mem-per-cpu و --mem-per-gpu مانعة‌الجمع هستند. اگر --mem، --mem-per-cpu یا --mem-per-gpu به‌عنوان آرگومان‌های خط فرمان مشخص شوند، بر متغیرهای محیطی اولویت خواهند داشت.

نکته: تعیین اندازه حافظه برابر با صفر به عنوان یک حالت خاص در نظر گرفته می‌شود و به کار اجازه دسترسی به تمام حافظه موجود در هر گره را می‌دهد.

نکته: حافظه مصرفی توسط هر فرایند slurmstepd در مجموع حافظه مصرفی کار محاسبه می‌شود. این حافظه معمولاً بین 20MiB تا 200MiB مصرف می‌کند، هرچند بسته به پیکربندی سیستم و پلاگین‌های بارگذاری‌شده می‌تواند متغیر باشد.

نکته: درخواست‌های حافظه به‌طور سخت‌گیرانه اعمال نخواهند شد مگر اینکه Slurm برای استفاده از یک مکانیزم اجباری پیکربندی شده باشد. برای جزئیات بیشتر به ConstrainRAMSpace در صفحه راهنمای cgroup.conf(5) و OverMemoryKill در صفحه راهنمای slurm.conf(5) مراجعه کنید.

--mem-bind=[{quiet|verbose},]<type>

اتصال (Bind) تسک‌ها به حافظه. تنها زمانی استفاده می‌شود که پلاگین task/affinity فعال بوده و توابع حافظه NUMA در دسترس باشند. توجه داشته باشید که تفکیک‌پذیری اتصال پردازنده و حافظه ممکن است در برخی معماری‌ها متفاوت باشد. برای مثال، اتصال پردازنده ممکن است در سطح هسته‌های درون یک پردازنده انجام شود در حالی که اتصال حافظه در سطح گره‌ها انجام خواهد شد، جایی که تعریف «گره‌ها» ممکن است از سیستمی به سیستم دیگر تفاوت داشته باشد. به‌طور پیش‌فرض هیچ اتصالی به حافظه انجام نمی‌شود؛ هر تسکی با استفاده از هر پردازنده‌ای می‌تواند از هر حافظه‌ای استفاده کند. این گزینه معمولاً برای اطمینان از اینکه هر تسک به نزدیک‌ترین حافظه به پردازنده تخصیص‌یافته‌اش متصل شده است به کار می‌رود. استفاده از هر نوعی غیر از "none" یا "local" توصیه نمی‌شود.

نکته: برای اینکه Slurm همیشه اتصال حافظه انتخاب‌شده را برای تمام دستورات اجرا شده در پوسته گزارش کند، می‌توانید با تنظیم مقدار متغیر محیطی SLURM_MEM_BIND روی "verbose"، حالت پرگو (verbose) را فعال کنید.

متغیرهای محیطی اطلاعاتی زیر هنگام استفاده از --mem-bind تنظیم می‌شوند:

SLURM_MEM_BIND_LIST
SLURM_MEM_BIND_PREFER
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_VERBOSE

برای شرح دقیق‌تر هر یک از متغیرهای SLURM_MEM_BIND* به بخش متغیرهای محیطی (ENVIRONMENT VARIABLES) مراجعه کنید.

گزینه‌های پشتیبانی‌شده عبارتند از:

--mem-per-cpu=<size>[units]

حداقل حافظه مورد نیاز به ازای هر پردازنده تخصیص‌یافته و قابل استفاده. واحدهای پیش‌فرض مبی‌بایت هستند. مقدار پیش‌فرض 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). اگر منابع بر اساس هسته (core)، سوکت (socket) یا کل گره‌ها تخصیص یابند، تعداد پردازنده‌های اختصاص‌یافته به یک کار ممکن است بیشتر از تعداد تسک‌ها باشد و مقدار --mem-per-cpu باید بر این اساس تنظیم شود. همچنین به --mem و --mem-per-gpu مراجعه کنید. گزینه‌های --mem، --mem-per-cpu و --mem-per-gpu مانعة‌الجمع هستند.

نکته: اگر مقدار نهایی حافظه درخواستی توسط یک کار، توسط هیچ‌یک از گره‌های پیکربندی‌شده در پارتیشن برآورده نشود، کار رد خواهد شد. این مسئله می‌تواند زمانی رخ دهد که --mem-per-cpu با گزینه --exclusive برای یک تخصیص کار استفاده شود و حاصل‌ضرب --mem-per-cpu در تعداد پردازنده‌های یک گره بیشتر از کل حافظه آن گره باشد.

نکته: این مورد برای پردازنده‌های تخصیص‌یافته قابل استفاده در یک تخصیص کار اعمال می‌شود. این نکته زمانی که بیش از یک ریسه (thread) به ازای هر هسته پیکربندی شده باشد حائز اهمیت است. اگر یک کار با استفاده از --threads-per-core ریسه‌های کمتری را نسبت به ریسه‌های موجود روی یک هسته درخواست کند (یا با --hint=nomultithread که به معنی --threads-per-core=1 است)، کار قادر به استفاده از آن ریسه‌های اضافی روی هسته نخواهد بود و آن ریسه‌ها در محاسبه حافظه به ازای پردازنده لحاظ نمی‌شوند. اما اگر کار به تمام ریسه‌های روی هسته دسترسی داشته باشد، آن ریسه‌ها در محاسبه حافظه به ازای پردازنده گنجانده خواهند شد، حتی اگر کار صراحتاً آن ریسه‌ها را درخواست نکرده باشد.

در مثال‌های زیر، هر هسته دارای دو ریسه است.

در این مثال نخست، دو تسک می‌توانند روی هایپرتریدهای مجزا در همان هسته اجرا شوند زیرا از --threads-per-core استفاده نشده است. تسک سوم از هر دو ریسه هسته دوم استفاده می‌کند. حافظه تخصیص‌یافته به ازای پردازنده شامل تمام ریسه‌ها می‌شود:

$ 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، به هر تسک یک هسته کامل اختصاص داده می‌شود اما تنها قادر به استفاده از یک ریسه در هر هسته است. پردازنده‌های تخصیص‌یافته شامل تمام ریسه‌ها در هر هسته می‌شوند. با این حال، حافظه تخصیص‌یافته به ازای پردازنده تنها شامل ریسه قابل استفاده در هر هسته است.

$ 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 تخصیص‌یافته.
واحدهای پیش‌فرض، مبی‌بایت (mebibytes) هستند.
واحدهای مختلف را می‌توان با استفاده از پسوند [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، محدودیت جدید به‌عنوان مقداری
به ازای هر گره (per-node)، در مقایسه با بیشترین تخصیص به ازای هر گره در سراسر
تمامی گره‌ها اعمال می‌شود.
این یک عملیات یک‌باره است: کاهش حداکثر یک بار در طول اجرای کار اعمال می‌شود.
در صورت صف‌بندی مجدد کار (requeue)، کاهش خودکار ممکن است دوباره راه‌اندازی شود.
این گزینه نیازمند پیکربندی SlurmctldParameters=enable_stepmgr و
JobAcctGatherType=jobacct_gather/cgroup است.

--mincpus=<n>

حداقل تعداد cpuها/پردازنده‌های منطقی به ازای هر گره را مشخص می‌کند.

--network=<type>

مشخص کردن اطلاعات مربوط به سوئیچ یا شبکه.
تفسیر type وابسته به سیستم است.
گزینهٔ network در سیستم‌های دارای شبکه‌های HPE Slingshot در دسترس است.
می‌توان از آن برای درخواست یک VNI کار (جهت استفاده برای ارتباط میان گام‌های
کاری در یک کار) استفاده کرد. همچنین می‌توان از آن برای بازنویسی منابع شبکهٔ
پیش‌فرضی که برای گام کاری تخصیص یافته است، استفاده نمود. می‌توان مقادیر متعدد
را در یک فهرست جداشده با کاما مشخص کرد.

منابعی که می‌توان درخواست کرد عبارتند از:

در سیستم‌هایی که با SwitchType=switch/nvidia_imex پیکربندی شده‌اند،
گزینه‌های زیر پشتیبانی می‌شوند:

--nice[=adjustment]

اجرای کار با یک اولویت زمان‌بندی تعدیل‌شده در Slurm. بدون مقدار تعدیل، اولویت
زمان‌بندی ۱۰۰ واحد کاهش می‌یابد. یک مقدار منفی برای nice اولویت را افزایش داده
و در غیر این صورت آن را کاهش می‌دهد. بازهٔ تعدیل +/- 2147483645 است.
تنها کاربران ممتاز می‌توانند تعدیل منفی تعیین کنند.
-k, --no-kill[=off]
در صورتی که یکی از گره‌های تخصیص‌یافته به کار با شکست مواجه شد (از کار افتاد)، کار را به‌طور خودکار خاتمه نده. در صورت خرابی یک گره، مسئولیت تحمل خطا بر عهده کاربر خواهد بود.
تخصیص کار باطل نخواهد شد، بنابراین کاربر می‌تواند گام‌های شغلی جدیدی را روی گره‌های باقی‌مانده در تخصیص خود اجرا کند.
این گزینه متغیر محیطی SLURM_NO_KILL را مقداردهی نمی‌کند.
بنابراین، هنگامی که یک گره از کار می‌افتد، گام‌های در حال اجرا روی آن گره متوقف خواهند شد، مگر اینکه متغیر محیطی SLURM_NO_KILL صراحتاً تنظیم شده باشد یا فراخوانی‌های srun در درون تخصیص کار صراحتاً --no-kill را درخواست کرده باشند.
آرگومان اختیاری "off" را مشخص کنید تا اثر متغیر محیطی SBATCH_NO_KILL غیرفعال شود.
به‌طور پیش‌فرض Slurm در صورتی که هر گره‌ای در محدوده گره‌های تخصیص‌یافته از کار بیفتد، کل تخصیص کار را خاتمه می‌دهد.

--no-requeue

مشخص می‌کند که کار دسته‌ای تحت هیچ شرایطی نباید مجدداً در صف قرار گیرد (یادداشت زیر را ببینید).
تنظیم این گزینه مانع از آن می‌شود که مدیران سیستم بتوانند کار را بازراه‌اندازی کنند (برای مثال، پس از یک زمان توقف برنامه‌ریزی‌شده)، آن را پس از خرابی گره بازیابی کنند، یا پس از پیش‌دستی (preemption) توسط یک کار با اولویت بالاتر، مجدداً در صف قرار دهند.
هنگامی که یک کار مجدداً در صف قرار می‌گیرد، اسکریپت دسته‌ای از ابتدا آغاز می‌شود.
همچنین گزینه --requeue را ببینید.
پارامتر پیکربندی JobRequeue رفتار پیش‌فرض را در کلاستر کنترل می‌کند.
نکته: در صورتی که ForceRequeueOnFail به‌عنوان گزینه‌ای برای پارامتر PrologFlags در slurm.conf تنظیم شده باشد، می‌تواند این تنظیم را لغو و بازنویسی کند.

-F, --nodefile=<node_file>

بسیار شبیه به --nodelist است، اما فهرست در فایلی با نام node file قرار دارد. نام‌های گره‌های فهرست می‌توانند در چندین خط در فایل نیز گسترش یابند. نام‌های تکراری گره‌ها در فایل نادیده گرفته خواهند شد.
ترتیب نام گره‌ها در فهرست مهم نیست؛ نام‌های گره‌ها توسط Slurm مرتب خواهند شد.

-w, --nodelist=<node_name_list>

درخواست فهرستی مشخص از گره‌ها.
کار شامل تا جای ممکن تعداد بیشتری از این گره‌ها بر اساس نیازمندی‌های منابع خواهد بود، و در صورت نیاز اجرای کار را برای دردسترس قرار گرفتن منابع به تاخیر می‌اندازد.
اگر حداقل تعداد گره یا پردازنده را بیشتر از مقداری مشخص کنید که فهرست گره‌های ارائه‌شده بتواند برآورده کند، منابع اضافی در صورت نیاز روی گره‌های دیگر تخصیص داده خواهد شد (مگر اینکه از --segment نیز استفاده شده باشد). برعکس، تعداد کمتر گره یا پردازنده ممکن است تنها به زیرمجموعه‌ای از فهرست گره‌های ارائه‌شده نیاز داشته باشد.
فهرست می‌تواند به صورت یک فهرست جداشده با کاما از گره‌ها، محدوده‌ای از گره‌ها (مثلاً node[1-5,7,...])، یا یک نام فایل مشخص شود.
اگر فهرست گره‌ها حاوی نویسه "/" باشد، یک نام فایل در نظر گرفته می‌شود.
نام‌های تکراری گره در فهرست نادیده گرفته خواهند شد.
ترتیب نام گره‌ها در فهرست مهم نیست؛ نام‌های گره‌ها توسط Slurm مرتب خواهند شد.

-N, --nodes=<minnodes>[-maxnodes]|<size_string>

درخواست می‌کند که حداقل minnodes گره به این کار تخصیص داده شود.
حداکثر تعداد گره نیز می‌تواند با maxnodes مشخص شود.
اگر فقط یک عدد مشخص شود، به عنوان هر دو مقدار حداقل و حداکثر تعداد گره استفاده می‌شود. تعداد گره می‌تواند به عنوان size_string نیز مشخص شود.
مشخصه size_string تعیین می‌کند که چه مقادیر گره‌ای باید استفاده شود.
مقادیر متعدد را می‌توان با استفاده از یک فهرست جداشده با کاما یا با یک تابع گام به وسیله پسوندی شامل دونقطه و مقادیر عددی با یک جداکننده "-" مشخص کرد.
برای مثال، "--nodes=1-15:4" معادل "--nodes=1,5,9,13" است.
محدودیت‌های گره در پارتیشن بر محدودیت‌های کار اولویت دارد.
اگر محدودیت‌های گره کار خارج از محدوده مجاز برای پارتیشن مرتبط با آن باشد، کار در وضعیت PENDING باقی خواهد ماند.
این امر امکان اجرای احتمالی در زمانی دیگر را که محدودیت پارتیشن تغییر کند، فراهم می‌سازد.
اگر محدودیت گره کار از تعداد گره‌های پیکربندی‌شده در پارتیشن تجاوز کند، کار رد خواهد شد.
توجه داشته باشید که متغیر محیطی SLURM_JOB_NUM_NODES بر روی تعداد گره‌هایی که در واقعیت به کار تخصیص یافته‌اند تنظیم خواهد شد. برای اطلاعات بیشتر بخش ENVIRONMENT VARIABLES  را ببینید. اگر -N مشخص نشده باشد، رفتار پیش‌فرض تخصیص گره‌های کافی برای برآورده کردن منابع درخواستیِ بیان‌شده توسط گزینه‌های مشخصه کار است، مانند -n، -c و --gpus.
به کار تا جای ممکن بیشترین تعداد گره در محدوده مشخص‌شده و بدون به تاخیر انداختن شروع کار تخصیص داده خواهد شد.
مشخصه تعداد گره می‌تواند شامل یک مقدار عددی و به دنبال آن پسوند "k" (ضرب مقدار عددی در ۱٬۰۲۴) یا "m" (ضرب مقدار عددی در ۱٬۰۴۸٬۵۷۶) باشد.
نکته: این گزینه نمی‌تواند همراه با توزیع اختیاری (arbitrary distribution) استفاده شود.

-n, --ntasks=<number>

دستور sbatch وظایف (تسک‌ها) را راه‌اندازی نمی‌کند، بلکه درخواست تخصیص منابع داده و یک اسکریپت دسته‌ای ارسال می‌کند. این گزینه به کنترل‌کننده Slurm اطلاع می‌دهد که گام‌های شغلی اجراشده در این تخصیص حداکثر number تسک را راه‌اندازی خواهند کرد و منابع کافی را فراهم کند.
مقدار پیش‌فرض یک تسک به ازای هر گره است، اما توجه داشته باشید که گزینه --cpus-per-task این پیش‌فرض را تغییر خواهد داد.

--ntasks-per-core=<ntasks>

درخواست می‌کند که حداکثر ntasks تسک روی هر هسته فراخوانی شود.
برای استفاده به همراه گزینه --ntasks در نظر گرفته شده است.
مرتبط با --ntasks-per-node است با این تفاوت که به جای سطح گره، در سطح هسته اعمال می‌شود. این گزینه توسط srun به ارث برده خواهد شد.
نرم‌افزار Slurm ممکن است برای رعایت این گزینه، پردازنده‌های بیشتری (cpus) نسبت به آنچه درخواست شده تخصیص دهد.
نکته: این گزینه هنگام استفاده از SelectType=select/linear پشتیبانی نمی‌شود. این مقدار نمی‌تواند بزرگتر از --threads-per-core باشد.

--ntasks-per-gpu=<ntasks>

درخواست می‌کند که به ازای هر GPU تعداد ntasks تسک فراخوانی شود.
این گزینه می‌تواند به دو روش کار کند: ۱) علاوه بر این --ntasks را مشخص کنید، که در این حالت یک مشخصه GPU بدون نوع به‌طور خودکار برای برآورده کردن --ntasks-per-gpu تعیین خواهد شد، یا ۲) GPUهای مورد نظر را (مثلاً از طریق --gpus یا --gres) بدون مشخص کردن --ntasks مشخص کنید، و تعداد کل تسک‌ها به‌طور خودکار تعیین خواهد شد.
تعداد CPUهای مورد نیاز در صورت لزوم به‌طور خودکار افزایش می‌یابد تا تعداد تسک‌های محاسبه‌شده فراهم شود.
این گزینه به‌طور ضمنی --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 مرتبط است، اما نیازی به دانستن تعداد واقعی cpus در هر گره ندارد. در برخی موارد، راحت‌تر است که بتوان درخواست کرد بیش از یک تعداد مشخص تسک روی هر گره فراخوانی نشود. نمونه‌هایی از این مورد عبارتند از ارسال یک برنامه ترکیبی MPI/OpenMP که در آن تنها یک "task/rank" از MPI باید به هر گره اختصاص داده شود در حالی که بخش OpenMP اجازه می‌یابد از تمام موازی‌سازی موجود در گره استفاده کند، یا ارسال یک کار منفرد آماده‌سازی/پاک‌سازی/پایش به هر گره از یک تخصیص موجود از پیش، به عنوان یک گام در یک اسکریپت کار بزرگتر.

--ntasks-per-socket=<ntasks>

درخواست می‌کند که حداکثر ntasks تسک روی هر سوکت فراخوانی شود.
برای استفاده به همراه گزینه --ntasks در نظر گرفته شده است.
مرتبط با --ntasks-per-node است با این تفاوت که به جای سطح گره، در سطح سوکت اعمال می‌شود.
نکته: این گزینه هنگام استفاده از SelectType=select/linear پشتیبانی نمی‌شود.

--oom-kill-step[={0|1}]

تعیین می‌کند که در صورت تشخیص یک رخداد OOM در هر تسک از یک گام، آیا کل گام خاتمه داده شود یا خیر. این گزینه تنظیم "OOMKillStep" در TaskPluginParam از slurm.conf را بازنویسی می‌کند. هنگامی که تنظیم نشده باشد، از مقدار slurm.conf استفاده خواهد کرد. هنگام تنظیم، مقدار "0" خاتمه کل گام را غیرفعال کرده و مقدار "1" آن را فعال می‌کند. این مورد برای کل تخصیص به جز گام خارجی (external step) اعمال می‌شود.
در صورتی که این گزینه بدون مقدار درج شود، مقدار پیش‌فرض "1" (فعال) است.

--open-mode={append|truncate}

باز کردن فایل‌های خروجی و خطا در حالت الحاق (append) یا بازنویسی (truncate) مطابق با مقدار مشخص‌شده.
مقدار پیش‌فرض توسط پارامتر پیکربندی سامانه JobFileAppend مشخص می‌شود.

-o, --output=<filename_pattern>

به Slurm دستور می‌دهد خروجی استاندارد اسکریپت دسته‌ای را مستقیماً به نام فایل مشخص‌شده در "filename pattern" متصل کند.
به‌طور پیش‌فرض، هر دو خروجی استاندارد و خطای استاندارد به همان فایل هدایت می‌شوند.
برای آرایه‌های کاری، نام فایل پیش‌فرض "slurm-%A_%a.out" است، "%A" با شناسه کار و "%a" با اندیس آرایه جایگزین می‌شود.
برای سایر کارها، نام فایل پیش‌فرض "slurm-%j.out" است، که در آن "%j" با شناسه کار جایگزین می‌شود.
برای گزینه‌های مشخص‌سازی نام فایل، بخش filename pattern را در زیر ببینید.
-O, --overcommit
تخصیص بیش از حد منابع (Overcommit).
هنگامی که بر یک تخصیص کار اعمال می‌شود (به‌استثنای کارهایی که درخواست دسترسی انحصاری به گره‌ها را دارند)، منابع به‌گونه‌ای تخصیص می‌یابند که گویی تنها یک تسک به ازای هر گره درخواست شده است. این بدان معناست که تعداد پردازنده‌های درخواست‌شده به ازای هر تسک (-c، --cpus-per-task) به‌جای ضرب شدن در تعداد تسک‌ها، به ازای هر گره تخصیص می‌یابد. گزینه‌هایی که برای تعیین تعداد تسک‌ها به ازای هر گره، سوکت، هسته و غیره استفاده می‌شوند، نادیده گرفته خواهند شد.
هنگامی که بر تخصیص‌های گام کار (دستور srun در هنگام اجرا درون یک تخصیص کار موجود) اعمال شود، این گزینه می‌تواند برای راه‌اندازی بیش از یک تسک به ازای هر پردازنده استفاده شود.
در حالت عادی، srun بیش از یک فرایند را به ازای هر پردازنده تخصیص نمی‌دهد.
با مشخص کردن --overcommit، شما صریحاً اجازه اجرای بیش از یک فرایند به ازای هر پردازنده را می‌دهید. با این حال، اجرای بیش از MAX_TASKS_PER_NODE تسک به ازای هر گره مجاز نیست. نکته: مقدار MAX_TASKS_PER_NODE در فایل slurm.h تعریف شده است و یک متغیر نیست، بلکه در زمان ساخت Slurm تنظیم می‌شود.

-s, --oversubscribe

تخصیص کار می‌تواند منابع را با سایر کارهای در حال اجرا به اشتراک مضاعف (over-subscribe) بگذارد.
منابعی که مشمول اشتراک مضاعف می‌شوند، بسته به پیکربندی می‌توانند گره‌ها، سوکت‌ها، هسته‌ها و/یا رشته‌های هایپرتردینگ (hyperthreads) باشند.
رفتار پیش‌فرض اشتراک مضاعف به پیکربندی سیستم بستگی دارد و گزینه OverSubscribe مربوط به پارتیشن نسبت به گزینه کار اولویت دارد.
این گزینه ممکن است منجر به این شود که تخصیص منابع سریع‌تر از زمانی که گزینه --oversubscribe تنظیم نشده انجام گیرد و امکان بهره‌وری بالاتری از سیستم را فراهم کند، اما عملکرد برنامه احتمالاً به دلیل رقابت بر سر منابع کاهش خواهد یافت.
همچنین گزینه --exclusive را ببینید.
نکته: این گزینه با --exclusive ناسازگار و مانعة‌الجمع است.

--parsable

تنها شماره شناسه کار و در صورت وجود، نام کلاستر را در خروجی نمایش می‌دهد.
مقادیر با یک نقطه‌ویرگول از یکدیگر جدا می‌شوند. خطاها همچنان نمایش داده خواهند شد.
توجه داشته باشید که --quiet شناسه کار را نیز همراه با سایر پیام‌های اطلاعاتی پنهان می‌کند.

-p, --partition=<partition_names>

درخواست یک پارتیشن خاص برای تخصیص منابع. اگر مشخص نشود، رفتار پیش‌فرض این است که به کنترلر Slurm اجازه داده می‌شود پارتیشن پیش‌فرضی را که توسط مدیر سیستم تعیین شده انتخاب کند. اگر کار بتواند از بیش از یک پارتیشن استفاده کند، نام آن‌ها را در یک فهرست جداشده با کاما مشخص کنید؛ پارتیشنی که زودترین زمان آغاز را ارائه دهد بدون در نظر گرفتن ترتیب نام پارتیشن‌ها استفاده خواهد شد (اگرچه پارتیشن‌های با اولویت بالاتر ابتدا در نظر گرفته می‌شوند).
هنگامی که کار آغاز شود، نام پارتیشن استفاده‌شده در ابتدای رشته پارتیشن در رکورد کار قرار خواهد گرفت.

--prefer=<list>

گره‌ها می‌توانند دارای ویژگی‌هایی (features) باشند که توسط مدیر Slurm به آن‌ها اختصاص داده شده است.
کاربران می‌توانند با استفاده از گزینه prefer مشخص کنند که کدام‌یک از این ویژگی‌ها برای کارشان مطلوب است اما الزامی نیست.
این گزینه مستقل از --constraint عمل کرده و در صورت امکان، هر آنچه در آنجا تنظیم شده را بازنویسی می‌کند.
هنگام زمان‌بندی، ویژگی‌های موجود در --prefer ابتدا بررسی می‌شوند. اگر مجموعه‌ای از گره‌ها با آن ویژگی‌ها در دسترس نباشد، سپس --constraint ارزیابی می‌شود.
برای اطلاعات بیشتر --constraint را ببینید؛ این گزینه به همان شیوه عمل می‌کند.

--priority=<value>

درخواست اولویت خاص برای کار.
ممکن است تابع محدودیت‌های خاص پیکربندی باشد.
value باید یک مقدار عددی یا "TOP" (برای بالاترین مقدار ممکن) باشد.
تنها اپراتورها و مدیران Slurm می‌توانند اولویت یک کار را تنظیم کنند.

--profile={all|none|<type>[,<type>...]}

جمع‌آوری جزئیات داده‌ها توسط افزونه acct_gather_profile را فعال می‌کند.
داده‌های تفصیلی معمولاً سری‌های زمانی هستند که بسته به افزونه پیکربندی‌شده، در یک فایل HDF5 برای کار یا در یک پایگاه داده InfluxDB ذخیره می‌شوند.

مقادیر معتبر type عبارتند از:

--propagate[=rlimit[,rlimit...]]

به کاربران اجازه می‌دهد مشخص کنند کدام‌یک از محدودیت‌های منابع قابل‌تغییر (نرم یا soft) به گره‌های محاسباتی انتقال یابند (propagate شوند) و بر کارهای آن‌ها اعمال گردند. اگر هیچ
rlimit مشخص نشود، تمام محدودیت‌های منابع انتقال خواهند یافت.
نام‌های rlimit زیر توسط Slurm پشتیبانی می‌شوند (اگرچه ممکن است برخی
گزینه‌ها در برخی سیستم‌ها پشتیبانی نشوند):

-q, --qos=<qos>

درخواست کیفیت خدمات (QOS) برای کار، یا یک فهرست جداشده با کاما از QOSها.
در صورت درخواست یک فهرست، مرتب‌سازی بر اساس اولویت QOSهای مشخص‌شده انجام می‌شود و
اولین مورد بالاترین اولویت را خواهد داشت.
مقادیر QOS می‌توانند
برای هر انتساب کاربر/کلاستر/حساب در پایگاه داده Slurm تعریف شوند.
کاربران به مجموعه qosهای تعریف‌شده برای انتساب خود محدود خواهند بود هرگاه
پارامتر پیکربندی Slurm، یعنی AccountingStorageEnforce، مقدار
"qos" را در تعریف خود داشته باشد..IP

-Q, --quiet

جلوگیری از نمایش پیام‌های اطلاعاتی sbatch مانند شناسه کار (Job ID). تنها خطاها همچنان نمایش داده خواهند شد.

--reboot

راه‌اندازی مجدد (reboot) اجباری گره‌های تخصیص‌یافته پیش از شروع کار.
این قابلیت تنها با برخی از پیکربندی‌های سیستم پشتیبانی می‌شود و در غیر این صورت بدون هیچ هشداری نادیده گرفته خواهد شد. تنها کاربر ریشه (root)، SlurmUser یا مدیران سیستم می‌توانند گره‌ها را بازنشانی کنند.

--requeue[=expedite]

مشخص می‌کند که کار دسته‌ای (batch job) باید واجد شرایط قرارگیری مجدد در صف (requeuing) باشد.
کار ممکن است به‌طور صریح توسط مدیر سیستم، پس از خرابی گره، یا هنگام پیش‌دستی (preemption) توسط یک کار با اولویت بالاتر، مجدداً در صف قرار گیرد.
هنگامی که یک کار دوباره در صف قرار می‌گیرد، اسکریپت دسته‌ای از ابتدای آن با همان شناسه کار آغاز می‌شود. همچنین گزینه --no-requeue را ببینید.
پارامتر پیکربندی JobRequeue رفتار پیش‌فرض را روی کلاستر کنترل می‌کند.
پارامتر اختیاری expedite درخواست می‌کند که کار بلافاصله دوباره واجد شرایط شروع باشد و با بالاترین اولویت ممکن زمان‌بندی شود.
این اتفاق تنها در صورتی رخ خواهد داد که قرارگیری مجدد سریع در صف به‌صورت سراسری با SlurmctldParameters=enable_expedited_requeue در slurm.conf مجاز شده باشد.

--reservation=<reservation_names>

تخصیص منابع برای کار از رزرو (reservation) نام‌برده‌شده. اگر کار بتواند از بیش از یک رزرو استفاده کند، نام‌های آن‌ها را در یک فهرست جداشده با کاما مشخص کنید؛ رزروی که زودترین زمان آغاز را ارائه دهد انتخاب می‌شود. هر رزرو به ترتیبی که درخواست شده است بررسی خواهد شد.
تمام رزروها در طول عمر کار در 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 استفاده می‌شود.
این گزینه تنها زمانی قابل استفاده است که مدیریت گام slurmstepd فعال باشد.
گزینه --stepmgr را ببینید.

--segment=<segment_size>

هنگامی که از توپولوژی بلوکی یا حلقه‌ای استفاده می‌شود، این گزینه اندازه بخش‌هایی (segments) را که برای ایجاد تخصیص کار استفاده می‌شوند، تعیین می‌کند.
هیچ الزامی وجود نخواهد داشت که تمام بخش‌های یک کار درون همان بلوک سطح بالاتر قرار گیرند.
نکته: اگر تعداد گره‌های درخواست‌شده (--nodes) بزرگتر از اندازه بخش درخواستی باشد، باید بر اندازه بخش بخش‌پذیر باشد.
اگر تمام گره‌ها درون یک بخش جای گیرند، این گزینه هیچ اثری نخواهد داشت.
نکته: هنگام استفاده همراه با --nodelist=<node_list>:
تعداد گره‌های درخواستی باید کمتر یا مساوی تعداد کل گره‌های یکتای مشخص‌شده در آرگومان --nodelist باشد.
درخواست گره‌های بیشتر از گره‌های یکتای موجود در --nodelist ارائه‌شده، منجر به رد کار توسط slurmctld خواهد شد.

--signal=[{R|B}:]<sig_num>[@sig_time]

هنگامی که کار در فاصله sig_time ثانیه‌ای تا زمان پایان خود قرار دارد، سیگنال sig_num به آن ارسال می‌شود.
به دلیل دقت تفکیک رسیدگی به رویدادها توسط Slurm، ممکن است سیگنال تا ۶۰ ثانیه زودتر از زمان مشخص‌شده ارسال شود.
sig_num می‌تواند شماره سیگنال یا نام آن باشد (مانند "10" یا "USR1").
sig_time باید مقداری صحیح بین 0 تا 65535 داشته باشد.
به‌طور پیش‌فرض، پیش از زمان پایان کار هیچ سیگنالی ارسال نمی‌شود.
اگر sig_num بدون هیچ sig_time مشخص شود، زمان پیش‌فرض ۶۰ ثانیه خواهد بود.
از گزینه "B:" برای ارسال سیگنال فقط به شل دسته‌ای (batch shell) استفاده کنید؛ به هیچ‌یک از فرایندهای دیگر سیگنال ارسال نخواهد شد. به‌طور پیش‌فرض، به تمام گام‌های کار سیگنال ارسال می‌شود، اما به خود شل دسته‌ای ارسال نمی‌شود.
از گزینه "R:" استفاده کنید تا به این کار اجازه دهید با یک رزرو که دارای MaxStartDelay تنظیم‌شده است هم‌پوشانی داشته باشد. اگر گزینه "R:" استفاده شود، پیش‌دستی (preemption) باید روی سیستم فعال باشد، و اگر کار پیش‌دستی شود، در صورت مجاز بودن دوباره در صف قرار می‌گیرد وگرنه لغو خواهد شد.
برای اینکه سیگنال در زمان پیش‌دستی ارسال شود، send_user_signal در PreemptParameter را ببینید.

--sockets-per-node=<sockets>

محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شده سوکت. در صورت فعال بودن پلاگین task/affinity، اطلاعات بیشتر را زیر گزینه -B در بالا ببینید.
نکته: این گزینه ممکن است در صورت عدم تعیین -n، تعداد وظایف (tasks) را به‌طور ضمنی برابر با یک وظیفه به ازای هر نخ درخواستی قرار دهد.

--spread-job

پخش کردن تخصیص کار روی بیشترین تعداد ممکن از گره‌ها و تلاش برای توزیع یکنواخت وظایف میان گره‌های تخصیص‌یافته.
این گزینه پلاگین topology/tree را غیرفعال می‌کند.

--spread-segments

جلوگیری از تخصیص گره‌های درون یک بلوک پایه به بخش‌های مجزا درون همان بلوک.
نکته: این گزینه تنها با پلاگین topology/block کار خواهد کرد.

--stepmgr

فعال کردن مدیریت گام slurmstepd به ازای هر کار در صورتی که در سراسر سیستم فعال نباشد.
این گزینه امکان مدیریت گام‌های کار را توسط یک extern slurmstepd منفرد مرتبط با کار فراهم می‌کند. این قابلیت برای کارهایی که گام‌های زیادی را درون تخصیص‌های خود ارسال می‌کنند مفید است. PrologFlags=contain باید تنظیم شده باشد.

--switches=<count>[@max-time]

هنگامی که از توپولوژی درختی استفاده می‌شود، این گزینه حداکثر تعداد سوئیچ‌های برگ (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 است.

--test-only

اعتبارسنجی اسکریپت دسته‌ای و بازگرداندن تخمینی از زمانی که کار با توجه به صف فعلی کارها و تمام آرگومان‌های دیگر مشخص‌کننده نیازمندی‌های کار زمان‌بندی می‌شود. در عمل هیچ کاری ارسال نمی‌شود.

--thread-spec=<num>

تعداد نخ‌های اختصاصی به ازای هر گره که توسط کار برای عملیات سیستم رزرو شده و توسط برنامه استفاده نمی‌شوند. برنامه از این نخ‌ها استفاده نخواهد کرد، اما هزینه تخصیص آن‌ها محاسبه خواهد شد.
این گزینه نمی‌تواند همراه با گزینه --core-spec استفاده شود.
نکته: تنظیم صریح مقدار نخ‌های اختصاصی یک کار، به‌طور ضمنی گزینه --exclusive آن را فعال کرده و کل گره‌ها را برای کار رزرو می‌کند.

--threads-per-core=<threads>

محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شده نخ به ازای هر هسته. در چیدمان وظایف، از حداکثر تعداد نخ‌های مشخص‌شده در هر هسته استفاده کنید. نکته: واژه «نخ‌ها» به تعداد واحدهای پردازشی روی هر هسته اشاره دارد، نه تعداد وظایف برنامه‌ای که قرار است در هر هسته اجرا شوند.
در صورت فعال بودن پلاگین task/affinity، اطلاعات بیشتر را زیر گزینه -B در بالا ببینید.
نکته: این گزینه ممکن است در صورت عدم تعیین -n، تعداد وظایف را به‌طور ضمنی برابر با یک وظیفه به ازای هر نخ درخواستی قرار دهد.

-t, --time=<time>

تعیین محدودیت برای زمان کل اجرای تخصیص کار. اگر محدودیت زمانی درخواست‌شده از محدودیت زمانی پارتیشن فراتر رود، کار در وضعیت PENDING باقی خواهد ماند (احتمالاً برای همیشه). محدودیت زمانی پیش‌فرض، محدودیت زمانی پیش‌فرض پارتیشن است. هنگامی که محدودیت زمانی فرا برسد، به هر وظیفه در هر گام کار ابتدا SIGTERM و سپس SIGKILL ارسال می‌شود. فاصله زمانی میان این سیگنال‌ها با پارامتر پیکربندی Slurm یعنی KillWait مشخص می‌شود. پارامتر پیکربندی OverTimeLimit ممکن است به کار اجازه دهد طولانی‌تر از زمان زمان‌بندی‌شده اجرا شود. دقت زمان یک دقیقه است و مقادیر ثانیه به بالا (به دقیقه بعدی) گرد می‌شوند.
محدودیت زمانی صفر درخواست می‌کند که هیچ محدودیت زمانی اعمال نشود. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند..IP

--time-min=<time>

تعیین حداقل محدودیت زمانی برای تخصیص منبع کار.
در صورت مشخص شدن، چنانچه کاهش محدودیت زمانی کار امکان شروع اجرای آن را زودتر
از حالت معمول فراهم کند، ممکن است محدودیت --time آن تا مقداری نه کمتر
از --time-min کاهش یابد.
پس از تخصیص منابع به کار، محدودیت زمانی کار تغییر نخواهد کرد.
این کار توسط الگوریتم زمان‌بندی بازپردازی (backfill scheduling) انجام می‌شود تا
منابعی را تخصیص دهد که در غیر این صورت برای کارهای با اولویت بالاتر رزرو می‌شدند.
قالب‌های زمانی پذیرفته‌شده شامل «minutes»، «minutes:seconds»،
«hours:minutes:seconds»، «days-hours»، «days-hours:minutes» و
«days-hours:minutes:seconds» هستند.

--tmp=<size>[units]

مشخص کردن حداقل فضای دیسک موقت به ازای هر گره (node).
واحد پیش‌فرض مبی‌بایت (mebibytes) است.
واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد.

--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:

--tres-per-task=<list>

فهرستی جداشده با کاما از منابع قابل‌ردیابی مورد نیاز کار به ازای هر وظیفه‌ای که در
تخصیص منابع کار ایجاد خواهد شد را مشخص می‌کند.
قالب هر مدخل در فهرست به صورت "trestype[/tresname]=count" است.
مقدار trestype نوع منبع قابل‌ردیابی درخواستی است (مانند cpu، gres، license و غیره).
مقدار tresname نام منبع قابل‌ردیابی است، همان‌طور که با sacctmgr show tres قابل
مشاهده است. این مقدار در صورت وجود برای انواع tres مانند gres، license و غیره الزامی است
(مانند gpu، gpu:a100).
به منظور درخواست مجوز (license) با این گزینه، مجوز(ها) باید در پارامتر
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

منابع مشخص‌شده روی هر گره به کار تخصیص داده خواهند شد. منابع قابل‌ردیابیِ در دسترس توسط مدیر سیستم قابل‌پیکربندی هستند.
نکته: این گزینه به همراه 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 لغو کرد.
نکته: منابع TRES نامعتبر برای --tres-per-task شامل bb، billing، energy، fs، mem، node، pages و vmem هستند.

--uid=<user>

تلاش برای ارسال و/یا اجرای یک کار به عنوان user به جای شناسه کاربر فراخواننده. از اعتبارنامه‌های کاربر فراخواننده برای بررسی مجوزهای دسترسی به پارتیشن هدف استفاده خواهد شد. برای مثال، کاربر root می‌تواند از این گزینه برای اجرای کارها به عنوان یک کاربر عادی در یک پارتیشن RootOnly استفاده کند. در صورت اجرا به عنوان root، دستور sbatch پس از تخصیص موفقیت‌آمیز گره، دسترسی‌های خود را به uid مشخص‌شده کاهش می‌دهد. user ممکن است نام کاربری یا شناسه کاربری عددی باشد.
نکته: آرگومان --uid منسوخ شده است و در نسخه‌های آینده حذف خواهد شد.

--usage

نمایش پیام راهنمای مختصر و خروج.

--use-min-nodes

در صورت ارائه محدوده‌ای از تعداد گره‌ها، اولویت با تعداد کمتر خواهد بود.

-v, --verbose

افزایش میزان جزئیات پیام‌های اطلاعاتی sbatch. استفاده از چندین -v میزان جزئیات sbatch را بیشتر افزایش می‌دهد. به‌طور پیش‌فرض تنها خطاها نمایش داده خواهند شد.

-V, --version

نمایش اطلاعات نسخه و خروج.

-W, --wait

تا زمان پایان کار ارسال‌شده خارج نشوید. کد وضعیت خروج دستور sbatch مشابه وضعیت خروج کار ارسال‌شده خواهد بود. اگر کار به جای خروج عادی به دلیل دریافت یک سیگنال خاتمه یابد، وضعیت خروج برابر با 1 تنظیم خواهد شد. در مورد یک آرایه کار (job array)، وضعیت خروج ثبت‌شده بالاترین مقدار در میان تمام وظایف موجود در آرایه کار خواهد بود. --wait-all-nodes=<value> زمان شروع اجرای دستور را کنترل می‌کند. به‌طور پیش‌فرض، کار به محض انجام تخصیص، اجرا را آغاز خواهد کرد.

--wckey=<wckey>

مقدار wckey مورد استفاده برای کار را مشخص می‌کند. اگر در slurm.conf مقدار TrackWCKey=no (پیش‌فرض) باشد، این مقدار نادیده گرفته می‌شود.

--wrap=<command_string>

دستور sbatch رشته دستور مشخص‌شده را در یک اسکریپت شل ساده «sh» قرار می‌دهد (wrap می‌کند) و آن اسکریپت را به کنترل‌کننده slurm ارسال می‌نماید. هنگامی که از --wrap استفاده می‌شود، نمی‌توان نام اسکریپت و آرگومان‌ها را در خط فرمان مشخص کرد؛ در عوض از اسکریپت پوششی تولیدشده توسط sbatch استفاده می‌شود.