نام (NAME)

salloc - دریافت یک تخصیص کار اسلرم (مجموعه‌ای از گره‌ها)، اجرای یک دستور، و سپس آزادسازی تخصیص هنگام اتمام دستور.

خلاصه دستور (SYNOPSIS)

salloc [OPTIONS(0)...] [ : [OPTIONS(N)...]] [command(0) [args(0)...]]

گزینه(ها) چندین کار را در یک کار ناهمگنِ هم‌زمان‌بندی‌شده تعریف می‌کنند. برای جزئیات بیشتر درباره کارهای ناهمگن (heterogeneous jobs)، سند زیر را ببینید:
https://slurm.schedmd.com/heterogeneous_jobs.html

توضیحات (DESCRIPTION)

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

دستور می‌تواند هر برنامه‌ای باشد که کاربر می‌خواهد. برخی از دستورهای متداول عبارتند از xterm، یک اسکریپت شل حاوی دستورهای srun، و خود srun (بخش «مثال‌ها» را ببینید). اگر هیچ دستوری مشخص نشده باشد، آن‌گاه salloc شل پیش‌فرض کاربر را اجرا می‌کند.

سند زیر تأثیر گزینه‌های گوناگون را بر تخصیص پردازنده‌ها به کارها و تسک‌ها شرح می‌دهد:
https://slurm.schedmd.com/cpu_management.html

نکته: سازوکار salloc شامل پشتیبانی از ذخیره و بازیابی تنظیمات خط ترمینال است و برای اجرا در پیش‌زمینه (foreground) طراحی شده است. اگر نیاز به اجرای salloc در پس‌زمینه دارید، ورودی استاندارد آن را روی یک فایل تنظیم کنید، برای نمونه: "salloc -n16 a.out </dev/null &"

مقدار بازگشتی (RETURN VALUE)

اگر salloc نتواند دستور کاربر را اجرا کند، مقدار 1 را برمی‌گرداند و خطاها را در stderr چاپ می‌کند. در غیر این صورت، در صورت موفقیت یا اگر توسط سیگنال‌های HUP، INT، KILL یا QUIT متوقف شود، مقدار 0 را برمی‌گرداند.

تفکیک مسیر دستور (COMMAND PATH RESOLUTION)

در صورت ارائه، مسیر دستور به ترتیب زیر تفکیک می‌شود:

1. اگر دستور با "." آغاز شود، مسیر به این صورت ساخته می‌شود: دایرکتوری کاری فعلی / دستور
2. اگر دستور با "/" آغاز شود، مسیر مطلق در نظر گرفته می‌شود.
3. اگر دستور از طریق PATH قابل تفکیک باشد. path_resolution(7) را ببینید.
4. اگر دستور در دایرکتوری کاری فعلی باشد.

دایرکتوری کاری فعلی، همان دایرکتوری کاری فرایند فراخواننده است، مگر اینکه آرگومان --chdir ارسال شود که در این صورت جایگزین دایرکتوری کاری فعلی خواهد شد.

گزینه‌ها (OPTIONS)

-A, --account=<account>

محاسبه و کسر منابع استفاده‌شده توسط این کار به حساب مشخص‌شده (account). مقدار account یک رشته دلخواه است. نام حساب را می‌توان پس از ارسال کار با استفاده از دستور scontrol تغییر داد.

--acctg-freq=<datatype>=<interval>[,<datatype>=<interval>...]

تعیین فواصل زمانی نمونه‌برداری حسابداری کار و پروفایل‌سازی بر حسب ثانیه. این گزینه می‌تواند برای بازنویسی پارامتر JobAcctGatherFrequency در فایل slurm.conf استفاده شود. عبارت <datatype>=<interval> فاصله نمونه‌برداری تسک را برای پلاگین jobacct_gather یا فاصله نمونه‌برداری برای یک نوع پروفایل‌سازی توسط پلاگین acct_gather_profile تعیین می‌کند. چندین جفت <datatype>=<interval> که با کاما از هم جدا شده‌اند می‌توانند مشخص شوند. مقادیر پشتیبانی‌شده برای datatype عبارتند از:

--bb=<spec>

مشخصات بافر انفجاری (burst buffer). قالب این مشخصات وابسته به سیستم است. توجه داشته باشید که ممکن است بافر انفجاری از یک گره ورود (login node) قابل دسترسی نباشد، بلکه نیازمند آن باشد که salloc یک شل را روی یکی از گره‌های محاسباتی تخصیص‌یافته به خود اجرا کند. هنگامی که گزینه --bb استفاده می‌شود، Slurm این گزینه را تجزیه کرده و یک فایل اسکریپت موقت بافر انفجاری ایجاد می‌کند که به صورت داخلی توسط پلاگین‌های burst buffer استفاده می‌شود. برای اطلاعات بیشتر و مثال‌ها، راهنمای burst buffer در Slurm را ببینید:
https://slurm.schedmd.com/burst_buffer.html

--bbf=<file_name>

مسیر فایل حاوی مشخصات بافر انفجاری (burst buffer). قالب این مشخصات وابسته به سیستم است. همچنین گزینه --bb را ببینید. توجه داشته باشید که ممکن است بافر انفجاری از یک گره ورود (login node) قابل دسترسی نباشد، بلکه نیازمند آن باشد که salloc یک شل را روی یکی از گره‌های محاسباتی تخصیص‌یافته به خود اجرا کند. برای اطلاعات بیشتر و مثال‌ها، راهنمای burst buffer در Slurm را ببینید:
https://slurm.schedmd.com/burst_buffer.html

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

--cpus-per-gpu=<ncpus>

درخواست این‌که به‌ازای هر GPU تخصیص‌یافته، تعداد ncpus پردازنده اختصاص یابد. گام‌هایی که این مقدار را به ارث می‌برند، به‌طور ضمنی --exact را اعمال می‌کنند. با گزینهٔ --cpus-per-task سازگار نیست.

-c, --cpus-per-task=<ncpus>

به Slurm اعلام می‌کند که گام‌های کاری بعدی به ncpus پردازنده به‌ازای هر وظیفه (task) نیاز خواهند داشت. به‌طور پیش‌فرض، Slurm یک پردازنده به‌ازای هر وظیفه تخصیص می‌دهد.

برای مثال، برنامه‌ای را در نظر بگیرید که دارای ۴ وظیفه است و هرکدام به ۳ پردازنده نیاز دارند. اگر کلاستر ما متشکل از گره‌های ۴ پردازنده‌ای (quad-processors) باشد و ما صرفاً درخواست ۱۲ پردازنده کنیم، کنترلر ممکن است تنها ۳ گره به ما تخصیص دهد. با این حال، با استفاده از گزینهٔ --cpus-per-task=3، کنترلر متوجه می‌شود که هر وظیفه به ۳ پردازنده روی همان گره نیاز دارد، و کنترلر تخصیصی متشکل از ۴ گره، یکی برای هر یک از ۴ وظیفه را اعطا خواهد کرد..TP --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]]
midnight، elevenses (ساعت ۱۱ صبح)، noon، fika (ساعت ۳ بعدازظهر)، teatime (ساعت ۴ بعدازظهر)، یا tomorrow

می‌توان یک یا چند رشته زمانی را مشخص کرد (برای مثال، 'tomorrow18:00'). در صورت وجود تعارض بین آن‌ها، آخرین مورد بدون اعلام هشدار اولویت خواهد داشت.

--delay-boot=<minutes>

اگر کار برای مدت زمانی کمتر از این بازه واجد شرایط اجرا بوده است، گره‌ها را به منظور برآورده کردن مشخصات ویژگی‌های (feature specification) این کار راه‌اندازی مجدد (reboot) نکنید. اگر کار کمتر از بازه مشخص‌شده در انتظار مانده باشد، تنها از گره‌هایی استفاده خواهد کرد که از قبل دارای ویژگی‌های مشخص‌شده هستند. آرگومان بر حسب دقیقه است. مدیر سیستم می‌تواند با استفاده از گزینه delay_boot از پارامتر پیکربندی SchedulerParameters در فایل slurm.conf یک مقدار پیش‌فرض تنظیم کند؛ در غیر این صورت مقدار پیش‌فرض صفر است (بدون تاخیر).

-d, --dependency=<dependency_list>

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

بدین معنی است که کار تنها پس از کد خروج ۰ از کارهای ۲۰ و ۲۱ و همچنین تکمیل کار ۲۳ می‌تواند اجرا شود. با این حال:

-d afterok:20:21?afterany:23

بدین معنی است که هر یک از شرایط (afterok:20 یا afterok:21 یا afterany:23) برای آزاد کردن کار کافی خواهد بود. چندین کار می‌توانند وابستگی یکسانی داشته باشند و این کارها حتی می‌توانند متعلق به کاربران متفاوتی باشند. این مقدار را می‌توان پس از ارسال کار با استفاده از دستور scontrol تغییر داد. وابستگی به کارهای دوردست در یک فدراسیون مجاز است. هنگامی که وابستگی یک کار به دلیل وضعیت خاتمه یک کار پیشین با شکست مواجه شود، کار وابسته هرگز اجرا نخواهد شد، حتی اگر کار پیشین مجدداً در صف قرار گیرد و در اجرای بعدی وضعیت خاتمه متفاوتی داشته باشد.

-m, --distribution={*|block|cyclic|arbitrary|plane=<size>}[:{*|block|cyclic|fcyclic}[:{*|block|cyclic|fcyclic}]][,{Pack|NoPack}]

روش‌های توزیع جایگزین را برای فرایندهای دوردست مشخص می‌کند. برای تخصیص کار، این گزینه متغیرهای محیطی را تنظیم می‌کند که در درخواست‌های بعدی srun استفاده خواهند شد و همچنین بر اینکه کدام هسته‌ها برای تخصیص کار انتخاب شوند اثر می‌گذارد.

این گزینه توزیع تسک‌ها به گره‌هایی که منابع روی آن‌ها تخصیص یافته است، و توزیع آن منابع به تسک‌ها را برای مقیدسازی (وابستگی تسک یا task affinity) کنترل می‌کند. روش توزیع اول (پیش از نخستین «:») توزیع تسک‌ها به گره‌ها را کنترل می‌کند. روش توزیع دوم (پس از نخستین «:») توزیع پردازنده‌های تخصیص‌یافته را در سوکت‌ها برای مقیدسازی به تسک‌ها کنترل می‌کند. روش توزیع سوم (پس از دومین «:») توزیع پردازنده‌های تخصیص‌یافته را در هسته‌ها برای مقیدسازی به تسک‌ها کنترل می‌کند. توزیع‌های دوم و سوم تنها در صورت فعال بودن task affinity اعمال می‌شوند. توزیع سوم تنها در صورتی پشتیبانی می‌شود که افزایه task/cgroup پیکربندی شده باشد. مقدار پیش‌فرض برای هر نوع توزیع با * مشخص می‌شود.

توجه داشته باشید که با select/cons_tres، تعداد پردازنده‌های تخصیص‌یافته به هر سوکت و گره ممکن است متفاوت باشد. برای اطلاعات بیشتر درباره تخصیص منابع، توزیع تسک‌ها به گره‌ها و مقیدسازی تسک‌ها به پردازنده‌ها به https://slurm.schedmd.com/mc_support.html مراجعه کنید.

-x, --exclude=<node_name_list>

گره‌های خاصی را به‌صراحت از منابع اعطاشده به کار مستثنی می‌کند.

--exclusive[={user|mcs|topo}]

تخصیص کار نمی‌تواند گره‌ها (یا در صورت استفاده از "=topo"، بخش توپولوژی) را با سایر کارهای در حال اجرا (یا در صورت استفاده از گزینهٔ "=user" یا گزینهٔ "=mcs"، فقط با سایر کاربران) به اشتراک بگذارد. اگر user/mcs/topo مشخص نشده باشند (یعنی تخصیص کار نمی‌تواند گره‌ها را با سایر کارهای در حال اجرا به اشتراک بگذارد)، تمام CPUها و GRESهای روی تمام گره‌های موجود در تخصیص به کار اختصاص می‌یابد، اما تنها به همان میزانی که درخواست کرده حافظه به آن تخصیص داده می‌شود. این طراحی برای پشتیبانی از زمان‌بندی گروهی (gang scheduling) است، زیرا کارهای تعلیق‌شده همچنان در حافظه باقی می‌مانند. برای درخواست تمام حافظه روی یک گره، از --mem=0 استفاده کنید. رفتار پیش‌فرض اشتراکی/اختصاصی (shared/exclusive) به پیکربندی سیستم بستگی دارد و گزینهٔ OverSubscribe پارتیشن بر گزینهٔ کار اولویت دارد. نکته: از آنجا که GRES اشتراکی (MPS) را نمی‌توان هم‌زمان با GRES اشتراک‌گذار (GPU) تخصیص داد، این گزینه فقط تمام GRESهای اشتراک‌گذار را تخصیص می‌دهد و هیچ GRES اشتراکی زیربنایی را تخصیص نمی‌دهد.

نکته: این گزینه با --oversubscribe ناسازگار (مانعة‌الجمع) است.

--extra=<string>

یک رشتهٔ دلخواه که در صورت استفاده از فاصله یا برخی نویسه‌های خاص باید در نقل‌قول تکی یا دوتایی قرار گیرد.

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

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

محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شدهٔ سوکت‌ها، هسته‌ها در هر سوکت و/یا رشته‌ها در هر هسته.
نکته: این گزینه‌ها اندازهٔ تخصیص منابع را تعیین نمی‌کنند. هر مقدار مشخص‌شده به‌عنوان یک حداقل در نظر گرفته می‌شود. می‌توان از یک ستاره (*) به‌عنوان جایگزین بدون محدود کردن انتخاب گره برای آن نوع استفاده کرد. در صورت تمایل می‌توان سطوح مجزا را در گزینه‌های جداگانه نیز مشخص کرد:.nf
--sockets-per-node=<sockets>
--cores-per-socket=<cores>
--threads-per-core=<threads>
اگر پلاگین task/affinity فعال باشد، تعیین تخصیص به این روش همچنین منجر می‌شود که وظایف (tasks) اجراشدهٔ بعدی در صورتی که گزینهٔ -B تعداد thread را مشخص کرده باشد به threadها مقید شوند، در غیر این صورت اگر تعداد core مشخص شده باشد به 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 مشخص نشده باشد) به صورت یک وظیفه به ازای هر رشتهٔ (thread) درخواستی تنظیم کند.

--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) پشتیبانی‌شده:

-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های مورد نیاز کار را در هر وظیفه‌ای (task) که قرار است در تخصیص منابع کار ایجاد شود مشخص می‌کند. امکان ارائهٔ یک نوع اختیاری برای GPU وجود دارد. برای نمونه "--gpus-per-task=volta:1". می‌توان چندین گزینه را در یک فهرست جداشده با ویرگول درخواست کرد، برای نمونه: "--gpus-per-task=volta:3,kepler:1". همچنین گزینه‌های --gpus، --gpus-per-socket و --gpus-per-node را ببینید. این گزینه به جای یک بازهٔ مبهم از گره‌ها با -N، --nodes، نیازمند یک شمارش صریح وظایف است؛ مانند -n، --ntasks یا "--gpus=X --gpus-per-task=Y". این گزینه به طور ضمنی مقدار --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 آن را لغو (override) کرد.

--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" است.

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

--gres-flags=<type>

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

-h, --help

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

--hint=<type>

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

-H, --hold

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

-I, --immediate[=<seconds>]

اگر منابع در بازه زمانی مشخص‌شده در دسترس نباشند، خارج می‌شود. اگر هیچ آرگومانی داده نشود (مقدار پیش‌فرض ثانیه‌ها برابر ۱ است)، منابع باید بلافاصله در دسترس باشند تا درخواست با موفقیت انجام شود. اگر defer در SchedulerParameters پیکربندی شده باشد و seconds=1 باشد، درخواست تخصیص بلافاصله با شکست مواجه می‌شود؛ defer تداخل داشته و بر این گزینه اولویت دارد. به طور پیش‌فرض، --immediate غیرفعال است و دستور تا زمانی که منابع در دسترس قرار گیرند متوقف (block) خواهد شد. از آنجا که آرگومان این گزینه اختیاری است، برای تجزیه صحیح، گزینه تک‌حرفی باید بلافاصله با مقدار آن دنبال شود و فاصله‌ای بین آنها نباشد؛ به عنوان مثال "-I60" و نه "-I 60";.

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

مشخص کردن نامی برای تخصیص کار. نام مشخص‌شده هنگام پرس‌وجوی کارهای در حال اجرا روی سیستم، در کنار شماره شناسه کار (job id) نمایش داده خواهد شد. نام پیش‌فرض کار، نام "دستور" مشخص‌شده در خط فرمان است.

-K, --kill-command[=signal]

دستور salloc همواره پس از اعطای تخصیص، یک دستور مشخص‌شده توسط کاربر را اجرا می‌کند. salloc به مدت نامحدود برای خروج آن دستور منتظر می‌ماند. اگر گزینه --kill-command را مشخص کنید، هر زمان که کنترلر Slurm به salloc اطلاع دهد تخصیص کار آن لغو شده است، salloc سیگنالی به دستور شما ارسال خواهد کرد. تخصیص کار می‌تواند به دو دلیل لغو شود: فردی از scancel برای لغو تخصیص استفاده کرده باشد، یا تخصیص به محدودیت زمانی خود رسیده باشد. اگر نام یا شماره سیگنالی را مشخص نکنید و Slurm برای ارسال سیگنال به دستور ایجادشده هنگام پایان کار پیکربندی شده باشد، سیگنال پیش‌فرض برای نشست‌های تعاملی SIGHUP و برای نشست‌های غیرتعاملی SIGTERM است. از آنجا که آرگومان این گزینه اختیاری است، برای تجزیه صحیح، گزینه تک‌حرفی باید بلافاصله با مقدار آن دنبال شود و فاصله‌ای بین آنها نباشد؛ به عنوان مثال "-K1" و نه "-K 1";.

-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)، درخواست‌های مجوز تنها می‌توانند روی نخستین مؤلفه از کار انجام شوند؛ به عنوان مثال "salloc -L ansys:2 :".

نکته: اگر مجوزها در AccountingStorageTres ردیابی شوند و از OR استفاده شود، ReqTRES تمام tresهای درخواستی را به صورت جداشده با کاما نمایش خواهد داد. AllocTRES تنها مجوزی را که به کار تخصیص یافته است نمایش می‌دهد.

نکته: وقتی کاری مجوزها را با عملگر OR درخواست می‌کند، Slurm تلاش خواهد کرد مجوزها را به همان ترتیبی که درخواست شده‌اند تخصیص دهد. این ترتیب مشخص‌شده حتی در صورتی که باقی مجوزهای درخواستی بتوانند روی یک رزرو درخواستی برآورده شوند، اولویت خواهد داشت. این موضوع در زمان پیکربندی SchedulerParameters=bf_licenses برای برنامه‌ریزی backfill نیز اعمال می‌شود.

--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 (رسیدن به ۵۰ درصد محدودیت زمانی). می‌توان چندین مقدار type را در فهرستی جداشده با کاما مشخص کرد. مقدار NONE تمام اعلان‌های رویداد را فرونشانی کرده و مقادیر دیگر مشخص‌شده را نادیده می‌گیرد. به طور پیش‌فرض هیچ اعلان ایمیلی ارسال نمی‌شود. کاربری که باید به او اطلاع داده شود با --mail-user تعیین می‌شود.

--mail-user=<user>

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

--mcs-label=<mcs>

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

--mem=<size>[units]

مشخص کردن حافظه واقعی مورد نیاز به ازای هر گره. واحد پیش‌فرض مبی‌بایت است. واحدهای دیگر را می‌توان با استفاده از پسوند [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) مراجعه کنید..IP

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

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

نکته: برای اینکه Slurm همواره وضعیت مقیدسازی حافظهٔ انتخاب‌شده را برای تمامی دستورهای اجراشده در یک پوسته گزارش دهد، می‌توانید حالت پرگو را با تنظیم مقدار متغیر محیطی SLURM_MEM_BIND روی "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]

حداقل حافظهٔ مورد نیاز به ازای هر CPU تخصیص‌یافتهٔ قابل استفاده. واحد پیش‌فرض مبی‌بایت (mebibytes) است. واحدهای مختلف را می‌توان با استفاده از پسوند [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های تخصیص‌یافتهٔ قابل استفاده در یک تخصیص کار صدق می‌کند. این نکته زمانی حائز اهمیت است که بیش از یک رشته در هر هسته پیکربندی شده باشد. اگر کاری --threads-per-core را با رشته‌های کمتری نسبت به آنچه روی هسته وجود دارد درخواست کند (یا --hint=nomultithread که به معنای --threads-per-core=1 است)، کار قادر به استفاده از آن رشته‌های اضافه روی هسته نخواهد بود و آن رشته‌ها در محاسبهٔ حافظه به ازای هر CPU لحاظ نخواهند شد. اما اگر کار به تمام رشته‌های روی هسته دسترسی داشته باشد، آن رشته‌ها در محاسبهٔ حافظه به ازای هر CPU لحاظ خواهند شد، حتی اگر کار صراحتاً آن رشته‌ها را درخواست نکرده باشد.

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

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

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

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

--mincpus=<n>

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

--network=<type>

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

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

روی سیستم‌های پیکربندی‌شده با SwitchType=switch/nvidia_imex، گزینه‌های زیر پشتیبانی می‌شوند:
unique-channel-per-segment
به‌جای یک کانال برای کل کار، به‌ازای هر سگمنت (segment) در کار یک کانال تخصیص می‌دهد. این گزینه تنها زمانی اعمال می‌شود که topology/block پیکربندی شده باشد.

--nice[=adjustment]

اجرای کار با اولویت زمان‌بندی تنظیم‌شده در Slurm. بدون مقدار تنظیمی، اولویت زمان‌بندی ۱۰۰ واحد کاهش می‌یابد. مقدار nice منفی اولویت را افزایش داده و در غیر این صورت آن را کاهش می‌دهد. محدوده تنظیم +/- 2147483645 است. تنها کاربران مجاز (ممتاز) می‌توانند مقدار تنظیمی منفی تعیین کنند.

--no-bell

بی‌صدا کردن استفاده salloc از زنگ ترمینال (terminal bell). همچنین گزینه --bell را ببینید.

-k, --no-kill[=off]

اگر یکی از گره‌های تخصیص‌یافته به کار دچار خرابی شود، کار را به‌طور خودکار خاتمه نده. در صورت خرابی یک گره، مسئولیت تحمل خطا (fault-tolerance) بر عهده کاربر خواهد بود.
تخصیص کار لغو نخواهد شد تا کاربر بتواند گام‌های کاری جدیدی را روی گره‌های باقی‌مانده در تخصیص خود اجرا کند.
این گزینه متغیر محیطی SLURM_NO_KILL را مقداردهی نمی‌کند.
بنابراین، هنگام خرابی یک گره، گام‌های در حال اجرا روی آن گره کشته خواهند شد مگر اینکه متغیر محیطی SLURM_NO_KILL به‌صراحت تنظیم شده باشد یا فراخوانی‌های srun درون تخصیص کار صریحاً --no-kill را درخواست کرده باشند.
برای غیرفعال کردن اثر متغیر محیطی SALLOC_NO_KILL، آرگومان اختیاری "off" را مشخص کنید.
به‌طور پیش‌فرض، اگر هر گره‌ای در محدوده گره‌های تخصیص‌یافته به کار دچار خرابی شود، Slurm کل تخصیص کار را خاتمه می‌دهد.

--no-shell

بلافاصله پس از تخصیص منابع، بدون اجرای هیچ فرمانی خارج شو. با این وجود، کار Slurm همچنان ایجاد خواهد شد، فعال باقی می‌ماند و تا زمانی که فعال است مالکیت منابع تخصیص‌یافته را در اختیار خواهد داشت.
شما یک شناسه کار Slurm بدون هیچ فرایند یا وظیفه (task) مرتبطی خواهید داشت. اگر گزینه --jobid= را با شناسه این کار Slurm مشخص کنید، می‌توانید دستورهای srun را روی این تخصیص منابع اجرا نمایید.
همچنین از این گزینه می‌توان برای رزرو موقت مجموعه‌ای از منابع استفاده کرد تا سایر کارها نتوانند برای مدتی از آن‌ها استفاده کنند. (توجه داشته باشید که کار Slurm مشمول محدودیت‌های معمول کارها، از جمله محدودیت‌های زمانی است، به‌طوری که در نهایت کار خاتمه یافته و منابع آزاد می‌شوند، یا اینکه می‌توانید کار را به‌صورت دستی با استفاده از دستور scancel لغو کنید.)

-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 مشخص نشده باشد، رفتار پیش‌فرض این است که گره‌های کافی برای برآورده کردن منابع درخواستیِ مشخص‌شده توسط گزینه‌های per-job، مانند -n، -c و --gpus تخصیص یابد.
به کار تا حد امکان بیشترین تعداد گره در محدوده مشخص‌شده و بدون به تاخیر انداختن آغاز کار تخصیص داده می‌شود.
مشخصه تعداد گره می‌تواند شامل یک مقدار عددی و به‌دنبال آن پسوند "k" (ضرب مقدار عددی در ۱٬۰۲۴) یا "m" (ضرب مقدار عددی در ۱٬۰۴۸٬۵۷۶) باشد.
NOTE: این گزینه را نمی‌توان به همراه توزیع دلخواه (arbitrary distribution) استفاده کرد.

-n, --ntasks=<number>

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

--ntasks-per-core=<ntasks>

درخواست اجرای حداکثر ntasks وظیفه روی هر هسته (core).
برای استفاده به همراه گزینه --ntasks در نظر گرفته شده است.
مرتبط با --ntasks-per-node، با این تفاوت که به‌جای سطح گره، در سطح هسته اعمال می‌شود. این گزینه توسط srun به ارث برده خواهد شد.
ممکن است Slurm برای رعایت این گزینه، پردازنده‌های (cpus) بیشتری نسبت به آنچه درخواست شده بود تخصیص دهد.
NOTE: این گزینه هنگام استفاده از 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 اجازه داده می‌شود از تمام موازی‌سازی موجود در گره استفاده کند، یا ارسال یک کار منفرد راه‌اندازی/پاک‌سازی/پایش به هر گره از یک تخصیص موجود از قبل به‌عنوان یک گام در یک اسکریپت کاری بزرگ‌تر..IP

--ntasks-per-socket=<ntasks>

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

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

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

-O, --overcommit

تخصیص بیش‌از‌حد (overcommit) منابع.
هنگامی که برای یک تخصیص کار (job allocation) اعمال شود (به‌جز کارهایی که دسترسی انحصاری به گره‌ها را درخواست می‌کنند)، منابع به گونه‌ای تخصیص می‌یابند که گویی تنها یک وظیفه به ازای هر گره درخواست شده است. این بدان معناست که تعداد پردازنده‌های درخواستی برای هر وظیفه (-c، --cpus-per-task) به ازای هر گره تخصیص می‌یابد، به جای اینکه در تعداد وظایف ضرب شود. گزینه‌های تعیین‌کننده تعداد وظایف در هر گره، سوکت، هسته و غیره نادیده گرفته می‌شوند.
هنگامی که برای تخصیص‌های گام کار اعمال شود (دستور srun هنگامی که درون یک تخصیص کارِ موجود اجرا شود)، این گزینه می‌تواند برای راه‌اندازی بیش از یک وظیفه به ازای هر CPU استفاده شود.
به طور معمول، srun بیش از یک فرایند به ازای هر CPU تخصیص نمی‌دهد.
با مشخص کردن --overcommit شما صراحتاً اجازه اجرای بیش از یک فرایند به ازای هر CPU را می‌دهید. با این حال، اجرای بیش از MAX_TASKS_PER_NODE وظیفه در هر گره مجاز نیست. نکته: مقدار MAX_TASKS_PER_NODE در فایل slurm.h تعریف شده و یک متغیر نیست، بلکه در زمان ساخت (build) نرم‌افزار Slurm تنظیم می‌شود.

-s, --oversubscribe

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

-p, --partition=<partition_names>

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

--prefer=<list>

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

--priority=<value>

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

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

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

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

-q, --qos=<qos>

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

-Q, --quiet

عدم نمایش پیام‌های اطلاعاتی salloc. خطاها همچنان نمایش داده خواهند شد.

--reboot

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

--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 استفاده می‌شود.
این گزینه فقط در صورتی قابل استفاده است که مدیریت گام slurmstepd فعال باشد.
--stepmgr را ببینید.

--segment=<segment_size>

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

--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 باید روی سیستم فعال باشد،
و در صورت اعمال preemption بر روی کار، در صورت مجاز بودن مجدداً در صف قرار می‌گیرد (requeued)،
در غیر این صورت لغو خواهد شد.
برای ارسال سیگنال در هنگام preemption، پارامتر send_user_signal
در PreemptParameter را ببینید.

--sockets-per-node=<sockets>

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

--spread-job

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

--spread-segments

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

--stepmgr

مدیریت گام slurmstepd را به ازای هر کار فعال می‌کند، در صورتی که در سطح سیستم فعال نشده باشد.
این ویژگی امکان مدیریت گام‌های کار را توسط یک slurmstepd خارجی (extern) منفرد مرتبط
با کار برای مدیریت گام‌ها فراهم می‌کند. این امر برای کارهایی که گام‌های متعددی
را در تخصیص‌های خود ارسال می‌کنند سودمند است. 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 است.

--thread-spec=<num>

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

--threads-per-core=<threads>

انتخاب گره را به گره‌هایی با حداقل تعداد مشخص‌شده رشته به ازای هر هسته
محدود می‌کند. در طرح‌بندی وظایف (task layout)، از حداکثر تعداد رشته مشخص‌شده
در هر هسته استفاده کنید. نکته: «رشته‌ها» به تعداد واحدهای پردازشی روی
هر هسته اشاره دارد، نه تعداد وظایف برنامه‌ای که قرار است به ازای هر هسته اجرا شوند.
هنگامی که افزونه 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".

--time-min=<time>

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

--tmp=<size>[units]

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

منابع مشخص‌شده در هر گره به کار تخصیص داده خواهند شد. منابع قابل‌ردیابیِ در دسترس توسط مدیر سیستم قابل‌پیکربندی هستند.
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.

--usage

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

--use-min-nodes

اگر بازه‌ای از تعداد گره‌ها داده شده باشد، تعداد کمتر ترجیح داده می‌شود.

-v, --verbose

افزایش پرگویی (verbosity) پیام‌های اطلاعاتی salloc. استفاده از چندین -v پرگویی salloc را باز هم افزایش می‌دهد. به طور پیش‌فرض فقط خطاها نمایش داده خواهند شد.

-V, --version

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

--wait-all-nodes=<value>

زمان آغاز اجرای دستور را نسبت به زمان آماده‌به‌کار شدن گره‌ها (یعنی بوت شدن) کنترل می‌کند. به طور پیش‌فرض، دستور salloc به محض انجام تخصیص بازمی‌گردد. این مقدار پیش‌فرض می‌تواند با استفاده از گزینه salloc_wait_nodes در پارامتر SchedulerParameters در فایل slurm.conf تغییر یابد.

--wckey=<wckey>

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

--x11[={all|first|last}]

راه‌اندازی بازفرستادن X11 روی «all» (همه)، «first» (اولین) یا «last» (آخرین) گره(های) تخصیص. این گزینه تنها در صورتی فعال است که Slurm با پشتیبانی از X11 کامپایل شده باشد و PrologFlags=x11 در slurm.conf تعریف شده باشد. مقدار پیش‌فرض "all" است.

NOTE: در صورتی که --clusters نیز ارائه شده باشد ممکن است این گزینه کار نکند. چنین کارهایی (همراه با یک هشدار) پذیرفته خواهند شد، اما عملکرد بازفرستادن X11 تضمین نمی‌شود.

اجرای salloc یک فراخوانی رویه از راه دور (RPC) به slurmctld ارسال می‌کند. اگر تعداد زیادی فراخوانی از سوی salloc یا سایر دستورهای کلاینت Slurm که فراخوانی‌های رویه از راه دور به دیمن slurmctld می‌فرستند به‌طور هم‌زمان دریافت شوند، می‌تواند منجر به افت کارایی دیمن slurmctld و احتمالاً ایجاد وضعیت منع سرویس (DoS) شود.

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

متغیرهای محیطی ورودی (INPUT ENVIRONMENT VARIABLES)

هنگام راه‌اندازی، salloc گزینه‌های تنظیم‌شده در متغیرهای محیطی زیر را خوانده و مدیریت می‌کند. اکثر این متغیرها به همان شیوه‌ای که گزینه‌ها در بالا تعریف شده‌اند، مقداردهی می‌شوند. برای گزینه‌های پرچمی (flag) که بدون آرگومان تعریف شده‌اند، گزینه می‌تواند با تنظیم متغیر محیطی بدون مقدار (رشته خالی یا NULL)، رشته 'yes'، یا یک عدد غیرصفر فعال شود. هر مقدار دیگری برای متغیر محیطی منجر به عدم تنظیم گزینه خواهد شد. چند استثنا برای این قواعد وجود دارد که در زیر ذکر شده‌اند.
نکته: گزینه‌های خط فرمان همواره بر تنظیمات متغیرهای محیطی ارجحیت دارند.

SALLOC_ACCOUNT

مشابه -A, --account

SALLOC_ACCTG_FREQ

مشابه --acctg-freq

SALLOC_BELL

مشابه --bell

SALLOC_BURST_BUFFER

مشابه --bb

SALLOC_CLUSTERS یا SLURM_CLUSTERS

مشابه --clusters

SALLOC_CONSTRAINT

مشابه -C، --constraint

SALLOC_CONTAINER

مشابه --container.

SALLOC_CONTAINER_ID

مشابه --container-id.

SALLOC_CONTAINER_TYPE

مشابه --container-type.

SALLOC_CORE_SPEC

مشابه --core-spec

SALLOC_CPUS_PER_GPU

مشابه --cpus-per-gpu

SALLOC_DEBUG

مشابه -v, --verbose؛ هنگامی که روی ۱ تنظیم شود معادل -v، هنگامی که روی ۲ تنظیم شود -vv، و به همین ترتیب.

SALLOC_DELAY_BOOT

مشابه --delay-boot

SALLOC_EXCLUSIVE

مشابه --exclusive

SALLOC_GPU_BIND

مشابه --gpu-bind

SALLOC_GPU_FREQ

مشابه --gpu-freq

SALLOC_GPUS

مشابه -G, --gpus

SALLOC_GPUS_PER_NODE

مشابه --gpus-per-node

SALLOC_GPUS_PER_TASK

مشابه --gpus-per-task

SALLOC_GRES

مشابه --gres

SALLOC_GRES_FLAGS

مشابه --gres-flags

SALLOC_HINT یا SLURM_HINT

مشابه --hint

SALLOC_IMMEDIATE

مشابه -I, --immediate

SALLOC_KILL_CMD

مشابه -K، --kill-command

SALLOC_MEM_BIND

مشابه --mem-bind

SALLOC_MEM_PER_CPU

مشابه --mem-per-cpu

SALLOC_MEM_PER_GPU

مشابه --mem-per-gpu

SALLOC_MEM_PER_NODE

مشابه --mem

SALLOC_NETWORK

مشابه --network

SALLOC_NO_BELL

مشابه --no-bell

SALLOC_NO_KILL

مشابه -k، --no-kill SALLOC_OVERCOMMIT مشابه -O, --overcommit

SALLOC_PARTITION

مشابه -p, --partition

SALLOC_POWER

مشابه --power

SALLOC_PROFILE

مشابه --profile

SALLOC_QOS

مشابه --qos

SALLOC_REQ_SWITCH

هنگام استفاده از توپولوژی درختی، این متغیر حداکثر تعداد سوئیچ‌های مورد نظر برای تخصیص کار و به صورت اختیاری حداکثر زمان انتظار برای آن تعداد سوئیچ را مشخص می‌کند. --switches را ببینید.

SALLOC_RESERVATION

مشابه --reservation

SALLOC_SEGMENT_SIZE

مشابه --segment

SALLOC_SIGNAL

مشابه --signal

SALLOC_SPREAD_JOB

مشابه --spread-job

SALLOC_THREAD_SPEC

مشابه --thread-spec

SALLOC_THREADS_PER_CORE

مشابه --threads-per-core

SALLOC_TIMELIMIT

مشابه -t, --time

SALLOC_TRES_BIND

مشابه --tres-bind

SALLOC_TRES_PER_TASK

مشابه --tres-per-task

SALLOC_USE_MIN_NODES

مشابه --use-min-nodes

SALLOC_WAIT_ALL_NODES

مشابه --wait-all-nodes. برای غیرفعال یا فعال کردن این گزینه باید روی 0 یا 1 تنظیم شود.

SALLOC_WAIT4SWITCH

حداکثر زمان انتظار برای سوئیچ‌های درخواستی. --switches را ببینید.

SALLOC_WCKEY

مشابه --wckey

SLURM_CONF

محل فایل پیکربندی Slurm.

SLURM_DEBUG_FLAGS

پرچم‌های اشکال‌زدایی مورد استفاده توسط salloc را مشخص می‌کند. برای فهرست کامل پرچم‌ها، DebugFlags را در صفحه راهنمای slurm.conf(5) ببینید. این متغیر محیطی بر تنظیمات موجود در slurm.conf اولویت دارد.

SLURM_EXIT_ERROR

کد خروج تولیدشده هنگام رخداد یک خطای Slurm (مانند گزینه‌های نامعتبر) را مشخص می‌کند. یک اسکریپت می‌تواند از این متغیر برای تمایز کدهای خروج برنامه کاربردی از شرایط خطای مختلف Slurm استفاده کند. همچنین SLURM_EXIT_IMMEDIATE را ببینید.

SLURM_EXIT_IMMEDIATE

کد خروج تولیدشده هنگام استفاده از گزینه --immediate در صورتی که منابع در حال حاضر در دسترس نباشند را مشخص می‌کند. یک اسکریپت می‌تواند از این متغیر برای تمایز کدهای خروج برنامه کاربردی از شرایط خطای مختلف Slurm استفاده کند. همچنین SLURM_EXIT_ERROR را ببینید.

دستور salloc متغیرهای محیطی زیر را در محیط برنامهٔ اجراشده مقداردهی می‌کند:

SLURM_*_HET_GROUP_#

برای یک تخصیص کار ناهمگن (heterogeneous)، متغیرهای محیطی به‌طور جداگانه برای هر مؤلفه تنظیم می‌شوند.

SLURM_CLUSTER_NAME

نام خوشه‌ای (cluster) که کار روی آن در حال اجرا است.

SLURM_CONTAINER

بسته OCI (OCI Bundle) برای کار. تنها در صورتی تنظیم می‌شود که --container مشخص شده باشد.

SLURM_CONTAINER_ID

شناسه OCI برای کار. تنها در صورتی تنظیم می‌شود که --container-id مشخص شده باشد.

SLURM_CONTAINER_TYPE

نوع ظرف (container) کار. تنها در صورتی تنظیم می‌شود که --container-type مشخص شده باشد.

SLURM_CPUS_PER_GPU

تعداد CPUهای درخواست‌شده به ازای هر GPU تخصیص‌یافته. تنها در صورتی تنظیم می‌شود که گزینهٔ --cpus-per-gpu مشخص شده باشد.

SLURM_CPUS_PER_TASK

تعداد CPUهای درخواست‌شده به ازای هر وظیفه (task). تنها در صورتی تنظیم می‌شود که گزینهٔ --cpus-per-task یا گزینهٔ --tres-per-task=cpu=# مشخص شده باشد.

SLURM_DIST_PLANESIZE

اندازه توزیع صفحه‌ای (plane distribution). تنها برای توزیع‌های صفحه‌ای تنظیم می‌شود. به -m, --distribution مراجعه کنید.

SLURM_DISTRIBUTION

تنها در صورتی تنظیم می‌شود که گزینهٔ -m, --distribution مشخص شده باشد.

SLURM_GPU_BIND

اتصال (binding) درخواست‌شدهٔ وظایف به GPU. تنها در صورتی تنظیم می‌شود که گزینهٔ --gpu-bind مشخص شده باشد.

SLURM_GPU_FREQ

فرکانس درخواست‌شدهٔ GPU. تنها در صورتی تنظیم می‌شود که گزینهٔ --gpu-freq مشخص شده باشد.

SLURM_GPUS

تعداد GPUهای درخواست‌شده. تنها در صورتی تنظیم می‌شود که گزینهٔ -G, --gpus مشخص شده باشد.

SLURM_GPUS_PER_NODE

تعداد GPU درخواستی به ازای هر گره (node) تخصیص‌یافته. تنها در صورتی تنظیم می‌شود که گزینهٔ --gpus-per-node مشخص شده باشد.

SLURM_GPUS_PER_SOCKET

تعداد GPU درخواستی به ازای هر سوکت (socket) تخصیص‌یافته. تنها در صورتی تنظیم می‌شود که گزینهٔ --gpus-per-socket مشخص شده باشد.

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 پردازنده‌های مجزا را به کارها تخصیص می‌دهد، بنابراین این عدد نشان‌دهندهٔ تعداد CPUهای تخصیص‌یافته به کار است.

SLURM_JOB_END_TIME

برچسب زمانی یونیکس (UNIX timestamp) برای زمان تخمینی پایان کار.

SLURM_JOB_GPUS

شناسه‌های سراسری (global) برای GPUهای تخصیص‌یافته به این کار. شناسه‌های GPU وابسته به cgroup هیچ دستگاهی نیستند، حتی اگر دستگاه‌ها با task/cgroup محدود شده باشند. تنها در کارهای دسته‌ای (batch) و تعاملی (interactive) تنظیم می‌شود.

SLURM_JOB_ID

شناسهٔ تخصیص کار.

SLURM_JOB_LICENSES

نام و تعداد مجوز(های) درخواست‌شده.

SLURM_JOB_NODELIST

فهرست گره‌های تخصیص‌یافته به کار.

SLURM_JOB_NUM_NODES

تعداد کل گره‌ها در تخصیص کار.

SLURM_JOB_PARTITION

نام پارتیشنی که کار در آن در حال اجرا است.

SLURM_JOB_QOS

کیفیت خدمات یا QOS (مخفف Quality Of Service) برای تخصیص کار.

SLURM_JOB_RESERVATION

رزرو پیشرفته‌ای (advanced reservation) که دربرگیرندهٔ تخصیص کار است، در صورت وجود.

SLURM_JOB_SEGMENT_SIZE

اندازه قطعه‌هایی (segments) که برای ایجاد تخصیص کار استفاده شده است. تنها در صورتی تنظیم می‌شود که --segment مشخص شده باشد.

SLURM_JOB_START_TIME

برچسب زمانی یونیکس (UNIX timestamp) برای زمان آغاز کار.

SLURM_JOBID

شناسهٔ تخصیص کار. به SLURM_JOB_ID مراجعه کنید. جهت سازگاری با نسخه‌های پیشین گنجانده شده است.

SLURM_MEM_BIND

برابر با مقدار گزینهٔ --mem-bind تنظیم می‌شود. SLURM_MEM_BIND_LIST روی ماسک بیتی استفاده‌شده برای مقیدسازی حافظه (memory binding) تنظیم می‌شود.

SLURM_MEM_BIND_PREFER

اگر گزینهٔ --mem-bind شامل گزینهٔ prefer باشد، روی "prefer" تنظیم می‌شود.

SLURM_MEM_BIND_TYPE

روی نوع مقیدسازی حافظه که با گزینهٔ --mem-bind مشخص شده، تنظیم می‌شود. مقادیر ممکن عبارتند از "none"، "rank"، "map_mem:"، "mask_mem:" و "local".

SLURM_MEM_BIND_VERBOSE

اگر گزینهٔ --mem-bind شامل گزینهٔ verbose باشد، روی "verbose" تنظیم می‌شود. در غیر این صورت روی "quiet" تنظیم می‌شود.

SLURM_MEM_PER_CPU

همانند --mem-per-cpu

SLURM_MEM_PER_GPU

حافظهٔ درخواستی به ازای هر GPU تخصیص‌یافته. تنها در صورتی تنظیم می‌شود که گزینهٔ --mem-per-gpu مشخص شده باشد.

SLURM_MEM_PER_NODE

همانند --mem

SLURM_NETWORK

در صورت تعیین، روی مقدار گزینهٔ --network تنظیم می‌شود.

SLURM_NNODES

تعداد کل گره‌ها در تخصیص کار. SLURM_JOB_NUM_NODES را ببینید. جهت سازگاری با نسخه‌های پیشین گنجانده شده است.

SLURM_NODELIST

فهرست گره‌های تخصیص‌یافته به کار. SLURM_JOB_NODELIST را ببینید. جهت سازگاری با نسخه‌های پیشین گنجانده شده است.

SLURM_NPROCS

همانند SLURM_NTASKS. جهت سازگاری با نسخه‌های پیشین گنجانده شده است.

SLURM_NTASKS

در صورت تعیین، روی مقدار گزینهٔ --ntasks تنظیم می‌شود. یا، چنانچه هر یک از گزینه‌های --ntasks-per-* مشخص شده باشند، روی تعداد وظایف (tasks) موجود در کار تنظیم می‌شود.

نکته: این متغیر همچنین یک متغیر ورودی برای srun است، بنابراین در صورت مقداردهی، هنگام فراخوانی از پوستهٔ salloc، عملاً گزینهٔ --ntasks را برای srun تنظیم خواهد کرد.

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_OVERCOMMIT

چنانچه --overcommit مشخص شده باشد، روی 1 تنظیم می‌شود.

SLURM_PROFILE

همانند --profile

SLURM_SHARDS_ON_NODE

تعداد قطعات GPU (GPU Shards) در دسترس گام بر روی این گره.

SLURM_SUBMIT_DIR

پوشه‌ای که salloc از آن فراخوانی شده است یا در صورت وجود، پوشهٔ مشخص‌شده توسط گزینهٔ -D, --chdir.

SLURM_SUBMIT_HOST

نام میزبان (hostname) رایانه‌ای که salloc از آن فراخوانی شده است.

SLURM_TASKS_PER_NODE

تعداد وظایفی که باید در هر گره آغاز شوند. مقادیر با ویرگول از هم جدا شده و به همان ترتیب SLURM_JOB_NODELIST هستند. اگر دو یا چند گره متوالی تعداد وظایف یکسانی داشته باشند، آن تعداد با "(x#)" دنبال می‌شود که "#" تعداد تکرار است. برای مثال، "SLURM_TASKS_PER_NODE=2(x3),1" نشان می‌دهد که سه گره نخست هر کدام دو وظیفه را اجرا می‌کنند و گره چهارم یک وظیفه را اجرا خواهد کرد.

SLURM_THREADS_PER_CORE

تنها در صورتی تنظیم می‌شود که --threads-per-core یا SALLOC_THREADS_PER_CORE مشخص شده باشند. این مقدار برابر با مقدار تعیین‌شده توسط --threads-per-core یا SALLOC_THREADS_PER_CORE خواهد بود. این متغیر توسط فراخوانی‌های بعدی srun در داخل تخصیص کار استفاده می‌شود.

SLURM_TRES_PER_TASK

روی مقدار --tres-per-task تنظیم می‌شود. اگر --cpus-per-task یا --gpus-per-task مشخص شده باشد، به گونه‌ای در SLURM_TRES_PER_TASK تنظیم می‌شود که گویی در --tres-per-task مشخص شده است.

در حالی که salloc در انتظار یک تخصیص کار PENDING است، بیشتر سیگنال‌ها باعث می‌شوند salloc درخواست تخصیص را لغو کرده و خارج شود.

با این حال، اگر تخصیص اعطا شده باشد و salloc از قبل دستور مشخص‌شده را آغاز کرده باشد، بیشتر سیگنال‌ها را نادیده خواهد گرفت. salloc تا زمانی که دستور پایان نیابد، خارج نخواهد شد و تخصیص را آزاد نمی‌کند. یک استثنای قابل توجه SIGHUP است. سیگنال SIGHUP باعث می‌شود salloc تخصیص را آزاد کرده و بدون منتظر ماندن برای پایان یافتن دستور خارج شود. استثنای دیگر SIGTERM است که به فرایند ایجادشده ارسال (forward) خواهد شد.

مثال‌ها (EXAMPLES)

برای دریافت یک تخصیص، و باز کردن یک xterm جدید که دستورات srun بتوانند در آن به‌صورت تعاملی وارد شوند:

$ salloc -N16 xterm
salloc: Granted job allocation 65537
# (at this point the xterm appears, and salloc waits for xterm to exit)
salloc: Relinquishing job allocation 65537

برای گرفتن تخصیص گره‌ها و راه‌اندازی یک برنامه موازی در یک خط فرمان:

$ salloc -N5 srun -n10 myprogram

برای ایجاد یک کار ناهمگن با ۳ مؤلفه، که هر کدام مجموعه‌ای یکتا از گره‌ها را تخصیص می‌دهند:

$ salloc -w node[2-3] : -w node4 : -w node[5-7] bash
salloc: job 32294 queued and waiting for resources
salloc: job 32294 has been allocated resources
salloc: Granted job allocation 32294

کپی‌رایت و تکثیر (COPYING)

Copyright (C) 2006-2007 The Regents of the University of California. تولید شده در Lawrence Livermore National Laboratory (رک، DISCLAIMER).
Copyright (C) 2008-2010 Lawrence Livermore National Security.
Copyright (C) 2010-2022 SchedMD LLC.

این فایل بخشی از Slurm، یک برنامه مدیریت منابع، است. برای جزئیات بیشتر، https://slurm.schedmd.com را ببینید.

نرم‌افزار Slurm یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط «پروانه عمومی همگانی گنو» همان‌طور که توسط «بنیاد نرم‌افزارهای آزاد» منتشر شده است، چه نسخه ۲ پروانه و چه (به انتخاب خودتان) هر نسخهٔ بعدی، بازتوزیع کرده و/یا تغییر دهید.

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

همچنین ببینید (SEE ALSO)

sinfo(1), sattach(1), sbatch(1), squeue(1), scancel(1), scontrol(1), slurm.conf(5), sched_setaffinity (2), numa (3)