slurm.conf(5) پرونده پیکربندی اسلورم slurm.conf(5)

slurm.conf - پرونده پیکربندی اسلورم

slurm.conf یک پرونده اسکی (ASCII) است که اطلاعات کلی پیکربندی Slurm، گره‌های تحت مدیریت، اطلاعات مربوط به نحوه گروه‌بندی آن گره‌ها در پارتیشن‌ها و پارامترهای مختلف زمان‌بندی مرتبط با آن پارتیشن‌ها را شرح می‌دهد. این پرونده باید در تمام گره‌های خوشه یکپارچه و یکسان باشد.

مکان این پرونده را می‌توان در زمان اجرا با تنظیم متغیر محیطی SLURM_CONF تغییر داد. دیمن‌های Slurm همچنین به شما این امکان را می‌دهند که با استفاده از گزینه «-f» در خط فرمان، مکان پیش‌فرض داخلی و مکان ارائه‌شده توسط متغیر محیطی را بازنویسی (override) کنید.

محتویات این پرونده به استثنای نام گره‌ها و پارتیشن‌ها به حروف بزرگ و کوچک حساس نیست (case insensitive). هر متنی پس از «#» در پرونده پیکربندی تا انتهای آن سطر به عنوان یادداشت (کامنت) در نظر گرفته می‌شود. تغییرات در پرونده پیکربندی با راه‌اندازی مجدد دیمن‌های Slurm، دریافت سیگنال SIGHUP توسط دیمن، یا اجرای دستور «scontrol reconfigure» اعمال می‌شوند، مگر اینکه خلاف آن ذکر شده باشد. تغییرات در تنظیمات شنود TCP نیازمند راه‌اندازی مجدد دیمن خواهد بود.

اگر سطری با کلمه «Include» و به دنبال آن یک فضای خالی (whitespace) و سپس نام یک پرونده آغاز شود، آن پرونده به‌صورت درون‌خطی در پرونده پیکربندی فعلی گنجانده می‌شود. برای سامانه‌های بزرگ یا پیچیده، استفاده از چندین پرونده پیکربندی ممکن است مدیریت را آسان‌تر کرده و امکان استفاده مجدد از برخی پرونده‌ها را فراهم کند (برای جزئیات بیشتر به بخش INCLUDE MODIFIERS مراجعه کنید).

نکته در مورد مجوزهای پرونده:

پرونده slurm.conf باید توسط همه کاربران Slurm قابل خواندن باشد، چرا که توسط بسیاری از دستورات Slurm استفاده می‌شود. سایر پرونده‌هایی که در پرونده slurm.conf تعریف شده‌اند، مانند پرونده‌های لاگ و پرونده‌های حسابداری کارها، ممکن است برای دسترسی موفقیت‌آمیز نیاز به ایجاد شدن/مالکیت توسط کاربر «SlurmUser» داشته باشند. از دستورات «chown» و «chmod» برای تنظیم مناسب مالکیت و مجوزها استفاده کنید. برای اطلاعات درباره پرونده‌ها و دایرکتوری‌های مختلف مورد استفاده توسط Slurm به بخش FILE AND DIRECTORY PERMISSIONS مراجعه کنید.

پارامترهای کلی پیکربندی موجود عبارتند از:

نام ماشین پشتیبان میزبان پایگاه‌داده ذخیره‌سازی حسابداری. در صورت استفاده با پلاگین accounting_storage/slurmdbd، این مکانی است که slurmdbd پشتیبان در آن اجرا خواهد شد. تنها در سامانه‌هایی که از SlurmDBD استفاده می‌کنند به کار می‌رود و در غیر این صورت نادیده گرفته می‌شود.
این پارامتر سطح اعمال محدودیت‌های مبتنی بر انتساب (association-based) را بر روی ارسال کارها کنترل می‌کند. گزینه‌های معتبر شامل هر ترکیبی از موارد زیر به‌صورت جداشده با کاما هستند که بسیاری از آن‌ها به طور ضمنی شامل گزینه‌های دیگر نیز می‌شوند:
به معنای تمام گزینه‌های موجود دیگر به جز nojobs و nosteps است.
هیچ کار جدیدی مجاز به اجرا نیست مگر اینکه یک انتساب (association) متناظر در سامانه وجود داشته باشد.
کاربران می‌توانند بر اساس انتساب، به هر محدودیت اندازه کار یا زمان اجرایی که تعریف شده است محدود شوند. متضمن associations است.
سامانه Slurm هیچ کار یا گامی (step) را در سامانه به حساب نخواهد آورد. متضمن nosteps است.
سامانه Slurm هیچ گامی که اجرا شده است را به حساب نخواهد آورد.
کارها زمان‌بندی نخواهند شد مگر اینکه یک qos معتبر مشخص شده باشد. متضمن associations است.
یک کار تنها در صورتی بر روی یک انتساب یا qos که محدودیت TRES-minutes برای آن تنظیم شده راه‌اندازی می‌شود که بتواند تا پایان اجرا شود. بدون تنظیم این گزینه، کارها تا زمانی که میزان مصرف آن‌ها به حد مجاز TRES-minutes نرسیده باشد راه‌اندازی می‌شوند. این امر می‌تواند منجر به این شود که کارها راه‌اندازی شوند اما پس از رسیدن به حد مجاز کشته (kill) شوند. با این گزینه، کار به دلیل محدودیت‌ها کشته نمی‌شود، حتی اگر محدودیت‌ها پس از شروع کار تغییر کرده باشند و انتساب یا qos محدودیت‌های به‌روزشده را نقض کند. متضمن limits و associations است.
کارها زمان‌بندی نخواهند شد مگر اینکه یک کلید مشخصه بار کاری (workload characterization key) معتبر مشخص شده باشد. متضمن associations و TrackWCKey (یک گزینه پیکربندی مجزا) است.
فهرستی از slurmdbdهای خارجی (<host/ip>[:port][,...]) جدا شده با کاما برای ثبت‌نام در آن‌ها. اگر هیچ پورتی مشخص نشود، از AccountingStoragePort استفاده خواهد شد.

این به خوشه‌های ثبت‌شده در slurmdbd خارجی اجازه می‌دهد با استفاده از گزینه‌های دستور کلاینت --cluster/-M با یکدیگر ارتباط برقرار کنند.

خوشه در صورتی که وجود نداشته باشد، خود را به slurmdbd خارجی اضافه می‌کند. اگر یک خوشه غیرخارجی از قبل در slurmdbd خارجی وجود داشته باشد، slurmctld از ثبت‌نام در slurmdbd خارجی صرف‌نظر می‌کند.

نام ماشینی که میزبان پایگاه‌داده ذخیره‌سازی حسابداری است. تنها در سامانه‌هایی که از SlurmDBD استفاده می‌کنند به کار می‌رود و در غیر این صورت نادیده گرفته می‌شود.
فهرستی از گزینه‌ها که با کاما جدا شده‌اند.
فهرست زیر از گزینه‌های کلید-مقدار (key-value) جدا شده با کاما برای برقراری یک اتصال امن به پایگاه‌داده استفاده می‌شوند:
مسیر پرونده گواهی کلید عمومی کلاینت.
مسیر پرونده گواهی مرجع صدور گواهی (CA).
مسیر دایرکتوری حاوی پرونده‌های گواهی معتبر SSL CA.
مسیر پرونده کلید خصوصی کلاینت.
فهرست رمزهای مجاز برای رمزنگاری SSL.
گذرواژه مورد استفاده برای دسترسی به پایگاه‌داده جهت ذخیره داده‌های حسابداری. تنها برای پلاگین‌های ذخیره‌سازی نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. در صورت استفاده از SlurmDBD (دیمن پایگاه‌داده) با احراز هویت MUNGE، این گزینه می‌تواند طوری پیکربندی شود که از یک دیمن MUNGE استفاده کند که به‌طور خاص برای ارائه احراز هویت بین خوشه‌ها پیکربندی شده است، در حالی که دیمن پیش‌فرض MUNGE احراز هویت درون یک خوشه را فراهم می‌کند. در این حالت، AccountingStoragePass باید پورت نام‌گذاری‌شده‌ای را مشخص کند که برای ارتباط با دیمن MUNGE جایگزین استفاده می‌شود (به عنوان مثال «/var/run/munge/global.socket.2»). مقدار پیش‌فرض NULL است.
پورت شنود سرور پایگاه‌داده ذخیره‌سازی حسابداری. تنها برای پلاگین‌های ذخیره‌سازی نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. مقدار پیش‌فرض SLURMDBD_PORT است که در زمان ساخت سامانه تعیین شده است. اگر هیچ مقداری به‌طور صریح مشخص نشود، روی 6819 تنظیم خواهد شد. این مقدار باید با پارامتر DbdPort در پرونده slurmdbd.conf برابر باشد.
فهرستی از منابع جدا شده با کاما که می‌خواهید در خوشه ردیابی کنید. این‌ها منابعی هستند که توسط کار sbatch/srun هنگام ارسال درخواست می‌شوند. در حال حاضر این شامل هرگونه GRES، BB (بافر انفجاری یا burst buffer) یا مجوز (license) به همراه CPU، Memory، Node، Energy، FS/[Disk|Lustre]، IC/OFED، Pages و VMem است. به‌طور پیش‌فرض Billing، CPU، Energy، Memory، Node، FS/Disk، Pages و VMem ردیابی می‌شوند. این TRESهای پیش‌فرض را نمی‌توان غیرفعال کرد، بلکه فقط می‌توان موارد جدیدی به آن‌ها اضافه نمود. AccountingStorageTRES=gres/craynetwork,license/iop1 منابع billing، cpu، energy، memory، nodes، fs/disk، pages و vmem را به همراه یک gres به نام craynetwork و همچنین مجوزی به نام iop1 ردیابی خواهد کرد. هر زمان که این منابع در خوشه استفاده شوند، ثبت می‌گردند. TRESها با شروع به‌کار slurmctld به‌طور خودکار در پایگاه‌داده تنظیم می‌شوند.

اگر چندین GRES از انواع مختلف ردیابی شوند (مانند GPUهایی از انواع مختلف)، درخواست‌های کار با مشخصات نوع منطبق ثبت خواهند شد. با فرض پیکربندی "AccountingStorageTRES=gres/gpu,gres/gpu:tesla,gres/gpu:volta" آنگاه «gres/gpu:tesla» و «gres/gpu:volta» تنها کارهایی را ردیابی می‌کنند که صراحتاً آن دو نوع GPU را درخواست کرده باشند، در حالی که «gres/gpu» پردازنده‌های گرافیکی (GPU) تخصیص‌یافته از هر نوعی («tesla»، «volta» یا هر نوع GPU دیگر) را ردیابی خواهد کرد.

ردیابی تنها GRESهای نوع‌دار (مثلاً "gres/gpu:tesla,gres/gpu:volta") می‌تواند منجر به رفتارهای غیرمنتظره شود که در آن همتای بدون نوع (مثلاً "gres/gpu") به‌طور ناهماهنگ به عنوان یک نام منبع معتبر شناخته شود. در این حالت، اگر کاری نسخه بدون نوع را درخواست کند، تخصیص منبع آن به عنوان یک نوع خاص ثبت می‌شود که در صورت تخصیص چندین نوع مختلف، ممکن است با نوع واقعی تخصیص‌یافته به کار مطابقت نداشته باشد. بنابراین توصیه می‌شود همیشه همتای بدون نوع را برای هر GRES نوع‌داری که ردیابی می‌شود، ردیابی کنید. علاوه بر این، ممکن است بخواهید از یک پلاگین job_submit استفاده کنید تا کارها را وادار کنید صراحتاً نوعی از GRES را مشخص نمایند.

NOTE: تنظیم gres/gpu همچنین gres/gpumem و gres/gpuutil را تنظیم می‌کند. هنگامی که gres/gpu تنظیم نشده باشد، gres/gpumem و gres/gpuutil را می‌توان به‌طور جداگانه تنظیم کرد.

نوع سازوکار ذخیره‌سازی حسابداری. به‌طور پیش‌فرض تنظیم نشده است، که نشان می‌دهد سوابق حسابداری نگهداری نمی‌شوند.

گزینه‌های فعلی عبارتند از:

سوابق حسابداری در SlurmDBD نوشته خواهند شد که یک پایگاه‌داده MySQL زیربنایی را مدیریت می‌کند. برای اطلاعات بیشتر به «man slurmdbd» مراجعه کنید.
فهرست جدا شده با کاما برای اصلاح اینکه کدام فیلدها توسط slurmctld به پایگاه‌داده حسابداری ارسال شوند.
گزینه‌های فعلی عبارتند از:
گنجاندن فیلد comment کار در پیام تکمیل کار ارسالی به پایگاه‌داده Accounting Storage. توجه داشته باشید که AdminComment و SystemComment همیشه در پایگاه‌داده ثبت می‌شوند.
گنجاندن متغیرهای محیطی کار دسته‌ای (batch job) مورد استفاده در زمان ارسال کار در پیام شروع کار ارسالی به پایگاه‌داده Accounting Storage.
گنجاندن فیلد extra کار در پیام تکمیل کار ارسالی به پایگاه‌داده Accounting Storage.
گنجاندن اسکریپت دسته‌ای (batch script) کار در پیام شروع کار ارسالی به پایگاه‌داده Accounting Storage.
مستثنی کردن مسیرهای stdio هنگام ثبت داده‌ها در پایگاه‌داده در زمان شروع کار یا گام. فیلدهای دیتابیس StdOut، StdErr و StdIn برای کارها و گام‌ها خالی خواهند بود.
بازه نمونه‌برداری پلاگین‌های AcctGather برای حسابداری گره. به ازای مقادیر none برای پلاگین AcctGather، این پارامتر نادیده گرفته می‌شود. برای تمام مقادیر دیگر، این پارامتر تعداد ثانیه‌های بین نمونه‌های حسابداری گره است. برای پلاگین acct_gather_energy/rapl، مقداری کمتر از 300 تنظیم کنید زیرا شمارنده‌ها فراتر از این نرخ ممکن است سرریز شوند (overflow). مقدار پیش‌فرض صفر است. این مقدار نمونه‌برداری حسابداری برای گره‌ها را غیرفعال می‌کند. نکته: بازه نمونه‌برداری حسابداری برای کارها توسط مقدار JobAcctGatherFrequency تعیین می‌شود.
پلاگین مورد استفاده برای حسابداری مصرف انرژی را مشخص می‌کند. پلاگین jobacct_gather و دیمن slurmd این پلاگین را برای جمع‌آوری داده‌های مصرف انرژی برای کارها و گره‌ها فراخوانی می‌کنند. جمع‌آوری داده‌های مصرف انرژی در سطح گره صورت می‌گیرد، بنابراین تنها در صورت تخصیص اختصاصی گره (exclusive job allocation) اندازه‌گیری‌های مصرف انرژی بازتاب‌دهنده مصرف واقعی کار خواهد بود. در صورت اشتراک‌گذاری گره بین کارها، انرژی مصرفی گزارش‌شده برای هر کار (از طریق sstat یا sacct) بازتاب‌دهنده انرژی واقعی مصرف‌شده توسط کارها نخواهد بود. حالت پیش‌فرض این است که چیزی جمع‌آوری نمی‌شود.

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

داده‌های مصرف انرژی از کتابخانه مدیریت GPU (مانند rsmi) برای نوع متناظر پردازنده گرافیکی جمع‌آوری می‌شود. در حال حاضر تنها برای rsmi در دسترس است. نکته: هنگامی که این گزینه تنظیم شده باشد، slurmd پلاگین gpu را پس از پیکربندی در حافظه نگه می‌دارد.
داده‌های مصرف انرژی از کنترلر مدیریت برد پایه (BMC) با استفاده از رابط مدیریت بستر هوشمند (IPMI) جمع‌آوری می‌شود.
داده‌های مصرف انرژی از کنترلر مدیریت برد پایه (BMC) برای سامانه‌های HPE Cray جمع‌آوری می‌شود.
داده‌های مصرف انرژی از حسگرهای سخت‌افزاری با استفاده از سازوکار محدودیت توان میانگین در حال اجرا (RAPL) جمع‌آوری می‌شود. توجه داشته باشید که فعال‌سازی RAPL ممکن است نیازمند اجرای دستور «sudo modprobe msr» باشد.
داده‌های مصرف انرژی از کنترلر Lenovo SD650 XClarity (XCC) با استفاده از دستورات خام IPMI OEM جمع‌آوری می‌شود.
پلاگین مورد استفاده برای حسابداری ترافیک شبکه میان‌اتصال (interconnect) را مشخص می‌کند. پلاگین jobacct_gather و دیمن slurmd این پلاگین را برای جمع‌آوری داده‌های ترافیک شبکه برای کارها و گره‌ها فراخوانی می‌کنند. جمع‌آوری داده‌های ترافیک شبکه در سطح گره صورت می‌گیرد، بنابراین تنها در صورت تخصیص اختصاصی گره، مقادیر جمع‌آوری‌شده بازتاب‌دهنده ترافیک واقعی کار خواهند بود. در صورت اشتراک‌گذاری گره بین کارها، ترافیک شبکه گزارش‌شده برای هر کار (از طریق sstat یا sacct) بازتاب‌دهنده ترافیک شبکه واقعی توسط کارها نخواهد بود.

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

داده‌های ترافیک شبکه Infiniband از شمارنده‌های پایش سخت‌افزاری دستگاه‌های Infiniband از طریق کتابخانه OFED جمع‌آوری می‌شود. به منظور حسابداری ترافیک شبکه به ازای هر کار، TRES با عنوان "ic/ofed" را به AccountingStorageTRES اضافه کنید.
آمار ترافیک شبکه از شبه‌سیستم‌فایل sysfs لینوکس برای رابط‌های خاص تعریف‌شده در acct_gather.conf(5) جمع‌آوری می‌شود. به منظور حسابداری ترافیک شبکه به ازای هر کار، TRES با عنوان "ic/sysfs" را به AccountingStorageTRES اضافه کنید.
پلاگین مورد استفاده برای حسابداری ترافیک سیستم‌فایل را مشخص می‌کند. پلاگین jobacct_gather و دیمن slurmd این پلاگین را برای جمع‌آوری داده‌های ترافیک سیستم‌فایل برای کارها و گره‌ها فراخوانی می‌کنند. جمع‌آوری داده‌های ترافیک سیستم‌فایل در سطح گره صورت می‌گیرد، بنابراین تنها در صورت تخصیص اختصاصی گره، مقادیر جمع‌آوری‌شده بازتاب‌دهنده ترافیک واقعی کار خواهند بود. در صورت اشتراک‌گذاری گره بین کارها، ترافیک سیستم‌فایل گزارش‌شده برای هر کار (از طریق sstat یا sacct) بازتاب‌دهنده ترافیک سیستم‌فایل واقعی توسط کارها نخواهد بود.

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

داده‌های ترافیک سیستم‌فایل Lustre از شمارنده‌های موجود در /proc/fs/lustre/ جمع‌آوری می‌شود. به منظور حسابداری ترافیک lustre به ازای هر کار، TRES با عنوان "fs/lustre" را به AccountingStorageTRES اضافه کنید.
پلاگین مورد استفاده برای پروفایل‌سازی دقیق کار (detailed job profiling) را مشخص می‌کند. پلاگین jobacct_gather و دیمن slurmd این پلاگین را برای جمع‌آوری داده‌های دقیق مانند تعداد I/O، مصرف حافظه یا مصرف انرژی برای کارها و گره‌ها فراخوانی می‌کنند. در این پلاگین رابط‌هایی برای جمع‌آوری داده‌ها در زمان شروع و تکمیل گام، شروع و تکمیل تسک و در فرکانس جمع‌آوری حسابداری وجود دارد. داده‌های جمع‌آوری‌شده در سطح گره تنها در صورت تخصیص اختصاصی گره به کارها مربوط می‌شوند.

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

این گزینه پلاگین HDF5 را فعال می‌کند. دایرکتوری محل ذخیره پرونده‌های پروفایل و اینکه چه مقادیری جمع‌آوری شوند در پرونده acct_gather.conf پیکربندی می‌شوند.
این گزینه پلاگین influxdb را فعال می‌کند. میزبان نمونه influxdb، پورت، پایگاه‌داده، سیاست نگهداری (retention policy) و اینکه چه مقادیری جمع‌آوری شوند در پرونده acct_gather.conf پیکربندی می‌شوند.
اگر روی «YES» تنظیم شود، Slurm به کارهای مجزا اجازه می‌دهد مقدار CoreSpecCount پیکربندی‌شده برای گره را بازنویسی (override) کنند. برای اینکه یک کار از این قابلیت استفاده کند، باید گزینه خط فرمان --core-spec مشخص شود. مقدار پیش‌فرض این گزینه برای سامانه‌های Cray برابر با «YES» و برای سایر انواع سامانه‌ها «NO» است.
فهرست جدا شده با کاما از پلاگین‌های احراز هویت جایگزین که slurmctld برای ارتباط مجاز می‌داند. مقادیر قابل قبول در حال حاضر شامل auth/jwt است.

NOTE: اگر از AuthAltParameters برای تعیین مسیر jwt_hs256.key مورد نیاز استفاده نشود، slurmctld به‌طور پیش‌فرض آن را در StateSaveLocation جستجو می‌کند. پرونده jwt_hs256.key باید فقط برای SlurmUser و root قابل مشاهده باشد. پیشنهاد نمی‌شود که jwt_hs256.key روی گره‌هایی غیر از ماشین اجراکننده slurmctld و ماشین اجراکننده slurmdbd قرار داده شود. auth/jwt را می‌توان با وجود متغیر محیطی SLURM_JWT فعال کرد. در صورت فعال شدن، AuthType پیش‌فرض را بازنویسی می‌کند.

برای تعریف گزینه‌های پلاگین‌های احراز هویت جایگزین استفاده می‌شود. چندین گزینه می‌توانند با کاما جدا شوند.
غیرفعال کردن استفاده از «scontrol token» توسط حساب‌های غیر از SlurmUser.
تنظیم حداکثر طول عمر (به ثانیه) برای هر توکن تولیدشده برای حساب‌های کاربری. این محدودیت برای همه کاربران به جز SlurmUser اعمال می‌شود. مراکزی که مایل به داشتن محدودیت‌های به ازای هر کاربر هستند باید به جای استفاده از scontrol token، با استفاده از ابزارهای سازگار با JWT و/یا یک پروکسی احراز هویت، توکن‌ها را تولید کنند.
مسیر مطلق به پرونده JWKS. کلید باید متعلق به SlurmUser یا root باشد، باید توسط SlurmUser قابل خواندن باشد و دسترسی پیشنهادی آن 0400 است. نباید توسط 'other' قابل نوشتن باشد. تنها کلیدهای RS256 پشتیبانی می‌شوند، اگرچه انواع کلیدهای دیگر ممکن است در پرونده فهرست شده باشند. در صورت تنظیم، هیچ کلید HS256 به‌طور پیش‌فرض بارگذاری نخواهد شد (و تولید توکن غیرفعال می‌شود)، اگرچه تنظیم jwt_key می‌تواند برای فعال‌سازی مجدد صریح استفاده از کلید HS256 (و تولید توکن) استفاده شود.
مسیر مطلق به پرونده کلید JWT. کلید باید HS256 باشد. کلید باید متعلق به SlurmUser یا root باشد، باید توسط SlurmUser قابل خواندن باشد و دسترسی پیشنهادی آن 0400 است. نباید برای 'other' قابل دسترسی باشد. در صورت عدم تنظیم، پرونده کلید پیش‌فرض jwt_hs256.key در StateSaveLocation است.
اجازه دادن به توکن‌های JWT برای داشتن اطلاعات هویتی کامل. در صورت فعال بودن، توکن‌های JWT باید شامل فیلدهای uid و gid باشند. آن‌ها همچنین باید شامل یک کلیم (claim) شناسه (id) با یک شیء JSON باشند که شامل عناصر gecos، dir، shell و gids (آرایه) یا groups (دیکشنری) باشد تا اطلاعات کامل هویت کاربر را فراهم کند. این امر در صورت وجود کلیم‌های معتبر در JWT، جستجوهای سیستمی slurmctld برای اطلاعات کاربر را دور می‌زند. (برای auth/jwt.)
هنگامی که این پرچم تنظیم شود، در صورتی که اطلاعات کامل هویت از کلیم‌های JWT در دسترس نباشد، احراز هویت auth/jwt ناموفق خواهد بود. این گزینه متضمن use_jwt_client_ids است. (برای auth/jwt.)
استفاده از یک فیلد کلیم جایگزین برای فیلد UserName مربوط به Slurm (sun). این گزینه به منظور فراهم کردن سازگاری با توکن‌های تولیدشده در خارج از Slurm طراحی شده است. (این فیلد ممکن است به عنوان grant نیز شناخته شود.)

پیش‌فرض: (غیرفعال)

اطلاعات اضافی مورد استفاده برای احراز هویت ارتباطات بین دیمن‌های Slurm (یعنی slurmctld و slurmd) و کلاینت‌های Slurm. تفسیر این گزینه مختص به AuthType پیکربندی‌شده است. چندین گزینه را می‌توان در یک فهرست جدا شده با کاما مشخص کرد. در صورت عدم تعیین، از اطلاعات احراز هویت پیش‌فرض استفاده خواهد شد.
طول عمر پیش‌فرض اعتبارنامه (credential) گام کار، به ثانیه (مثلاً "cred_expire=1200"). این مدت باید به اندازه کافی طولانی باشد تا محیط کاربر بارگذاری شود، prolog اجرا شود، با صفحه‌بندی (page out) شدن slurmd از حافظه مقابله شود و غیره. این مورد همچنین مدت زمانی را که یک کار در صف دوباره قرار گرفته (requeued) باید قبل از شروع مجدد منتظر بماند کنترل می‌کند. مقدار پیش‌فرض 120 ثانیه است.
مسیر به سوکت دیمن MUNGE جهت استفاده (مثلاً "socket=/var/run/munge/munge.socket.2"). مقدار پیش‌فرض "/var/run/munge/munge.socket.2" است. توسط auth/munge و cred/munge استفاده می‌شود.
طول عمر اعتبارنامه، به ثانیه (مثلاً "ttl=300"). مقدار پیش‌فرض به AuthType استفاده‌شده بستگی دارد. برای auth/munge، مقدار پیش‌فرض به نحوه نصب MUNGE بستگی دارد اما معمولاً 300 ثانیه است. برای auth/slurm، مقدار پیش‌فرض 60 ثانیه است. برای auth/jwt، مقدار پیش‌فرض 1800 ثانیه است.
به پلاگین auth/slurm اجازه می‌دهد تا کاربران را بدون اتکا به اطلاعات کاربری از LDAP یا سیستم‌عامل احراز هویت کند. هنگامی که با nss_slurm همراه شود، اطلاعات کاربر می‌تواند روی گره‌های محاسباتی توسط slurmstepd مدیریت شود. این امر به خوشه اجازه می‌دهد در محیطی کار کند که در آن فقط گره‌های ورود (login nodes) به اطلاعات کاربری LDAP/OS دسترسی دارند. برای اطلاعات بیشتر به https://slurm.schedmd.com/nss_slurm.html مراجعه کنید.

NOTE: برخی از قابلیت‌های Slurm نیازمند احراز هویت کاربر هستند اما تحت پوشش use_client_ids قرار نمی‌گیرند، از جمله:

• پیکربندی پارتیشن با AllowGroups
• ایجاد رزرو با Users
• پارامتر AllowUserBoot در helpers.conf(5)
روش احراز هویت برای ارتباطات بین مؤلفه‌های Slurm. تمام دیمن‌ها و دستورات Slurm باید قبل از تغییر مقدار AuthType خاتمه داده شده و بعداً مجدداً راه‌اندازی شوند. تغییرات در این مقدار باعث اختلال در گام‌های کارهای در حال اجرا شده و از تکمیل آن‌ها جلوگیری می‌کند، بنابراین هنگام تغییر آن نباید هیچ کاری در حال اجرا باشد. برای اطلاعات بیشتر به https://slurm.schedmd.com/authentication.html مراجعه کنید.

مقادیر قابل قبول در حال حاضر:

نشان می‌دهد که MUNGE باید استفاده شود (پیش‌فرض). (برای اطلاعات بیشتر به "https://dun.github.io/munge/" مراجعه کنید).
استفاده از پلاگین احراز هویت داخلی Slurm.
حداکثر زمان (به ثانیه) که یک کار دسته‌ای (batch job) برای راه‌اندازی مجاز است قبل از اینکه مفقود تلقی شده و تخصیص آن آزاد شود. مقدار پیش‌فرض 10 (ثانیه) است. در صورتی که برای اجرای Prolog، بارگذاری متغیرهای محیطی کاربر زمان بیشتری نیاز باشد یا دیمن slurmd از حافظه صفحه‌بندی (paged) شود، ممکن است مقادیر بزرگتری مورد نیاز باشد.
NOTE: آزمایش اینکه آیا یک کار با موفقیت راه‌اندازی شده است تنها زمانی انجام می‌شود که دیمن Slurm در گره محاسباتی وضعیت خود را در دیمن slurmctld روی گره اصلی (head node) ثبت کند، که این اتفاق به ندرت رخ می‌دهد. بنابراین، اگر زمان شروع یک کار از BatchStartTimeout بیشتر شود، کار لزوماً خاتمه نخواهد یافت. این پارامتر پیکربندی همچنین برای راه‌اندازی تسک‌ها و جلوگیری از لغو دستورات srun به دلیل اسکریپت‌های Prolog طولانی‌مدت اعمال می‌شود.
فهرست جدا شده با کاما از مسیرهای دایرکتوری مطلق که هنگام تشخیص خودکار و انتشار (broadcast) وابستگی‌های شیء اشتراکی (shared object) فایل اجرایی از طریق sbcast یا srun --bcast باید مستثنی شوند. کلیدواژه «none» را می‌توان برای نشان دادن اینکه هیچ مسیر دایرکتوری نباید مستثنی شود به کار برد. مقدار پیش‌فرض «/lib,/usr/lib,/lib64,/usr/lib64» است. این گزینه می‌تواند با sbcast --exclude و srun --bcast-exclude بازنویسی شود.
رفتار sbcast و srun --bcast را کنترل می‌کند. چندین گزینه را می‌توان در یک فهرست جدا شده با کاما مشخص کرد. مقادیر پشتیبانی‌شده عبارتند از:
دایرکتوری مقصد برای پرونده‌ای که به گره‌های محاسباتی تخصیص‌یافته منتشر (broadcast) می‌شود. مقدار پیش‌فرض، دایرکتوری کاری فعلی است، یا در صورت تنظیم، --chdir برای srun.
تعیین کتابخانه فشرده‌سازی پرونده پیش‌فرض مورد استفاده. مقادیر پشتیبانی‌شده "lz4" و "none" هستند. مقدار پیش‌فرض با گزینه sbcast --compress برابر "lz4" و در غیر این صورت "none" است. برخی از کتابخانه‌های فشرده‌سازی ممکن است در برخی سامانه‌ها در دسترس نباشند.
در صورت تنظیم، تلاش می‌کند وابستگی‌های شیء اشتراکی فایل اجرایی را به‌طور خودکار تشخیص داده و به گره‌های محاسباتی تخصیص‌یافته منتشر کند. این پرونده‌ها در دایرکتوری در کنار فایل اجرایی قرار می‌گیرند. تنها برای srun، متغیر LD_LIBRARY_PATH نیز به‌طور خودکار به‌روزرسانی می‌شود تا این دایرکتوری حافظه موقت (cache) را شامل شود. این را می‌توان با گزینه --send-libs در sbcast یا srun بازنویسی کرد. به‌طور پیش‌فرض این ویژگی غیرفعال است.
پلاگین مورد استفاده برای مدیریت بافرهای انفجاری (burst buffers). به‌طور پیش‌فرض تنظیم نشده است. مقادیر قابل قبول در حال حاضر عبارتند از:
استفاده از Cray DataWarp API برای ارائه عملکرد بافر انفجاری.
این پلاگین قلاب‌هایی (hooks) به یک API که توسط یک اسکریپت Lua تعریف شده است فراهم می‌کند. این پلاگین توسعه یافته است تا به مدیران سامانه روشی برای انجام هر تسکی (نه فقط صحنه‌آرایی یا file staging پرونده‌ها) در نقاط مختلف چرخه حیات یک کار ارائه دهد.
گزینه‌های جدا شده با کاما که گزینه‌های پلاگین certgen را مشخص می‌کنند. مقادیر پشتیبانی‌شده عبارتند از:
مسیر مطلق به اسکریپت اجرایی برای تولید گواهی خودامضا TLS. کلید خصوصی تولیدشده توسط keygen_script به عنوان stdin ارسال می‌شود و تنها پرونده PEM گواهی باید در stdout چاپ شود. باید در صورت موفقیت مقدار 0 و در صورت خطا مقدار غیرصفر برگرداند.
مسیر مطلق به اسکریپت اجرایی برای تولید کلید خصوصی که بعداً برای تولید گواهی خودامضا استفاده می‌شود. تنها پرونده PEM کلید خصوصی باید در stdout چاپ شود، که بعداً به عنوان stdin به certgen_script ارسال خواهد شد. باید در صورت موفقیت مقدار 0 و در صورت خطا مقدار غیرصفر برگرداند.
پلاگین certgen که استفاده خواهد شد را مشخص می‌کند. مقادیر قابل قبول در حال حاضر:
استفاده از اسکریپت‌های داخلی/پیکربندی‌شده برای تولید جفت‌کلید گواهی.
برای تعریف پارامترهای پلاگین certmgr استفاده می‌شود.
دیمن slurmd/sackd یک گواهی امضاشده جدید را در این بازه زمانی مشخص (به دقیقه) از slurmctld درخواست می‌کند.

پیش‌فرض 1440 دقیقه است (یک بار در روز).

مسیر اسکریپت مورد استفاده برای تولید درخواست‌های امضای گواهی (CSR). نام گره به عنوان یک آرگومان به اسکریپت داده می‌شود. اسکریپت باید تنها پرونده PEM درخواست امضای گواهی را در stdout چاپ کرده و در صورت موفقیت مقدار 0 را برگرداند. در صورت خطا باید مقداری غیرصفر برگرداند.

همراه با certmgr/script الزامی است. تنها توسط دیمن‌هایی اجرا می‌شود که درخواست گواهی می‌دهند.

مسیر اسکریپت مورد استفاده برای دریافت کلید خصوصی گره که برای تولید CSR بازگردانده‌شده توسط generate_csr_script استفاده شده است. نام گره به عنوان یک آرگومان به اسکریپت داده می‌شود. اسکریپت باید کلید خصوصی گره (پرونده PEM) را در stdout چاپ کند. در صورت موفقیت باید 0 و در صورت بروز خطا غیرصفر برگرداند.

همراه با certmgr/script الزامی است. تنها توسط دیمن‌هایی اجرا می‌شود که درخواست گواهی می‌دهند.

مسیر اسکریپت مورد استفاده برای دریافت توکن یکتای گره که توسط slurmctld با استفاده از اسکریپت تنظیم‌شده توسط validate_node_script= اعتبارسنجی می‌شود. نام گره به عنوان یک آرگومان به اسکریپت ارسال می‌شود. اسکریپت باید توکن یکتای گره را در stdout چاپ کرده و در صورت موفقیت مقدار 0 را برگرداند. در صورت بروز خطا باید مقداری غیرصفر برگرداند.

همراه با certmgr/script الزامی است. تنها توسط دیمن‌هایی اجرا می‌شود که درخواست گواهی می‌دهند.

مسیر اسکریپت مورد استفاده برای امضای درخواست‌های امضای گواهی ورودی. این اسکریپت تنها در صورتی فراخوانی می‌شود که validate_node_script= از قبل روی توکن یکتای گره همراه فراخوانی شده باشد و با کد خروج غیرصفر بازگشته باشد. درخواست امضای گواهی (همان‌طور که توسط generate_csr_script= داده شده است) به عنوان یک آرگومان به این اسکریپت ارسال می‌شود. اسکریپت باید گواهی امضاشده جدید را در stdout چاپ کرده و در صورت موفقیت مقدار 0 را برگرداند. در صورت خطا باید مقدار غیرصفر برگرداند.

همراه با certmgr/script الزامی است. تنها توسط slurmctld اجرا می‌شود.

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

همراه با certmgr/script الزامی است. تنها توسط slurmctld اجرا می‌شود.

پلاگین مورد استفاده برای تمدید پویای گواهی‌های TLS برای slurmd/sackd.
از قلاب‌های اسکریپت (script hooks) برای پیاده‌سازی مدیریت گواهی استفاده می‌کند. برای جزئیات در مورد نحوه راه‌اندازی این اسکریپت‌ها، به CertmgrParameters مراجعه کنید.
پارامترهای اضافی برای پلاگین‌های cli_filter. چندین گزینه می‌توانند با ویرگول جدا شوند. مقادیر قابل قبول در حال حاضر عبارتند از:
مسیر مطلق به اسکریپت cli_filter.lua برای استفاده در هنگام فعال بودن cli_filter/lua. اگر این پارامتر تعریف نشود، به جای آن مسیر پیش‌فرض استفاده خواهد شد (همان مسیر slurm.conf).

NOTE: دایرکتوری پیکربندی‌شده حاوی اسکریپت cli_filter.lua باید دارای دسترسی‌های 755 باشد، خود اسکریپت دارای دسترسی 644 باشد و مالکیت هر دو متعلق به SlurmdUser باشد.

فهرستی جداشده با ویرگول از پلاگین‌های فیلتر/تغییر گزینه‌های رابط خط فرمان. پلاگین‌های مشخص‌شده به همان ترتیبی که فهرست شده‌اند اجرا خواهند شد. به‌طور پیش‌فرض از هیچ پلاگین cli_filter استفاده نمی‌شود. مقادیر قابل قبول در حال حاضر عبارتند از:
این پلاگین به شما امکان می‌دهد پیاده‌سازی سفارشی خود را از یک cli_filter با استفاده از lua بنویسید.
این پلاگین ثبت وقایع فعالیت‌های ارسال کار انجام‌شده را فعال می‌کند. تمام گزینه‌های salloc/sbatch/srun همراه با متغیرهای محیطی با فرمت JSON در syslog ثبت می‌شوند. اگر این پلاگین آخرین پلاگین در فهرست نباشد، ممکن است مقادیری متفاوت از آنچه واقعاً به slurmctld ارسال شده است را ثبت کند.
این پلاگین به دنبال فایل $HOME/.slurm/defaults می‌گردد و هر خط آن را به عنوان یک جفت key=value می‌خواند، که در آن key هر یک از گزینه‌های ارسال کار موجود برای salloc/sbatch/srun است و value یک مقدار پیش‌فرض تعریف‌شده توسط کاربر است. به عنوان مثال: 
time=1:30
mem=2048
مورد فوق منجر به یک مقدار پیش‌فرض تعریف‌شده توسط کاربر برای هر یک از کارهای آن‌ها به‌صورت "-t 1:30" و "--mem=2048" می‌شود.
نامی که این کلاستر مدیریت‌شده با Slurm در پایگاه داده حسابداری با آن شناخته می‌شود. این نام برای تفکیک رکوردهای حسابداری زمانی که چندین کلاستر به یک پایگاه داده گزارش می‌دهند، مورد نیاز است. به دلیل محدودیت‌ها در برخی پایگاه‌های داده، هرگونه حروف بزرگ در نام به‌طور خودکار و بدون هشدار به حروف کوچک نگاشت می‌شوند. برای جلوگیری از سردرگمی، توصیه می‌شود که نام با حروف کوچک باشد. نام کلاستر باید ۴۰ کاراکتر یا کمتر باشد تا با محدودیت حداکثر طول نام‌های جدول در MySQL/MariaDB مطابقت داشته باشد.
گزینه‌های جداشده با ویرگول که گزینه‌های ارتباطی را مشخص می‌کنند.
الزام می‌کند که تمام توکن‌های احراز هویت Slurm شامل یک پی‌لود جدیدتر (20.11.9 و 21.08.8) باشند که لایه امنیتی مضاعفی را در برابر حملات بازپخش اعتبارنامه فراهم می‌کند. این گزینه تنها باید زمانی فعال شود که تمام دیمن‌های Slurm به نسخه 20.11.9/21.08.8 یا جدیدتر ارتقا یافته باشند، و تمام کارهایی که پیش از ارتقا شروع شده بودند به پایان رسیده باشند.
جلوگیری از پاسخگویی slurmctld و slurmd به درخواست‌های ورودی HTTP.
غیرفعال کردن عملکرد فقط IPv4 برای تمام دیمن‌های slurm (به‌جز slurmdbd). این مورد همچنین باید در فایل slurmdbd.conf شما تنظیم شود.
فعال کردن استفاده از آدرس‌های IPv6 برای تمام دیمن‌های slurm (به‌جز slurmdbd). هنگام استفاده از هر دو پروتکل IPv4 و IPv6، اولویت‌های خانواده آدرس بر اساس فایل /etc/gai.conf شما خواهد بود. این مورد همچنین باید در فایل slurmdbd.conf شما تنظیم شود.
هنگامی که از munge به عنوان AuthType استفاده می‌شود، slurmctld از getnameinfo برای به دست آوردن نام میزبان از آدرس IP ذخیره‌شده در اعتبارنامه munge استفاده می‌کند. این پارامتر تعداد ثانیه‌هایی را کنترل می‌کند که slurmctld باید تفکیک آدرس IP به نام میزبان را در حافظه پنهان (کش) نگه دارد. اگر روی 0 تنظیم شود، کش غیرفعال می‌شود. مقدار پیش‌فرض 60 است.
این مورد بر اتصالات بین srun و فرآیند slurmstepd آن و همچنین تمام اتصالات به slurmdbd تأثیر می‌گذارد. پیش‌فرض، استفاده از تنظیمات پیش‌فرض سیستم است.
این مورد بر اتصالات بین srun و فرآیند slurmstepd آن و همچنین تمام اتصالات به slurmdbd تأثیر می‌گذارد. پیش‌فرض، استفاده از تنظیمات پیش‌فرض سیستم است.
این مورد بر اتصالات بین srun و فرآیند slurmstepd آن و همچنین تمام اتصالات به slurmdbd تأثیر می‌گذارد. از مقادیر بزرگتر می‌توان برای بهبود قابلیت اطمینان ارتباطات در صورت بروز خرابی‌های شبکه استفاده کرد. حالت پیش‌فرض غیرفعال بودن keepalive است.
برای اتصال مستقیم (bind) به آدرسی استفاده می‌شود که نود به عنوان محل اجرای slurmctld به آن تفکیک می‌شود، به جای اتصال پیام‌ها به هر آدرسی روی نود، که حالت پیش‌فرض است.
برای اتصال مستقیم (bind) به آدرسی استفاده می‌شود که نود به آن تفکیک می‌شود، به جای اتصال پیام‌ها به هر آدرسی روی نود که حالت پیش‌فرض است. این گزینه برای تمام دیمن‌ها/کلاینت‌ها به جز slurmctld است.
مدت زمان انتظار بر حسب ثانیه، هنگامی که هر کاری در کلاستر در وضعیت COMPLETING است، پیش از آنکه کارهای دیگری زمان‌بندی شوند. این پارامتر در سطح زمان‌بندی کلاستر ارزیابی می‌شود، نه به ازای هر نود. هدف از این کار تلاش برای نگه‌داشتن کارها روی نودهایی است که اخیراً مورد استفاده بوده‌اند، با هدف جلوگیری از تکه‌تکه شدن منابع (fragmentation). اگر روی صفر تنظیم شود، کارهای معلق در اسرع وقت شروع خواهند شد. از آنجا که منابع یک کار در وضعیت COMPLETING به محض تکمیل Epilog در هر نود برای استفاده کارهای دیگر آزاد می‌شود، این امر می‌تواند منجر به تخصیص‌های بسیار تکه‌تکه شده منابع شود. برای ارائه حداقل زمان پاسخگویی به کارها، مقدار صفر توصیه می‌شود (بدون انتظار). برای به حداقل رساندن تکه‌تکه شدن منابع، مقداری معادل KillWait به علاوه دو توصیه می‌شود. در این حالت، تنظیم KillWait روی یک مقدار کوچک ممکن است مفید باشد. مقدار پیش‌فرض CompleteWait صفر ثانیه است. مقدار نمی‌تواند از 65533 تجاوز کند.

این پارامتر این واقعیت را لغو نمی‌کند که نودها در وضعیت COMPLETING واجد شرایط زمان‌بندی کار نیستند. نودها قرارگیری کارهای جدید را قبول نخواهند کرد تا زمانی که Epilog آن‌ها تکمیل شود و وضعیت COMPLETING را ترک کنند، حتی اگر CompleteWait روی صفر تنظیم شده باشد.

NOTE: تنظیم reduce_completing_frag بر رفتار CompleteWait تأثیر می‌گذارد.

گاورنر پیش‌فرض CPU برای استفاده در هنگام اجرای یک مرحله کار (job step) در صورتی که به‌طور صریح با گزینه --cpu-freq تنظیم نشده باشد. مقادیر قابل قبول در حال حاضر شامل یکی از گاورنرهای زیر است:
تلاش می‌کند از گاورنر CPU نوع Conservative استفاده کند
تلاش می‌کند از گاورنر CPU نوع OnDemand استفاده کند
تلاش می‌کند از گاورنر CPU نوع Performance استفاده کند
تلاش می‌کند از گاورنر CPU نوع PowerSave استفاده کند
پیش‌فرض: استفاده از پیش‌فرض سیستم. در صورتی که گزینه --cpu-freq مشخص نشده باشد، هیچ تلاشی برای تنظیم گاورنر انجام نمی‌شود.
فهرست گاورنرهای فرکانس CPU که مجاز هستند با گزینه --cpu-freq در salloc، sbatch یا srun تنظیم شوند. مقادیر قابل قبول در حال حاضر عبارتند از:
تلاش می‌کند از گاورنر CPU نوع Conservative استفاده کند
تلاش می‌کند از گاورنر CPU نوع OnDemand استفاده کند (یک مقدار پیش‌فرض)
تلاش می‌کند از گاورنر CPU نوع Performance استفاده کند (یک مقدار پیش‌فرض)
تلاش می‌کند از گاورنر CPU نوع PowerSave استفاده کند
تلاش می‌کند از گاورنر CPU نوع SchedUtil استفاده کند
تلاش می‌کند از گاورنر CPU نوع UserSpace استفاده کند (یک مقدار پیش‌فرض)
پیش‌فرض: OnDemand، Performance و UserSpace.
ابزار امضای رمزنگاری که باید در ایجاد اعتبارنامه‌های مرحله کار استفاده شود. مقادیر قابل قبول در حال حاضر عبارتند از:
نشان می‌دهد که باید از Munge استفاده شود (پیش‌فرض).
استفاده از فرمت اعتبارنامه داخلی Slurm.
اعمال مقدار پیش‌فرض برای پارامترهای پلاگین data_parser. آرگومان‌های --json یا --yaml را در sacct(1)، scontrol(1)، sinfo(1)، squeue(1)، sacctmgr(1)، sdiag(1) و sshare(1) ببینید.
پیش‌فرض: آخرین نسخه پلاگین data_parser بدون پرچم‌های انتخاب‌شده.
زیرسیستم‌های خاصی را تعریف می‌کند که باید ثبت وقایع دقیق‌تری از رویدادها را ارائه دهند. چندین زیرسیستم می‌توانند با جداکننده‌های ویرگول مشخص شوند. بیشتر DebugFlags در صورتی که SlurmctldDebug در سطح 'verbose' یا بالاتر باشد، منجر به پیام‌های ثبت وقایع اضافی برای زیرسیستم‌های مشخص‌شده خواهند شد. ثبت وقایع بیشتر ممکن است بر کارایی تأثیر بگذارد.

NOTE: همچنین می‌توانید فلگ‌های دیباگ را با تعریف متغیر محیطی SLURM_DEBUG_FLAGS با فلگ‌های مورد نظر در هنگام راه‌اندازی فرآیند (دستور کلاینت، دیمن و غیره) تنظیم کنید. متغیر محیطی بر تنظیمات موجود در slurm.conf اولویت دارد.

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

جزئیات حسابداری شمارنده‌های تجمیعی (Accrue counters)
عامل‌های RPC (RPCهای خروجی از دیمن‌های Slurm)
برای تمام RPCهای ورودی به slurmctld، آدرس مبدأ، کاربر احراز هویت شده و نوع RPC را پیش از پردازش اتصال چاپ می‌کند.
چاپ گواهی‌های TLS در حال استفاده
جزئیات زمان‌بند پس‌پرکننده (Backfill scheduler)
زمان‌بند پس‌پرکننده برای ثبت یک نگاشت بسیار باجزئیات از منابع رزروشده در طول زمان. برای داشتن دیدی کامل و باجزئیات از عملکرد زمان‌بند پس‌پرکننده با Backfill ترکیب شود.
پلاگین بافر انفجاری (Burst Buffer)
جزئیات Cgroup
جزئیات مدیر اتصال (Connection manager)
جزئیات مقیدسازی CPU برای کارها و مراحل
جزئیات فرکانس CPU برای کارها و مراحل با استفاده از گزینه --cpu-freq.
جزئیات ساختار داده عمومی.
عامل RPC (RPCهای خروجی به DBD)
اطلاعات دیباگ وابستگی کار
اطلاعات دیباگ Elasticsearch (منسوخ شده). نام مستعار JobComp.
اطلاعات دیباگ AcctGatherEnergy
اطلاعات دیباگ زمان‌بندی فدراسیون
جزئیات منبع عمومی (Generic resource)
جزئیات کارهای ناهمگن (Heterogeneous job)
جزئیات زمان‌بندی گروهی (Gang scheduling)
پیام خطای نمادهای "*" در فایل‌های conf را نمایش ندهد.
جزئیات عمومی جمع‌آوری حسابداری کار (مختص به یک پلاگین خاص نیست).
جزئیات پلاگین تکمیل کار (Job Completion)
جزئیات مدیریت مجوز (License)
جزئیات پلاگین فضای نام (Namespace)
جزئیات پلاگین متریک‌ها (Metrics)
جزئیات شبکه. Warning: فعال کردن این فلگ ممکن است باعث ثبت رمزهای عبور، توکن‌ها یا سایر اعتبارنامه‌های احراز هویت در لاگ شود.
تخلیه مقادیر خام هگزادسیمال ارتباطات کلیدی شبکه. Warning: این فلگ باعث ثبت لاگ‌های بسیار حجیم شده و ممکن است باعث ثبت گذرواژه‌ها، توکن‌ها یا سایر اعتبارنامه‌های احراز هویت شود.
اطلاعات دیباگ پلاگین ویژگی‌های نود (Node Features)
عدم ثبت پیام در لاگ زمانی که فایل‌های slurm.conf بین دیمن‌های Slurm متفاوت هستند
جزئیات پلاگین مدیریت مصرف برق و ذخیره انرژی (برنامه‌های تعلیق/ازسرگیری suspend/resume)
اولویت‌بندی کارها
جزئیات پلاگین‌های AcctGatherProfile
جزئیات پروتکل ارتباطی
رزروهای پیشرفته (Advanced reservations)
اطلاعات دیباگ فوروارد پیام
اطلاعات دیباگ مربوط به هر اسکریپت فراخوانی‌شده توسط Slurm. این شامل اسکریپت‌های اجراشده توسط slurmctld مانند PrologSlurmctld و EpilogSlurmctld می‌شود.
پلاگین انتخاب منبع
تخصیص منابع slurmctld برای مراحل کار
پلاگین سوییچ
مدیریت ریسه‌ها (تردها) و کارها.
پلاگین TLS
ردیابی کارها در slurmctld. این فلگ اطلاعات دقیق کار شامل وضعیت، شناسه‌های کار و شمارنده نودهای تخصیص‌یافته را چاپ می‌کند.
تریگرهای slurmctld
تعداد پیش‌فرض CPUهای تخصیص‌یافته به ازای هر GPU تخصیص‌یافته. این مقدار تنها در صورتی استفاده می‌شود که کار گزینه‌های --cpus-per-task و --cpus-per-gpu را مشخص نکرده باشد.
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر CPU تخصیص‌یافته قابل استفاده بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه (over-subscribing) و ایجاد صفحه‌بندی (paging) استفاده می‌شود. عموماً اگر پردازنده‌های مجزا به کارها تخصیص داده شوند (SelectType=select/cons_tres)، از DefMemPerCPU استفاده می‌شود. مقدار پیش‌فرض 0 (نامحدود) است. همچنین به DefMemPerGPU، DefMemPerNode و MaxMemPerCPU مراجعه کنید. DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.

NOTE: این مورد برای CPUهای تخصیص‌یافته قابل استفاده در یک تخصیص کار اعمال می‌شود. این نکته زمانی مهم است که بیش از یک ریسه (thread) به ازای هر هسته پیکربندی شده باشد. اگر کاری --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
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر GPU تخصیص‌یافته بر حسب مبی‌بایت. مقدار پیش‌فرض 0 (نامحدود) است. لطفاً توجه داشته باشید که حداکثر تلاش (best effort) برای پیش‌بینی اینکه کدام GPUها در سیستم استفاده خواهند شد انجام می‌شود، اما این ممکن است بین زمان ارسال کار و زمان شروع تغییر کند و باعث شود که MaxMemPerNode احتمالاً همانطور که برای کارهای ناهمگن انتظار می‌رود کار نکند. همچنین به DefMemPerCPU و DefMemPerNode مراجعه کنید. DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر نود تخصیص‌یافته بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. عموماً اگر کل نودها به کارها تخصیص داده شوند (SelectType=select/linear) و منابع بیش از حد تخصیص داده شوند (OverSubscribe=yes یا OverSubscribe=force)، از DefMemPerNode استفاده می‌شود. مقدار پیش‌فرض 0 (نامحدود) است. همچنین به DefMemPerCPU، DefMemPerGPU و MaxMemPerCPU مراجعه کنید. DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.
چندین گزینه می‌توانند با ویرگول جدا شوند.
به‌طور پیش‌فرض، هنگامی که یک کار فدراسیونی دارای وابستگی تکین است، هر کلاستر در فدراسیون باید پیش از آنکه وابستگی تکین کار برآورده‌شده تلقی شود، آن را برطرف کند. فعال کردن این گزینه به این معنی است که فقط کلاستر مبدأ باید وابستگی تکین را پاک کند. این گزینه باید در تمام کلاسترهای موجود در فدراسیون تنظیم شود.
اگر کاری وابستگی نامعتبر داشته باشد و هرگز نتواند اجرا شود، آن را خاتمه داده و وضعیت آن را روی JOB_CANCELLED تنظیم می‌کند. به‌طور پیش‌فرض، کار با دلیل DependencyNeverSatisfied در حالت معلق باقی می‌ماند.
اگر روی "YES" تنظیم شود، از اجرای هرگونه کار توسط کاربر root جلوگیری خواهد شد. مقدار پیش‌فرض "NO" است، به این معنی که کاربر root قادر به اجرای کارها خواهد بود. DisableRootJobs همچنین می‌تواند به ازای هر پارتیشن تنظیم شود.
تعداد ثانیه‌هایی که srun منتظر می‌ماند تا slurmstepd اتصال TCP/IP مورد استفاده برای رله داده بین برنامه کاربر و srun را هنگام خاتمه برنامه کاربر ببندد. مقدار پیش‌فرض ۶۰ ثانیه است. نمی‌تواند از 65533 تجاوز کند.
کنترل می‌کند که آیا محدودیت‌های پارتیشن هنگام ارسال کار به کلاستر اعمال شوند یا خیر. محدودیت‌های پارتیشن که توسط این گزینه در نظر گرفته می‌شوند عبارتند از MaxMemPerCPU، MaxMemPerNode، MinNodes، MaxNodes، MaxTime، AllocNodes، AllowAccounts، AllowGroups، AllowQOS پیکربندی‌شده و آستانه استفاده از QOS. همچنین بررسی می‌کند که آیا کار نودهای بیشتری از آنچه در پارتیشن وجود دارد درخواست می‌کند یا خیر. اگر تنظیم شود، کار و QOS کاری که از محدودیت‌های پارتیشن فراتر روند، قابل ارسال نخواهند بود.
کارهایی که از تعداد نودهای یک پارتیشن و/یا هر یک از محدودیت‌های پیکربندی‌شده آن فراتر روند، در زمان ارسال رد خواهند شد. اگر کار به چندین پارتیشن ارسال شود، کار باید محدودیت‌های تمام پارتیشن‌های درخواستی را برآورده کند.
کارها در صورتی پذیرفته می‌شوند که محدودیت‌های حداقل یکی از پارتیشن‌های درخواستی را برآورده کنند.
محدودیت‌های پارتیشن در زمان ارسال اعمال نمی‌شوند، اما همچنان در طول زمان‌بندی اعمال خواهند شد. این شامل کارهایی می‌شود که نودهای بیشتری از تعداد موجود در هر یک از پارتیشن‌ها درخواست می‌کنند، بنابراین کارها می‌توانند به پارتیشن‌های خالی ارسال شوند. کاری که از محدودیت‌های تمام پارتیشن‌های درخواستی فراتر رود، تا زمانی که محدودیت‌های پارتیشن تغییر نکند، در صف باقی خواهد ماند. این مقدار پیش‌فرض است.
نام مسیر برنامه‌ای برای اجرا به عنوان کاربر root در هر نود هنگامی که کار کاربر تکمیل می‌شود (مانند "/usr/local/slurm/epilog"). اگر این یک نام مسیر مطلق نباشد (یعنی با اسلش شروع نشود)، باید نسبت به دایرکتوری حاوی فایل slurm.conf باشد. یک الگوی glob (به glob (7) مراجعه کنید) نیز ممکن است برای اجرای بیش از یک اسکریپت epilog استفاده شود (مانند "/etc/slurm/epilog.d/*"). هنگامی که بیش از یک اسکریپت epilog پیکربندی شده باشد، آن‌ها به ترتیب الفبایی معکوس (z-a -> Z-A -> 9-0) اجرا می‌شوند. اسکریپت(های) Epilog ممکن است برای پاکسازی فایل‌ها، غیرفعال کردن ورود کاربر و غیره استفاده شوند. به‌طور پیش‌فرض هیچ epilog وجود ندارد. برای اطلاعات بیشتر به Prolog and Epilog Scripts مراجعه کنید.

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

NOTE: پیکربندی چندین اسکریپت epilog با گنجاندن این گزینه در چندین خط امکان‌پذیر است.

تعداد میکروثانیه‌هایی که دیمن slurmctld برای پردازش یک پیام تکمیل epilog از دیمن‌های slurmd نیاز دارد. برای کارهایی که بیش از ۶۴ نود را در بر می‌گیرند، هر میزبان پیام خود را بر اساس شاخص خود در فهرست نودهای کار و این مقدار به تأخیر می‌اندازد و از هجوم همزمان RPCها که می‌تواند منجر به از دست رفتن پیام‌ها شود، جلوگیری می‌کند. مقدار پیش‌فرض 2000 میکروثانیه است. حداکثر مقدار 1000000 (۱ ثانیه) است. مقادیر فراتر از حداکثر به مقدار پیش‌فرض بازنشانی می‌شوند. برای یک کار ۱۰۰۰ نودی، مقدار پیش‌فرض پیام‌های تکمیل epilog را در طول دو ثانیه پخش می‌کند.
نام مسیر کامل و معتبر برنامه‌ای برای اجرای slurmctld هنگام خاتمه تخصیص کار (مانند "/usr/local/slurm/epilog_controller"). این برنامه به عنوان SlurmUser اجرا می‌شود که به آن اجازه می‌دهد در صورت بروز خطا، نودها را تخلیه کرده و کار را مجدداً در صف قرار دهد (به scontrol(1) مراجعه کنید). اینکه برنامه دقیقاً چه کاری انجام می‌دهد و چگونه این کار را انجام می‌دهد، کاملاً به صلاحدید مدیر سیستم است. اطلاعات مربوط به کار در حال راه‌اندازی، نودهای تخصیص‌یافته به آن و غیره با استفاده از متغیرهای محیطی به برنامه منتقل می‌شوند. برای اطلاعات بیشتر به Prolog and Epilog Scripts مراجعه کنید.

NOTE: پیکربندی چندین اسکریپت epilog با گنجاندن این گزینه در چندین خط امکان‌پذیر است.

فاصله زمانی بر حسب ثانیه که Slurm پیش از پایان دادن به برنامه‌های Epilog منتظر می‌ماند. مقدار پیش‌فرض PrologEpilogTimeout است. این فاصله زمانی برای Epilog اجرا شده توسط دیمن slurmd پس از پایان کار، EpilogSlurmctld اجرا شده توسط دیمن slurmctld، و فراخوانی epilog پلاگین SPANK یعنی slurm_spank_job_epilog اعمال می‌شود.
اگر زمان Epilog یا slurm_spank_job_epilog به پایان برسد (time out)، گره تخلیه (drained) می‌شود. در تمامی موارد، خطاها ثبت (log) می‌شوند.
تعدیل اثر فراتر رفتن از سهم عادلانه (fair share) منابع تخصیص‌یافته توسط یک کاربر یا گروه. مقادیر بالاتر توانایی بیشتری برای تمایز قائل شدن بین فراتر رفتن از سهم عادلانه در سطوح بالا فراهم می‌کنند (برای مثال، مقدار 1 منجر به تفاوت ناچیزی بین مصرف بیش از حد با ضریب 10 و 100 می‌شود، در حالی که مقدار 5 منجر به تفاوت چشمگیری در اولویت خواهد شد). مقدار پیش‌فرض 1 است.
برای تعریف گزینه‌های فدراسیون استفاده می‌شود. چندین گزینه می‌توانند با کاما از هم جدا شوند.
اگر تنظیم شود، دستورهای وضعیت کلاینت (مانند squeue، sinfo، sprio و غیره) اطلاعات را به‌طور پیش‌فرض در یک نمای فدراسیونی نمایش می‌دهند. این گزینه از نظر عملکردی معادل استفاده از گزینه --federation در هر دستور است. برای لغو نمای فدراسیونی و دریافت یک نمای محلی از کلاستر مشخص‌شده، از گزینه --local کلاینت استفاده کنید.

به دستورهای کلاینت اجازه می‌دهد حتی زمانی که slurmdbd غیرفعال است، با بازیابی رکوردهای کلاستر از slurmctld، از گزینه --cluster استفاده کنند.

شناسه کاری (job id) که برای نخستین کار ارسال‌شده به Slurm استفاده می‌شود. شناسه‌های تولیدشده برای هر کار بعدی 1 واحد افزایش می‌یابند. مقدار باید بزرگ‌تر از 0 باشد. مقدار پیش‌فرض 1 است. همچنین نگاه کنید به MaxJobId
فهرستی جداشده با کاما از منابع عمومی (generic resources) که باید مدیریت شوند (مانند GresTypes=gpu,mps). این منابع ممکن است یک پلاگین GRES مرتبط با همان نام داشته باشند که قابلیت‌های اضافی را فراهم می‌کند. به‌طور پیش‌فرض هیچ منبع عمومی مدیریت نمی‌شود. برای عملکرد صحیح، اطمینان حاصل کنید که این پارامتر در تمامی گره‌های کلاستر یکسان و سازگار باشد.
اگر روی یک مقدار غیر صفر تنظیم شود، اطلاعات مربوط به این‌که کدام کاربران عضو گروه‌های مجاز برای استفاده از یک پارتیشن هستند، به‌طور دوره‌ای به‌روزرسانی می‌شود، حتی اگر تغییری در پرونده /etc/group ایجاد نشده باشد. اگر روی صفر تنظیم شود، اطلاعات اعضای گروه تنها پس از به‌روزرسانی پرونده /etc/group به‌روز خواهد شد. مقدار پیش‌فرض 1 است. همچنین پارامتر GroupUpdateTime را ببینید.
کنترل می‌کند که اطلاعات مربوط به این‌که کدام کاربران عضو گروه‌های مجاز برای استفاده از یک پارتیشن هستند هر چند وقت یک‌بار به‌روزرسانی شود، و فهرست‌های عضویت گروه کاربری چه مدت کش (cache) شوند. فاصله زمانی بر حسب ثانیه مشخص می‌شود و مقدار پیش‌فرض آن 600 ثانیه است. مقدار صفر از به‌روزرسانی دوره‌ای اطلاعات عضویت در گروه جلوگیری می‌کند. همچنین پارامتر GroupUpdateForce را ببینید.
فرکانس پیش‌فرض GPU برای استفاده هنگام اجرای یک گام کاری (job step) در صورتی که با استفاده از گزینه --gpu-freq به‌طور صریح تنظیم نشده باشد. این گزینه می‌تواند برای پیکربندی مستقل فرکانس‌های GPU و حافظه آن استفاده شود. هیچ مقدار پیش‌فرضی وجود ندارد. در صورت عدم تنظیم و عدم تعیین گزینه --gpu-freq، تلاشی برای تغییر فرکانس GPU صورت نمی‌گیرد. پس از اتمام کار، فرکانس‌های تمام GPUهای متأثر به بالاترین مقادیر ممکن بازنشانی خواهند شد. در برخی موارد، محدودیت‌های توان مصرفی سیستم (power caps) ممکن است مقادیر درخواستی را لغو و بازنویسی کنند. فیلد type می‌تواند "memory" باشد. اگر type مشخص نشود، فرکانس GPU در نظر گرفته می‌شود. فیلد value می‌تواند یکی از مقادیر "low"، "medium"، "high"، "highm1" یا یک مقدار عددی بر حسب مگاهرتز (MHz) باشد. اگر مقدار عددی مشخص‌شده امکان‌پذیر نباشد، مقداری تا حد امکان نزدیک به آن استفاده خواهد شد. برای تعاریف مقادیر به بخش زیر مراجعه کنید. نمونه‌های استفاده شامل "GpuFreqDef=medium,memory=high" و "GpuFreqDef=450" هستند.

تعاریف مقادیر (value) پشتیبانی‌شده:

پایین‌ترین فرکانس موجود.
تلاش برای تنظیم فرکانس در میانه محدوده موجود.
بالاترین فرکانس موجود.
(high منهای یک) فرکانس بعدی پس از بالاترین فرکانس موجود را انتخاب می‌کند.
نوع پلاگین هش مورد استفاده برای ارتباطات شبکه را مشخص می‌کند. مقادیر قابل قبول عبارتند از:
هش‌ها توسط تابع هش رمزنگاری KangarooTwelve تولید می‌شوند. این مقدار پیش‌فرض است.
هش‌ها توسط تابع هش رمزنگاری SHA-3 تولید می‌شوند.

NOTE: اطمینان حاصل کنید که HashPlugin هم در slurm.conf و هم در slurmdbd.conf مقدار یکسانی داشته باشد.

فاصله زمانی بر حسب ثانیه بین اجراهای HealthCheckProgram. مقدار پیش‌فرض صفر است که اجرا را غیرفعال می‌کند.
مشخص می‌کند که گره‌ها در چه وضعیت‌هایی باید HealthCheckProgram را اجرا کنند. می‌توان چندین وضعیت را با کاما جدا کرد، به استثنای وضعیت‌های *_ONLY. مقدار پیش‌فرض ANY است تا روی گره‌ها در هر وضعیتی اجرا شود.
روی گره‌های در وضعیت ALLOC (تمام CPUها تخصیص یافته‌اند) اجرا شود.
روی گره‌ها در هر وضعیتی اجرا شود.
به جای اجرای برنامه بررسی سلامت روی همه گره‌ها به صورت هم‌زمان، اجرای آن به صورت چرخشی روی تمام گره‌های محاسباتی در طول مدت زمان HealthCheckInterval انجام می‌شود. می‌تواند با گزینه‌های مختلف وضعیت گره ترکیب شود.
روی گره‌های در وضعیت IDLE (بیکار) اجرا شود.
روی گره‌هایی اجرا شود که در وضعیت IDLE هستند و DRAINED (تخلیه شده) نیستند.
روی گره‌های در وضعیت MIXED (برخی از CPUها بیکار و برخی دیگر تخصیص یافته‌اند) اجرا شود.
تنها پس از راه‌اندازی مجدد (reboot) گره اجرا شود. این وضعیت با هر وضعیت دیگری ناسازگار و مانعة‌الجمع است.
تنها هنگام راه‌اندازی slurmd اجرا شود. این وضعیت با هر وضعیت دیگری ناسازگار و مانعة‌الجمع است.
مسیر کامل اسکریپتی که باید به‌طور دوره‌ای توسط کاربر root روی تمام گره‌های محاسباتی که در وضعیت NOT_RESPONDING نیستند اجرا شود. این برنامه می‌تواند برای اطمینان از عملکرد کامل گره و تخلیه (DRAIN) گره یا ارسال ایمیل در صورت شناسایی مشکل استفاده شود. هر اقدامی که باید انجام شود باید صریحاً توسط خود برنامه صورت گیرد (برای نمونه، اجرای "scontrol update NodeName=foo State=drain Reason=tmp_file_system_full" جهت تخلیه یک گره). فاصله زمانی اجرا با استفاده از پارامتر HealthCheckInterval کنترل می‌شود. توجه داشته باشید که HealthCheckProgram به‌طور هم‌زمان روی تمام گره‌ها اجرا خواهد شد تا تأثیر آن بر برنامه‌های موازی به حداقل برسد. این برنامه در صورتی که ظرف 60 ثانیه به‌طور عادی خاتمه نیابد، متوقف (kill) خواهد شد. این برنامه همچنین هنگامی که دیمن slurmd برای نخستین بار راه‌اندازی می‌شود و پیش از ثبت نام در دیمن slurmctld اجرا خواهد شد. اگر HealthCheckNodeState برابر با START_ONLY یا REBOOT_ONLY باشد، تنها هنگامی اجرا می‌شود که دیمن slurmd برای نخستین بار راه‌اندازی شود یا هنگامی که slurmd پس از راه‌اندازی مجدد گزارش دهد. به‌طور پیش‌فرض هیچ برنامه‌ای اجرا نخواهد شد.
مدت زمان بر حسب ثانیه که HealthCheckProgram مجاز به اجرا است. مقدار پیش‌فرض 60 است. HealthCheckTimeout باید کمتر از HealthCheckInterval باشد؛ در غیر این صورت خطا لاگ می‌شود. مقدار 0 مجاز نیست و به مقدار پیش‌فرض بازنشانی می‌شود. حداکثر مقدار 65535 است.
پیاده‌سازی http_parser مورد استفاده را مشخص می‌کند. در صورت وجود، مقدار پیش‌فرض http_parser/libhttp_parser است، در غیر این صورت http_parser/llhttp_parser خواهد بود. مقادیر قابل قبول در حال حاضر عبارتند از:
استفاده از پلاگین مبتنی بر libhttp_parser.
استفاده از پلاگین مبتنی بر llhttp.
فاصله زمانی، بر حسب ثانیه، که پس از آن یک دستور تخصیص کار پاسخ‌نداده (non-responsive) (مانند srun یا salloc) منجر به خاتمه کار خواهد شد. اگر گره‌ای که دستور روی آن اجرا می‌شود دچار خرابی شود یا دستور به‌طور غیرعادی خاتمه یابد، این امر تخصیص کار آن را پایان می‌دهد. این گزینه هیچ تأثیری بر کارهای دسته‌ای (batch jobs) ندارد. هنگام تنظیم مقدار، توجه داشته باشید که یک دیباگر که از srun برای راه‌اندازی یک برنامه استفاده می‌کند ممکن است دستور srun را برای مدت طولانی در حالت متوقف‌شده (stopped) رها کند. این محدودیت برای کارهایی که در پارتیشن‌هایی با پرچم فعال RootOnly اجرا می‌شوند نادیده گرفته می‌شود (زمان‌بند که به عنوان root اجرا می‌شود مسئول کار خواهد بود). مقدار پیش‌فرض نامحدود (صفر) است و نباید از 65533 ثانیه بیشتر باشد.
هنگامی که LaunchParameters=use_interactive_step فعال باشد، اجرای salloc به‌طور خودکار یک فرایند srun را با InteractiveStepOptions آغاز می‌کند تا یک ترمینال را روی یک گره در تخصیص کار راه‌اندازی کند. مقدار پیش‌فرض "--interactive --preserve-env --pty $SHELL" است. گزینه "--interactive" عمداً در صفحه راهنمای srun مستند نشده است. این گزینه فقط برای استفاده در InteractiveStepOptions در نظر گرفته شده است تا یک «گام تعاملی» (interactive step) ایجاد کند که منابعی مصرف نمی‌کند تا گام‌های دیگر بتوانند به صورت موازی با گام تعاملی اجرا شوند.
پلاگین JobAcctGather اطلاعات مربوط به میزان استفاده از حافظه، CPU، ورودی/خروجی (I/O)، اتصال متقابل (interconnect)، انرژی و GPU را در سطح وظیفه (task)، بسته به این‌که کدام پلاگین‌ها در Slurm پیکربندی شده‌اند، جمع‌آوری می‌کند. این پارامتر نحوه جمع‌آوری برخی از این معیارها را کنترل خواهد کرد. به‌طور پیش‌فرض تنظیم‌نشده (unset) است.

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

آمار CPU و حافظه را با خواندن رابط‌های دایرکتوری cgroup وظیفه (مانند memory.stat، cpu.stat) از طریق فراخوانی CgroupPlugin پیکربندی‌شده جمع‌آوری می‌کند (نگاه کنید به "man cgroup.conf"). این سازوکار پارامترهای JobAcctGatherParams=UsePSS یا NoShared را نادیده می‌گیرد زیرا این موارد تنها هنگام خواندن میزان مصرف حافظه از فایل‌سیستم proc استفاده می‌شوند.
آمار CPU و حافظه را با خواندن procfs جمع‌آوری می‌کند. این پلاگین تمام pidهای وظیفه را دریافت کرده و برای هر کدام از آن‌ها /proc/<pid>/stats را می‌خواند. اگر UsePSS تنظیم شده باشد، /proc/<pid>/smaps را نیز می‌خواند، و اگر NoShare تنظیم شده باشد، /proc/<pid>/statm را نیز می‌خواند (برای اطلاعات بیشتر JobAcctGatherParams را ببینید).

این پلاگین در کارهایی با تعداد زیادی فرایند فرزند ایجادشده (spawned) هزینه کارایی (performance penalty) به همراه دارد، زیرا نیاز دارد روی تمام pidهای وظیفه پیمایش کرده و آمار را در یک معیار واحد برای ppid تجمیع کند، و سپس این مقادیر باید در آمار کلی وظیفه تجمیع شوند.

NOTE: تغییر نوع پلاگین در زمانی که کارها در کلاستر در حال اجرا هستند امکان‌پذیر است. گام‌های در حال اجرا همچنان از سازوکار پلاگین قبلی استفاده خواهند کرد، در حالی که گام‌های جدید از سازوکار جدید استفاده می‌کنند.

فواصل نمونه‌برداری حسابداری و پروفایل‌سازی کار، که برای هر نوع داده مشخص می‌شود. چندین فاصله زمانی به صورت جداشده با کاما در قالب <datatype>=<interval> قابل تعیین است. اگر فاصله‌ای بدون نوع داده ارائه شود، به نوع داده task اختصاص می‌یابد. انواع داده‌های پشتیبانی‌شده عبارتند از:
تأثیرگذار بر حسابداری و پروفایل‌سازی:
فاصله زمانی نمونه‌برداری بر حسب ثانیه برای میزان استفاده وظیفه توسط پلاگین‌های jobacct_gather و برای پروفایل‌سازی وظیفه توسط پلاگین acct_gather_profile. پیش‌فرض 30 است.
اگر این فاصله زمانی 0 (غیرفعال) باشد، اطلاعات حسابداری تنها هنگام خاتمه کار جمع‌آوری می‌شود که تداخل Slurm با کار را کاهش می‌دهد، اما همچنین به این معنی است که آمار کار تنها از یک نمونه به دست آمده و منعکس‌کننده میانگین یا حداکثر چند نمونه در طول دوره حیات کار نیست.
تنها تأثیرگذار بر پروفایل‌سازی:
فاصله زمانی نمونه‌برداری بر حسب ثانیه برای پروفایل‌سازی انرژی با استفاده از پلاگین acct_gather_energy. پیش‌فرض 0 (غیرفعال) است.
فاصله زمانی نمونه‌برداری بر حسب ثانیه برای پروفایل‌سازی InfiniBand با استفاده از پلاگین acct_gather_interconnect. پیش‌فرض 0 (غیرفعال) است.
فاصله زمانی نمونه‌برداری بر حسب ثانیه برای پروفایل‌سازی فایل‌سیستم با استفاده از پلاگین acct_gather_filesystem. پیش‌فرض 0 (غیرفعال) است.

مقادیر کوچک‌تر (غیر صفر) تأثیر بیشتری بر کارایی کار دارند، اما مقداری برابر با 30 ثانیه بعید است برای برنامه‌هایی با کمتر از 10,000 وظیفه محسوس باشد.
کاربران می‌توانند هنگام ارسال کار با استفاده از گزینه --acctg-freq هر فاصله زمانی را به صورت جداگانه برای هر کار لغو و بازنویسی کنند.
این مقدار در هنگام استفاده از پلاگین‌های acct_gather_energy/ipmi یا xcc باید کمتر یا مساوی با EnergyIPMIFreq باشد، زیرا در غیر این صورت مقادیر تکراری به صورت غیرضروری در نظرسنجی‌های متوالی (polls) دریافت خواهند شد.
پارامترهای اختیاری برای پلاگین جمع‌آوری حسابداری کار. مقادیر قابل قبول در حال حاضر عبارتند از:
حسابداری میزان مصرف GPU را انجام ندهد و از هرگونه فراخوانی کتابخانه درایور GPU صرف‌نظر کند. اگر پاسخ‌دهی درایور GPU کند باشد، این پارامتر می‌تواند به بهبود کارایی کمک کند.
حافظه مبتنی بر فایل‌سیستم (active_file و inactive_file) از حافظه گزارش‌شده کسر خواهد شد. این کار استفاده از رابط memory.peak را غیرفعال می‌کند، که می‌تواند منجر به عدم ثبت جهش‌های لحظه‌ای و کوتاه مصرف حافظه در MaxRSS شود. تنها با پلاگین cgroup/v2 سازگار است.
حافظه اشتراکی (shared memory) را از RSS مستثنی می‌کند. این گزینه نمی‌تواند همراه با UsePSS استفاده شود. تنها با پلاگین jobacct_gather/linux سازگار است.
فرایندهایی را که در هر بار جمع‌آوری اطلاعات حسابداری توسط پلاگین JobAcctGather مشخص شود حافظه‌ای بیش از مقدار درخواستی گام‌ها مصرف می‌کنند، متوقف (kill) می‌کند. این پارامتر باید با احتیاط استفاده شود زیرا کاری که از سهمیه حافظه تخصیص‌یافته خود فراتر رود ممکن است سایر فرایندها و/یا سلامت ماشین را تحت تأثیر قرار دهد.

NOTE: در صورت در دسترس بودن، توصیه می‌شود به جای استفاده از این سازوکار JobAcctGather برای اعمال محدودیت حافظه، با فعال کردن task/cgroup به عنوان یک TaskPlugin و استفاده از ConstrainRAMSpace=yes در cgroup.conf حافظه را محدود کنید. استفاده از JobAcctGather مبتنی بر نظرسنجی دوره‌ای (polling) است و پیش از متوقف شدن یک کار تأخیر وجود دارد که می‌تواند منجر به رخدادهای اتمام حافظه (Out of Memory) سیستم شود.

NOTE: هنگام استفاده از OverMemoryKill، اگر مجموع حافظه مصرفی توسط تمامی فرایندهای یک گام از حد مجاز حافظه فراتر رود، کل گام توسط پلاگین JobAcctGather متوقف/لغو (killed/cancelled) خواهد شد. این با رفتار حالت استفاده از ConstrainRAMSpace تفاوت دارد، که در آن فرایندهای درون گام متوقف می‌شوند اما گام فعال باقی می‌ماند و احتمالاً فرایندهای دیگری همچنان در حال اجرا خواهند بود.

برای محاسبه میزان مصرف واقعی حافظه، به جای مقدار RSS از مقدار PSS استفاده شود. مقدار PSS به عنوان RSS ذخیره خواهد شد. این گزینه نمی‌تواند همراه با NoShared استفاده شود. تنها با پلاگین jobacct_gather/linux سازگار است.
نام ماشینی که پایگاه‌داده تکمیل کار را میزبانی می‌کند. تنها برای پلاگین‌های ذخیره‌سازی از نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود. می‌تواند یک سوکت UNIX باشد، مانند "unix:/path/to/socket".
این گزینه رشته‌ای را تعیین می‌کند که بسته به JobCompType معانی متفاوتی دارد:
اگر jobcomp/elasticsearch باشد:
به این پلاگین دستور می‌دهد تا اطلاعات رکوردهای کارهای پایان‌یافته را به نشانی وب (URL endpoint) سرور Elasticsearch (شامل شماره پورت و نمایه (index) مقصد) که در این گزینه پیکربندی شده است ارسال کند. این رشته معمولاً باید به صورت <host>:<port>/<target>/_doc باشد. هنگام فعال بودن این پلاگین هیچ مقدار پیش‌فرضی برای JobCompLoc وجود ندارد.

NOTE: برای اطلاعات بیشتر به https://slurm.schedmd.com/elasticsearch.html مراجعه کنید.

اگر jobcomp/filetxt باشد:
به این پلاگین دستور می‌دهد تا اطلاعات رکوردهای کارهای پایان‌یافته را به پرونده‌ای که در این گزینه پیکربندی شده است ارسال کند. این رشته باید نشان‌دهنده یک مسیر مطلق به یک پرونده باشد. مقدار پیش‌فرض برای این پلاگین /var/log/slurm_jobcomp.log است.
اگر jobcomp/kafka باشد:
هنگامی که این پلاگین پیکربندی شده باشد، اطلاعات رکوردهای کارهای پایان‌یافته (و به صورت اختیاری شروع اجرای کارها) به یک سرور Kafka ارسال می‌شود. این پلاگین از librdkafka استفاده می‌کند. این رشته نشان‌دهنده یک مسیر مطلق به پرونده‌ای حاوی جفت‌های key=value برای پیکربندی رفتار کتابخانه است. برای عملکرد صحیح پلاگین، این پرونده باید وجود داشته باشد و دست‌کم ویژگی bootstrap.servers مربوط به librdkafka در آن پیکربندی شده باشد. هنگام فعال بودن این پلاگین هیچ مقدار پیش‌فرضی برای JobCompLoc وجود ندارد.

NOTE: برای فهرست کامل ویژگی‌های librdkafka، لطفاً به مستندات کتابخانه مراجعه کنید. همچنین می‌توانید برای اطلاعات بیشتر صفحه jobcomp_kafka را مشاهده کنید: https://slurm.schedmd.com/jobcomp_kafka.html

NOTE: تاپیک(های) مقصد Kafka و سایر پارامترهای پلاگین را می‌توان از طریق JobCompParams پیکربندی کرد.

اگر jobcomp/lua باشد:
این گزینه در این پلاگین نادیده گرفته می‌شود. رکورد کار پایان‌یافته توسط یک اسکریپت کدگذاری‌شده صلب jobcomp.lua پردازش می‌شود که انتظار می‌رود در همان مکان slurm.conf قرار داشته باشد. هنگام فعال بودن این پلاگین هیچ مقدار پیش‌فرضی برای JobCompLoc وجود ندارد.
اگر jobcomp/mysql باشد:
به این پلاگین دستور می‌دهد تا اطلاعات رکوردهای کارهای پایان‌یافته را به نام پایگاه‌داده‌ای که در این گزینه پیکربندی شده است ارسال کند. این رشته باید نشان‌دهنده نام یک پایگاه‌داده باشد. مقدار پیش‌فرض برای این پلاگین slurm_jobcomp_db است.
اگر jobcomp/script باشد:
اطلاعات رکورد کار پایان‌یافته از طریق متغیرهای محیطی در دسترس قرار می‌گیرد و توسط اسکریپتی با نام پیکربندی‌شده توسط این گزینه پردازش می‌شود. این رشته باید نشان‌دهنده مسیر یک اسکریپت باشد. هنگام فعال بودن این پلاگین هیچ مقدار پیش‌فرضی برای JobCompLoc وجود ندارد. این مورد باید به‌طور صریح پیکربندی شود وگرنه راه‌اندازی اولیه پلاگین با شکست مواجه خواهد شد.
ارسال یک رشته متنی اختیاری به پلاگین تکمیل کار. همچنین نگاه کنید به JobCompType.
فهرست اختیاری جداشده با کاما برای jobcomp/elasticsearch:
توضیحات (comment) کار را به عنوان بخشی از پیام‌های jobcomp ارسال می‌کند.
اسکریپت کار را به عنوان بخشی از پیام‌های jobcomp ارسال می‌کند.
فهرست اختیاری جداشده با کاما برای jobcomp/kafka:
به پلاگین jobcomp/kafka دستور می‌دهد تا هنگام شروع اجرای یک کار، زیرمجموعه‌ای از فیلدهای رکورد کار را به تاپیک کافکای topic_job_start ارسال کند.

NOTE: نوشتن در زمان پایان کار (هدف اولیه و تاریخی پلاگین) همیشه به‌طور پیش‌فرض فعال است و نمی‌توان آن را غیرفعال کرد.

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

حداکثر زمان (بر حسب میلی‌ثانیه) برای انتظار جهت تکمیل تمامی درخواست‌های تولید (produce requests) معوق و غیره. این مقدار به عنوان یک آرگومان مهلت زمانی (timeout) به تابع API فلاش librdkafka که هنگام خاتمه پلاگین فراخوانی می‌شود، ارسال می‌گردد. این کار پیش از نابود کردن نمونه تولیدکننده (producer instance) انجام می‌شود تا اطمینان حاصل شود که تمام درخواست‌های تولید در صف مانده و در حال پردازش قبل از خاتمه تکمیل می‌شوند. برای فراخوانی‌های غیرمسدودکننده (non-blocking)، روی 0 تنظیم کنید. برای انتظار نامحدود برای یک رویداد، روی -1 تنظیم کنید (توصیه نمی‌شود، زیرا این مورد در fini پلاگین فراخوانی می‌شود و می‌تواند مانع از خاتمه آرام و تمیز slurmctld شود). مقادیر پذیرفته‌شده [-1,2147483647] هستند. مقدار پیش‌فرض 500 (میلی‌ثانیه) است.
تعداد ثانیه‌های بین فراخوانی‌های تابع poll در API librdkafka، که هندل ارائه‌شده کافکا را برای رویدادها بررسی (poll) می‌کند. پلاگین یک ریسه (thread) مجزا برای اجرای این فراخوانی در فاصله زمانی پیکربندی‌شده ایجاد می‌کند. مقادیر پذیرفته‌شده [0,4294967295] هستند. مقدار پیش‌فرض 2 (ثانیه) است.
به کال‌بک گزارش تحویل (delivery report callback) دستور می‌دهد پیام‌هایی را که تحویل آن‌ها به دلیل رسیدن زمان انتظار برای تحویل موفق به مقدار ویژگی message.timeout.ms در librdkafka شکست خورده است، دوباره در صف قرار دهد (requeue). به‌طور پیش‌فرض تنظیم نشده است (پیام‌ها دوباره در صف قرار نمی‌گیرند و در نتیجه دور انداخته می‌شوند).
توضیحات (comment) کار را به عنوان بخشی از پیام‌های jobcomp ارسال می‌کند.
اسکریپت کار را به عنوان بخشی از پیام‌های jobcomp ارسال می‌کند.
تاپیک مقصد کافکا برای ارسال پیام‌ها در هنگام پایان یک کار. مقدار پیش‌فرض ClusterName است.
تاپیک مقصد کافکا برای ارسال پیام‌ها در هنگام شروع اجرای یک کار. مقدار پیش‌فرض <ClusterName>-job-start است.

NOTE: توصیه می‌شود که رکوردهای رویداد شروع اجرای کار به تاپیک کافکای متفاوتی نسبت به تاپیک پیکربندی‌شده برای رکوردهای رویداد پایان کار ارسال شوند.

فهرست اختیاری جداشده با کاما برای jobcomp/mysql:
مدت زمان بر حسب ثانیه برای کش کردن گذرواژه‌های تولیدشده پایگاه‌داده پیش از درخواست گذرواژه جدید از StoragePassScript. معمولاً توکن باید پیش از انقضای واقعی تازه‌سازی شود؛ در صورت شکست در تولید توکن، توکن کش‌شده همچنان استفاده خواهد شد تا از ایجاد خرابی در اتصال ناشی از خطاهای گذرا در تولید توکن جلوگیری شود. مقدار پیش‌فرض 300 ثانیه (5 دقیقه) است.
گذرواژه‌ای که برای دسترسی به پایگاه‌داده جهت ذخیره داده‌های تکمیل کار استفاده می‌شود. تنها برای پلاگین‌های ذخیره‌سازی از نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود.
مسیر مطلق به یک اسکریپت اجرایی که توکن‌های احراز هویت موقت (ephemeral) را برای اتصالات پایگاه‌داده تولید می‌کند که به جای JobCompPass استفاده می‌شوند. اسکریپت باید گذرواژه/توکن را در خروجی استاندارد (stdout) چاپ کرده و در صورت موفقیت با وضعیت 0 خارج شود. این قابلیت امکان تولید پویای گذرواژه را به جای ذخیره اطلاعات هویتی ایستا در پرونده‌های پیکربندی فراهم می‌کند. مالکیت و مجوز اجرای اسکریپت باید متعلق به SlurmUser باشد.
متغیرهای محیطی ارائه‌شده به اسکریپت:
نام میزبان پایگاه‌داده
شماره پورت پایگاه‌داده
نام کاربری پایگاه‌داده
قالب خروجی مورد انتظار:
TOKEN=<authentication_token>
اسکریپت باید در صورت موفقیت با وضعیت 0 و در صورت شکست با وضعیتی غیر صفر خارج شود. هر خروجی در خطای استاندارد (stderr) به عنوان یک خطا لاگ خواهد شد. اگر یک میزبان پشتیبان (backup host) مشخص شده باشد، اسکریپت همچنان نام میزبان اصلی را دریافت خواهد کرد و از همان توکن برای هر دو میزبان استفاده می‌شود.
پورت شنود سرور پایگاه‌داده تکمیل کار. تنها برای پلاگین‌های ذخیره‌سازی از نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود.
نوع سازوکار ثبت گزارش (لاگین) تکمیل کار. به‌طور پیش‌فرض تنظیم‌نشده (unset) است. مقادیر قابل قبول در حال حاضر عبارتند از:
پس از پایان کار، رکوردی از کار باید در یک سرور Elasticsearch که توسط پارامتر JobCompLoc مشخص شده است، نوشته شود.
NOTE: اطلاعات بیشتر در وب‌سایت Slurm در دسترس است ( https://slurm.schedmd.com/elasticsearch.html ).
پس از پایان کار، رکوردی از کار باید در یک پرونده متنی که توسط پارامتر JobCompLoc مشخص شده است، نوشته شود.
پس از پایان کار (یا به صورت اختیاری شروع اجرای کار)، رکوردی از کار باید به یک سرور Kafka که با مسیر پرونده ارجاع‌شده در JobCompLoc و/یا با استفاده از سایر JobCompParams مشخص شده است، ارسال شود.
پس از پایان کار، رکوردی از کار باید توسط اسکریپت jobcomp.lua واقع در دایرکتوری پیش‌فرض اسکریپت‌ها (معمولاً زیرشاخه etc از دایرکتوری محل نصب) پردازش شود.
پس از پایان کار، رکوردی از کار باید در یک پایگاه‌داده MySQL یا MariaDB که توسط پارامتر JobCompLoc مشخص شده است، نوشته شود.
پس از پایان کار، اسکریپتی که توسط پارامتر JobCompLoc مشخص شده است همراه با متغیرهای محیطی ارائه‌دهنده اطلاعات کار اجرا می‌شود.
حساب کاربری برای دسترسی به پایگاه‌داده تکمیل کار. تنها برای پلاگین‌های ذخیره‌سازی از نوع پایگاه‌داده استفاده می‌شود و در غیر این صورت نادیده گرفته می‌شود.
این گزینه کنترل می‌کند که اگر پرونده خروجی یا خطای یک کار هنگام شروع کار وجود داشته باشد، چه اقدامی انجام شود. اگر JobFileAppend روی مقدار 1 تنظیم شود، خروجی به انتهای پرونده موجود الحاق (append) می‌شود. به‌طور پیش‌فرض، هر پرونده موجود کوتاه/پاکسازی (truncate) می‌شود.
این گزینه قابلیت پیش‌فرض قرارگیری مجدد کارهای دسته‌ای (batch jobs) در صف (requeue) را کنترل می‌کند. کارها ممکن است صریحاً توسط مدیر سیستم، پس از خرابی گره، یا پس از پیش‌دستی (preemption) توسط کاری با اولویت بالاتر مجدداً در صف قرار گیرند. اگر JobRequeue روی مقدار 1 تنظیم شود، کارهای دسته‌ای می‌توانند دوباره در صف قرار گیرند مگر اینکه کاربر صریحاً آن را غیرفعال کرده باشد. اگر JobRequeue روی مقدار 0 تنظیم شود، کارهای دسته‌ای دوباره در صف قرار نخواهند گرفت مگر اینکه کاربر صریحاً آن را فعال کرده باشد. از گزینه‌های --no-requeue یا --requeue در sbatch برای تغییر رفتار پیش‌فرض برای کارهای منفرد استفاده کنید. مقدار پیش‌فرض 1 است.
این‌ها پلاگین‌های مختص هر سایت (site-specific) هستند که می‌توانند برای تنظیم پارامترهای پیش‌فرض کار و/یا ثبت وقایع (logging) به کار روند. در صورت تمایل می‌توان Slurm را به گونه‌ای پیکربندی کرد که از چندین پلاگین job_submit استفاده کند، که باید به صورت یک فهرست جداشده با کاما مشخص شوند و به همان ترتیبی که فهرست شده‌اند اجرا خواهند شد. 
e.g. for multiple job_submit plugin configuration:
JobSubmitPlugins=lua,require_timelimit
برای جزئیات بیشتر در مورد پیاده‌سازی پلاگین، به https://slurm.schedmd.com/job_submit_plugins.html مراجعه کنید. به‌طور پیش‌فرض هیچ پلاگین ثبت کاری استفاده نمی‌شود. پلاگین‌های موجود در حال حاضر عبارتند از:
تنظیم پارتیشن پیش‌فرض روی تمام پارتیشن‌های موجود در کلاستر.
تنظیم مقادیر پیش‌فرض برای درخواست‌های ثبت یا ویرایش کار.
ثبت وقایع (لاگ کردن) پارامترهای انتخابی ثبت و ویرایش کار.
اجرای یک اسکریپت Lua که منطق job_submit اختصاصی سایت را پیاده‌سازی می‌کند. تنها یک اسکریپت Lua اجرا خواهد شد. نام آن باید "job_submit.lua" باشد و باید در دایرکتوری پیش‌فرض پیکربندی (معمولاً زیردایرکتوری "etc" از دایرکتوری محل نصب) قرار داشته باشد. نمونه اسکریپت‌های Lua را می‌توان همراه با توزیع Slurm در دایرکتوری contribs/lua یافت. اگر اسکریپت lua پیکربندی‌شده نامعتبر باشد، slurmctld هنگام راه‌اندازی با خطای مهلک (fatal) مواجه می‌شود. Slurm برای هر بار ثبت کار تلاش می‌کند اسکریپت را بارگذاری کند. اگر در حین اجرای slurmctld اسکریپت خراب یا حذف شود، Slurm به نسخه فعال قبلی اسکریپت بازمی‌گردد. Warning: slurmctld این اسکریپت را در حالی اجرا می‌کند که قفل‌های داخلی را در دست دارد و در هر لحظه تنها یک نسخه از این اسکریپت می‌تواند اجرا شود. این امر مانع از اکثر همزمانی‌ها در slurmctld می‌شود. بنابراین، این اسکریپت باید در سریع‌ترین زمان ممکن اجرا شده و به پایان برسد.
تنظیم پارتیشن پیش‌فرض یک کار بر اساس پارامترهای ثبت کار و پارتیشن‌های در دسترس.
ترجمه گزینه‌های ثبت کار PBS به معادل Slurm (در صورت امکان).
اجبار درخواست‌های ثبت کار به تعیین محدودیت زمانی (timelimit).

NOTE: برای مشاهده نمونه‌های استفاده، به کدهای Slurm در "src/plugins/job_submit" و "contribs/lua/job_submit*.lua" مراجعه کرده و سپس کد را مطابق با نیازهای خود تغییر دهید.

اگر برابر با 1 تنظیم شود، در صورتی که هر وظیفه‌ای (task) دچار خرابی (crash) یا لغو (abort) شود — همان‌طور که با یک کد خروج غیر صفر مشخص می‌شود — گام کاری (step) فوراً خاتمه خواهد یافت. با مقدار پیش‌فرض 0، اگر یکی از فرایندها دچار خرابی یا توقف شود، سایر فرایندها به اجرای خود ادامه می‌دهند در حالی که فرایند خراب یا متوقف‌شده منتظر می‌ماند. کاربر می‌تواند این پارامتر پیکربندی را با استفاده از -K یا --kill-on-bad-exit در srun بازنویسی کند.
فاصله زمانی بر حسب ثانیه که پس از رسیدن کار به محدودیت زمانی خود، بین سیگنال‌های SIGTERM و SIGKILL به فرایندهای کار داده می‌شود. اگر کار نتواند در بازه زمانی تعیین‌شده به‌صورت مسالمت‌آمیز (gracefully) خاتمه یابد، به‌صورت اجباری خاتمه داده خواهد شد. مقدار پیش‌فرض 30 ثانیه است. این مقدار نباید از 65533 تجاوز کند.
حداکثر دفعاتی که یک کار دسته‌ای (batch job) می‌تواند پیش از علامت‌گذاری به عنوان JobHeldAdmin، به‌طور خودکار دوباره در صف قرار گیرد. (عمدتاً زمانی مفید است که گزینه nohold_on_prolog_fail در SchedulerParameters فعال باشد.) مقدار پیش‌فرض 5 است.
پلاگین‌هایی را مشخص می‌کند که برای پشتیبانی از ویژگی‌های گره (node features) که می‌توانند در طول زمان تغییر کنند، استفاده می‌شوند؛ به عنوان مثال، گره‌ای که ممکن است با تنظیمات مختلف BIOS بوت شود. این قابلیت از طریق استفاده از اطلاعات active_features و available_features یک گره پشتیبانی می‌شود. مقادیر مجاز در حال حاضر عبارتند از:
برای گزارش و تغییر ویژگی‌های روی گره‌ها با استفاده از اسکریپت‌ها یا برنامه‌های دلخواه به کار می‌رود. برای اطلاعات بیشتر به صفحه راهنمای helpers.conf مراجعه کنید: https://slurm.schedmd.com/helpers.conf.html
گزینه‌های مربوط به پلاگین راه‌اندازی کار را مشخص می‌کند. مقادیر مجاز شامل موارد زیر هستند:
تنظیم فرکانس CPU برای گام دسته‌ای از طریق گزینه داده‌شده --cpu-freq، یا گزینه CpuFreqDef در slurm.conf. به‌طور پیش‌فرض فقط گام‌هایی که با srun آغاز شده‌اند از گزینه‌های تنظیم فرکانس CPU استفاده خواهند کرد.

NOTE: اگر از srun برای راه‌اندازی گام‌های خود درون یک اسکریپت دسته‌ای استفاده می‌کنید (توصیه می‌شود)، این گزینه وضعیتی ایجاد می‌کند که در آن ممکن است چندین عامل اقدام به تنظیم cpu_freq کنند، زیرا گام دسته‌ای معمولاً روی همان منابعی اجرا می‌شود که یک یا چند گامِ ایجادشده توسط srunها در اسکریپت ایجاد خواهند کرد.

تنظیم فرکانس CPU برای گام تعاملی از طریق گزینه‌های داده‌شده --cpu-freq، یا گزینه CpuFreqDef در slurm.conf.
به کارهای روی کلاستر Cray XC امکان دسترسی انحصاری به منابع شبکه را می‌دهد. این گزینه فقط باید در کلاسترهایی تنظیم شود که دسترسی انحصاری به هر گره را در هر زمان به یک کار واحد ارائه می‌دهند، و از گام‌های موازی درون کار استفاده نمی‌کنند؛ در غیر این صورت منابع روی گره ممکن است بیش از حد تخصیص داده شوند (oversubscribed).
اجازه می‌دهد تفکیک نام و اطلاعات passwd و group برای یک کار توسط slurmstepd انجام شود، به جای اینکه نیاز به جستجو (lookup) از یک سرویس مبتنی بر شبکه باشد. برای اطلاعات بیشتر به https://slurm.schedmd.com/nss_slurm.html مراجعه کنید.
اگر روی یک کلاستر Cray XC تنظیم شود، در هنگام تکمیل گام کاری، کش Lustre پاکسازی (flush) نمی‌شود. این تنظیم فقط پس از پیکربندی مجدد و تنها برای کارهای تازه راه‌اندازی‌شده اعمال خواهد شد.
هنگام راه‌اندازی وظایف، Slurm ورودی‌هایی در MPIR_proctable ایجاد می‌کند که توسط دیباگرهای موازی، ابزارهای پروفایلینگ و ابزارهای مرتبط برای اتصال به فرایند در حال اجرا استفاده می‌شوند. به‌طور پیش‌فرض ورودی‌های MPIR_proctable حاوی ساختارهای MPIR_procdesc هستند که در آن‌ها host_name به‌طور پیش‌فرض روی NodeName تنظیم شده است. اگر این گزینه مشخص شود، به جای آن از NodeAddr در این زمینه استفاده خواهد شد.
به‌طور پیش‌فرض، slurmctld نام کاربری (user_name) و شناسه‌های گروهی گسترش‌یافته (extended gids) را برای یک کار جستجو کرده و ارسال می‌کند، به جای آنکه این کار به‌طور مستقل روی هر گره به عنوان بخشی از هر بار راه‌اندازی وظیفه انجام شود. این امر به کاهش مشکلات مقیاس‌پذیری سرویس نام هنگام راه‌اندازی کارهایی که شامل گره‌های زیادی هستند کمک می‌کند. استفاده از این گزینه، این قابلیت را غیرفعال می‌کند. در صورت تعیین enable_nss_slurm، این گزینه نادیده گرفته می‌شود.
قفل کردن حافظه فعلی فرایند slurmstepd در RAM.
قفل کردن حافظه فعلی و آتی فرایند slurmstepd در RAM.
باعث می‌شود srun --exclusive به‌طور پیش‌فرض به گزینه --exclusive=allocation تغییر یابد. این امر گزینه ضمنی --exact را که exclusive برای srun اضافه می‌کند، غیرفعال می‌سازد. کاربران همچنان می‌توانند برای دریافت رفتار استاندارد، srun --exclusive --exact را مشخص کنند.
باعث می‌شود srun پیش از تلاش برای اجرای برنامه روی گره‌های گام کاری، وجود برنامه اجرایی و مجوز اجرای کاربر را روی گره‌ای که srun در آن فراخوانی شده است بررسی کند.
باعث می‌شود salloc به جای اجرا به صورت محلی در هر جایی که salloc فراخوانی شده است، از گام تعاملی (Interactive Step) برای اجرای یک شل (shell) روی یک گره محاسباتی تخصیص‌یافته استفاده کند. این کار با اجرای دستور srun به همراه InteractiveStepOptions به عنوان گزینه‌های آن انجام می‌شود.

این گزینه بر salloc که با یک دستور به عنوان آرگومان فراخوانی شده است تاثیری ندارد. این کارها همچنان به عنوان کاربر فراخواننده روی میزبان فراخواننده اجرا خواهند شد.

هنگامی که pam_slurm_adopt برای پیوستن یک فرایند خارجی به cgroup یک کار استفاده می‌شود، مقدار RLIMIT_RSS تنظیم می‌گردد، درست همان‌طور که برای وظایف در حال اجرا در گام‌های عادی انجام می‌شود.
پارامترهایی برای کنترل رفتار مجوزها (licenses). به‌طور پیش‌فرض هیچ پارامتری تنظیم نشده است. چندین پارامتر را می‌توان در یک فهرست جداشده با کاما تعیین کرد. گزینه‌های پشتیبانی‌شده در حال حاضر عبارتند از:
اجازه می‌دهد کارها با نام اختصاری برای مجوزهای راه دور (remote licenses) که نام سرور را حذف می‌کند ثبت شوند. به عنوان مثال، "matlab@licenseServer" را می‌توان با "matlab" درخواست کرد. درخواست‌هایی که شامل نام سرور باشند همیشه شناسایی خواهند شد. اگر یک مجوز محلی (تعریف‌شده در slurm.conf) وجود داشته باشد، ترجیح داده می‌شود که با آن مطابقت داده شود. اگر چندین سرور با همان نام مجوز وجود داشته باشند، تطبیق تقریبی (fuzzy match) با شکست مواجه می‌شود و باید از تطبیق دقیق (همراه با نام سرور) استفاده شود.
مشخصات مجوزها (یا منابع دیگری که در تمام گره‌های کلاستر در دسترس هستند) که می‌توانند به کارها تخصیص یابند. نام مجوزها می‌تواند به‌طور اختیاری با یک دونقطه و تعداد همراه باشد که تعداد پیش‌فرض آن یک است. نام‌های متعدد مجوزها باید با کاما از هم جدا شوند (مانند "Licenses=foo:4,bar"). توجه داشته باشید که اگر مشخصات مجوز مورد نیاز یک کار در دسترس نباشد، Slurm از زمان‌بندی آن جلوگیری می‌کند. Slurm مانع از استفاده کارها از مجوزهایی که به‌طور صریح در مشخصات ثبت کار قید نشده‌اند، نمی‌شود.
قالب برچسب زمانی (timestamp) در فایل‌های گزارش slurmctld و slurmd. مقادیر مجاز قالب شامل "iso8601"، "iso8601_ms"، "rfc5424"، "rfc5424_ms"، "rfc3339"، "clock"، "short" و "thread_id" است. مقادیری که به "_ms" ختم می‌شوند با مقادیر بدون آن در این تفاوت دارند که کسر ثانیه با دقت میلی‌ثانیه چاپ می‌شود. مقدار پیش‌فرض "iso8601_ms" است. قالب‌های "rfc5424" مانند قالب‌های "iso8601" هستند با این تفاوت که مقدار منطقه زمانی (timezone) نیز نمایش داده می‌شود. قالب "clock" یک برچسب زمانی بر حسب میکروثانیه را نشان می‌دهد که با تابع استاندارد C یعنی ()clock بازیابی شده است. قالب "short" یک قالب کوتاه تاریخ و زمان است. قالب "thread_id" برچسب زمانی را در قالب تابع استاندارد C یعنی ()ctime بدون سال اما شامل میکروثانیه، شناسه فرایند (PID) دیمن و نام و شناسه ریسه (thread) فعلی نشان می‌دهد.
نام دامنه برای تکمیل نام‌های کاربری در صورتی که آدرس ایمیل به‌طور صریح با گزینه "--mail-user" ارائه نشده باشد. در صورت عدم تنظیم، MTA محلی باید خود آدرس محلی را تکمیل کند. تغییرات در MailDomain فقط کارهای جدید را تحت تأثیر قرار می‌دهد.
مسیر کامل به برنامه مورد استفاده برای ارسال ایمیل بر اساس درخواست کاربر. مقدار پیش‌فرض "/bin/mail" است (یا "/usr/bin/mail" در صورتی که "/bin/mail" وجود نداشته باشد اما "/usr/bin/mail" موجود باشد). این برنامه با آرگومان‌های مناسب برای دستور پیش‌فرض mail فراخوانی می‌شود، با این حال اطلاعات اضافی در مورد کار در قالب متغیرهای محیطی ارسال می‌گردد.

متغیرهای اضافی همان متغیرهایی هستند که به PrologSlurmctld و EpilogSlurmctld منتقل می‌شوند، به همراه متغیرهای اضافی در زمینه‌های زیر:

وضعیت پایه کار هنگامی که MailProg فراخوانی می‌شود.
نوع ایمیلی که موجب ارسال ایمیل شده است.
مدت زمانی که کار در صف قرار داشته است.
مدت زمانی که کار اجرا شده است.
کد خروج کار یا بالاترین کد خروج برای یک آرایه کاری (job array).
حداقل کد خروج کار برای یک آرایه کاری.
بالاترین سیگنال کار برای یک آرایه کاری.
مدت زمان خروج داده‌ها (staging out) برای کار.
حداکثر مقدار شاخص وظیفه در آرایه کاری، یکی کمتر از MaxArraySize خواهد بود تا امکان استفاده از مقدار شاخص صفر وجود داشته باشد. برای غیرفعال کردن استفاده از آرایه کاری، MaxArraySize را روی 0 تنظیم کنید. این مقدار نباید از 4000001 تجاوز کند. مقدار MaxJobCount باید بسیار بزرگتر از MaxArraySize باشد، زیرا هر وظیفه در آرایه کاری همچنان به عنوان یک کار جداگانه محاسبه می‌شود (برای جزئیات بیشتر به MaxJobCount مراجعه کنید). مقدار پیش‌فرض 1001 است. همچنین به max_array_tasks در SchedulerParameters مراجعه کنید.
هنگامی که ارتباط با SlurmDBD امکان‌پذیر نیست، slurmctld پیام‌هایی را که قرار است پس از در دسترس قرار گرفتن مجدد SlurmDBD پردازش شوند در صف قرار می‌دهد. برای جلوگیری از اتمام حافظه، slurmctld تنها تعداد محدودی پیام را در صف قرار می‌دهد. مقدار پیش‌فرض 10000 یا MaxJobCount * 2 + تعداد گره‌ها * 4 است، هر کدام که بزرگتر باشد. این مقدار نمی‌تواند کمتر از 10000 باشد.
حداکثر تعداد کارهایی که slurmctld می‌تواند در یک زمان در حافظه نگه دارد. این پارامتر را با MinJobAge ترکیب کنید تا اطمینان حاصل شود که دیمن slurmctld حافظه یا سایر منابع خود را به پایان نمی‌رساند. پس از رسیدن به این محدودیت، درخواست‌های ثبت کارهای اضافی با شکست مواجه خواهند شد. مقدار پیش‌فرض 10000 کار است. NOTE: هر وظیفه از یک آرایه کاری به عنوان یک کار محاسبه می‌شود، حتی اگر تا زمان تغییر یا شروع، رکوردهای کاری جداگانه‌ای را اشغال نکنند. کارایی سیستم با بیش از چند صد هزار کار ممکن است افت کند. تنظیم MaxSubmitJobs برای هر کاربر عموماً برای جلوگیری از پر کردن سیستم با کارها توسط یک کاربر واحد ارزشمند است. این کار با استفاده از پایگاه داده Slurm و پیکربندی اعمال محدودیت‌های منابع انجام می‌شود.
حداکثر شناسه کاری (job id) که برای کارهای ثبت‌شده در Slurm بدون درخواست مقدار مشخص، استفاده می‌شود. شناسه‌های کار اعداد صحیح ۳۲ بیتی بدون علامت هستند که ۲۶ بیت اول برای شناسه‌های کار محلی و ۶ بیت باقی‌مانده برای شناسه کلاستر به منظور شناسایی مبدا کار فدرال رزرو شده است. حداکثر شناسه کار محلی مجاز 67,108,863 (0x3FFFFFF) است. مقدار پیش‌فرض 67,043,328 (0x03ff0000) است. MaxJobId فقط برای شناسه کار محلی اعمال می‌شود و نه شناسه کار فدرال. مقادیر شناسه کار تولیدشده برای هر کار بعدی ۱ واحد افزایش می‌یابد. پس از رسیدن به MaxJobId، به کار بعدی مقدار FirstJobId اختصاص داده خواهد شد. کارهای فدرال همیشه شناسه کار 67,108,865 یا بالاتر خواهند داشت. همچنین به FirstJobId مراجعه کنید.
حداکثر اندازه حافظه واقعی در دسترس به ازای هر CPU تخصیص‌یافته بر حسب مبی‌بایت (mebibytes). برای جلوگیری از تخصیص بیش از حد حافظه (over-subscribing) و ایجاد صفحه‌بندی (paging) استفاده می‌شود. MaxMemPerCPU عموماً زمانی استفاده می‌شود که پردازنده‌های مجزا به کارها تخصیص داده شوند (SelectType=select/cons_tres). مقدار پیش‌فرض 0 (نامحدود) است. همچنین به DefMemPerCPU، DefMemPerGPU و MaxMemPerNode مراجعه کنید. MaxMemPerCPU و MaxMemPerNode مانعة‌الجمع هستند.

NOTE: اگر کاری محدودیت حافظه به ازای هر CPU را مشخص کند که از این محدودیت سیستم بیشتر باشد، تعداد CPUهای آن کار به ازای هر وظیفه تلاش خواهد کرد تا به‌طور خودکار افزایش یابد. این ممکن است منجر به شکست کار به دلیل محدودیت‌های تعداد CPU شود. این ویژگی تنظیم خودکار از نوع بهترین تلاش (best-effort) است و تخصیص بهینه به دلیل احتمال وجود پیکربندی‌های ناهمگن و کارهای چندپارتیشنی/چند QoS تضمین نمی‌شود. اگر این موضوع نگران‌کننده است، توصیه می‌شود در عوض از یک پلاگین LUA ثبت کار استفاده کنید تا تنظیمات خودکار را مطابق با نیازهای خاص شما اعمال کند.

حداکثر اندازه حافظه واقعی در دسترس به ازای هر گره تخصیص‌یافته در یک تخصیص کار بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. MaxMemPerNode عموماً زمانی استفاده می‌شود که گره‌های کامل به کارها تخصیص داده شوند (SelectType=select/linear) و منابع بیش از حد تخصیص داده شده باشند (OverSubscribe=yes یا OverSubscribe=force). مقدار پیش‌فرض 0 (نامحدود) است. همچنین به DefMemPerNode و MaxMemPerCPU مراجعه کنید. MaxMemPerCPU و MaxMemPerNode مانعة‌الجمع هستند.
حداکثر تعداد گره‌هایی که می‌توانند در کنترلر وجود داشته باشند. به‌طور پیش‌فرض MaxNodeCount روی تعداد گره‌های یافت‌شده در slurm.conf تنظیم می‌شود. اگر MaxNodeCount کمتر از تعداد گره‌های یافت‌شده در slurm.conf باشد، نادیده گرفته خواهد شد. تعداد کل گره‌ها در یک سیستم نمی‌تواند از 65536 تجاوز کند. برای پشتیبانی از گره‌های ایجادشده به صورت پویا با ثبت پویای گره و گره‌های ایجادشده با scontrol، مقدار MaxNodeCount را افزایش دهید.
حداکثر تعداد گام‌هایی که هر کاری می‌تواند آغاز کند. این پارامتر برای محدود کردن اثرات اسکریپت‌های دسته‌ای نامناسب در نظر گرفته شده است. مقدار پیش‌فرض 40000 گام است.
حداکثر تعداد وظایفی که Slurm به یک گام کاری اجازه می‌دهد روی یک گره منفرد ایجاد کند. مقدار پیش‌فرض MaxTasksPerNode برابر با 512 است. نباید از 65533 تجاوز کند.
‏MCS = امنیت چند دسته‌ای (Multi-Category Security). پارامترهای پلاگین MCS. پارامترهای پشتیبانی‌شده مختص MCSPlugin هستند. تغییرات در این مقدار زمانی اعمال می‌شوند که دیمن‌های Slurm مجدداً پیکربندی شوند. اطلاعات بیشتر در مورد MCS در اینجا در دسترس است: https://slurm.schedmd.com/mcs.html.
‏MCS = امنیت چند دسته‌ای (Multi-Category Security) : اختصاص یک برچسب امنیتی به کارها و اطمینان از اینکه گره‌ها فقط می‌توانند بین کارهایی که از برچسب امنیتی یکسان استفاده می‌کنند به اشتراک گذاشته شوند. به‌طور پیش‌فرض تنظیم نشده است. مقادیر مجاز شامل موارد زیر هستند:
فقط کاربرانی با حساب کاربری (account) یکسان می‌توانند گره‌ها را به اشتراک بگذارند (نیاز به فعال بودن سیستم حسابداری دارد).
فقط کاربرانی با گروه یکسان می‌توانند گره‌ها را به اشتراک بگذارند.
یک گره نمی‌تواند با سایر کاربران به اشتراک گذاشته شود.
فقط کارهایی با رشته برچسب دلخواه یکسان می‌توانند گره‌ها را به اشتراک بگذارند.
زمان مجاز برای تکمیل یک ارتباط رفت و برگشت (round-trip) بر حسب ثانیه. مقدار پیش‌فرض 10 ثانیه است. برای سیستم‌هایی با گره‌های اشتراکی، ممکن است دیمن slurmd به حافظه مجازی (page out) منتقل شود و نیاز به مقادیر بالاتری داشته باشد.
کنترل می‌کند که کدام کاربران مجاز به ارسال پرس‌وجو به نقاط پایانی (endpoints) پلاگین متریک هستند. SlurmUser و root همیشه مجاز هستند. هنگامی که تنظیم شود، PrivateData و/یا MetricsParameters=ignore_private_data را نادیده می‌گیرد و به کاربران موجود در فهرست اجازه می‌دهد از نقاط پایانی متریک پرس‌وجو کنند. این گزینه احراز هویت JWT را برای پرس‌وجو از نقاط پایانی متریک فعال می‌کند.
پارامترهای مربوط به پلاگین‌های متریک. چندین پارامتر می‌توانند با کاما از هم جدا شوند. پارامترهای پشتیبانی‌شده در حال حاضر عبارتند از:
هنگامی که تنظیم شود باعث می‌شود پلاگین‌های متریک PrivateData را نادیده بگیرند و به همه کاربران دسترسی عمومی برای پرس‌وجو از نقاط پایانی متریک بدون احراز هویت را می‌دهد. اگر MetricsAuthUsers تنظیم شده باشد، این گزینه نادیده گرفته خواهد شد.
پلاگین متریک مورد استفاده برای تخلیه آمارها از سوکت slurmctld را مشخص می‌کند. برای جزئیات بیشتر به راهنمای متریک‌ها (Metrics Guide) مراجعه کنید: https://slurm.schedmd.com/metrics.html

مقادیر قابل پیکربندی در حال حاضر عبارتند از:

استفاده از پلاگین مبتنی بر OpenMetrics.
حداقل سن یک کار تکمیل‌شده پیش از آنکه رکورد آن از فهرست کارهایی که slurmctld در حافظه نگه می‌دارد پاک شود. این مقدار را با MaxJobCount ترکیب کنید تا اطمینان حاصل شود دیمن slurmctld حافظه یا سایر منابع خود را به پایان نمی‌رساند. مقدار پیش‌فرض 300 ثانیه است. مقدار صفر از هرگونه پاکسازی رکورد کارها جلوگیری می‌کند. کارها در طول یک چرخه backfill پاکسازی نمی‌شوند، بنابراین اگر از پلاگین زمان‌بندی backfill استفاده شود، ممکن است پاکسازی یک کار بیش از MinJobAge ثانیه طول بکشد. به منظور حذف برخی شرایط رقابتی (race conditions) احتمالی، حداقل مقدار غیر صفر توصیه‌شده برای MinJobAge برابر با 2 است.
نوع پیش‌فرض MPI مورد استفاده را مشخص می‌کند. به‌طور پیش‌فرض تنظیم نشده است، که به Slurm اجازه می‌دهد با نسخه‌هایی از MPI به غیر از موارد فهرست‌شده در زیر کار کند. دستور srun در هر صورت می‌تواند این پارامتر پیکربندی را بازنویسی کند. نسخه‌های پشتیبانی‌شده در حال حاضر شامل موارد زیر هستند: pmi2 و pmix. اطلاعات بیشتر در مورد استفاده از MPI در اینجا در دسترس است: https://slurm.schedmd.com/mpi_guide.html.
پارامترهای مربوط به MPI. چندین پارامتر می‌توانند با کاما از هم جدا شوند. پارامترهای پشتیبانی‌شده در حال حاضر عبارتند از:
تزریق متغیرهای محیطی در تخصیص‌ها را برای متغیرهای زیر غیرفعال می‌کند: I_MPI_HYDRA_BOOTSTRAP، I_MPI_HYDRA_BOOTSTRAP_EXEC_EXTRA_ARGS، HYDRA_BOOTSTRAP، HYDRA_LAUNCHER_EXTRA_ARGS.

تنظیم دستی I_MPI_HYDRA_BOOTSTRAP یا HYDRA_BOOTSTRAP روی 'slurm' در تخصیص، این پارامتر را نادیده می‌گیرد و تزریق آرگومان‌های اضافی طبق معمول انجام خواهد شد.

پلاگین مورد استفاده برای جداسازی کارها از طریق فضاهای نام (namespaces) را مشخص می‌کند. برای استفاده از این پلاگین‌ها، باید 'PrologFlags=Contain' تنظیم شده باشد. برای جزئیات بیشتر به صفحه فضاهای نام مراجعه کنید: https://slurm.schedmd.com/namespace.html

NOTE: برای مهار منابع و ردیابی استفاده به ProctrackType مراجعه کنید.

مقادیر مجاز در حال حاضر عبارتند از:

برای ایجاد یک فضای نام فایل‌سیستم خصوصی و به‌طور اختیاری فضاهای نام کاربر (user) و شناسه فرایند (pid) استفاده می‌شود. فضای نام فایل‌سیستم حاوی فایل‌سیستم‌های موقت (/tmp و /dev/shm) برای هر کار است.

NOTE: این پلاگین برای عملکرد صحیح به cgroup/v2 نیاز دارد.
NOTE: هنگام استفاده از فضاهای نام کاربر، پشتیبانی از bpf token (اضافه‌شده در هسته 6.9) برای استفاده از ConstrainDevices در cgroup.conf الزامی است.

برای ایجاد یک فضای نام خصوصی روی فایل‌سیستم برای کارها استفاده می‌شود که حاوی سیستم‌های فایل موقت (/tmp و /dev/shm) برای هر کار است.
تعداد دقایقی که یک کار می‌تواند بیش از محدودیت زمانی خود اجرا شود، پیش از آنکه لغو گردد. معمولاً محدودیت زمانی یک کار به عنوان یک محدودیت سخت (hard) در نظر گرفته می‌شود و کار با رسیدن به آن محدودیت متوقف خواهد شد. پیکربندی OverTimeLimit منجر به این می‌شود که محدودیت زمانی کار مانند یک محدودیت نرم (soft) تلقی شود. افزودن مقدار OverTimeLimit به محدودیت زمانی نرم، یک محدودیت زمانی سخت فراهم می‌کند که در آن نقطه کار لغو می‌شود. این امر به‌ویژه برای زمان‌بندی پس‌پرکننده (backfill) مفید است که بر اساس محدودیت زمانی نرم هر کار عمل می‌کند. مقدار پیش‌فرض صفر است. نمی‌تواند از 65533 دقیقه تجاوز کند. مقدار "UNLIMITED" نیز پشتیبانی می‌شود.
مکان‌هایی را برای جستجوی پلاگین‌های Slurm مشخص می‌کند. این یک فهرست از دایرکتوری‌ها است که با دونقطه (:) از هم جدا شده‌اند، مشابه متغیر محیطی PATH. مقدار پیش‌فرض، پیشوند داده‌شده در زمان پیکربندی به همراه "/lib/slurm" است.
محل فایل پیکربندی برای پلاگین‌های پشته‌پذیر (stackable) Slurm که از معماری پلاگین پشته‌پذیر برای کنترل کار گره (SPANK) استفاده می‌کنند. این گزینه پشتیبانی از مجموعه‌ای بسیار قابل تنظیم از پلاگین‌ها را فراهم می‌کند تا قبل و/یا بعد از اجرای هر وظیفه ایجادشده به عنوان بخشی از گام کاری کاربر فراخوانی شوند. مکان پیش‌فرض "plugstack.conf" در همان دایرکتوری slurm.conf سیستم است. برای اطلاعات بیشتر در مورد پلاگین‌های SPANK، به راهنمای spank(8) مراجعه کنید.
سازوکار مورد استفاده برای قبضه کردن کارها (preempt) یا فعال‌سازی زمان‌بندی گروهی (gang scheduling). هنگامی که پارامتر PreemptType برای فعال‌سازی قبضه تنظیم شده باشد، PreemptMode سازوکار پیش‌فرض مورد استفاده برای قبضه کردن کارهای واجد شرایط برای کلاستر را انتخاب می‌کند.
در صورتی که PreemptType=preempt/partition_prio باشد، PreemptMode می‌تواند بر اساس هر پارتیشن مشخص شود تا این مقدار پیش‌فرض را بازنویسی کند. متناوباً، اگر PreemptType=preempt/qos باشد، می‌تواند بر اساس هر QOS مشخص شود. در هر صورت، هنگام فعال بودن قبضه، باید یک مقدار پیش‌فرض معتبر PreemptMode برای کل کلاستر تعیین شود.
گزینه GANG برای فعال‌سازی زمان‌بندی گروهی مستقل از اینکه قبضه فعال باشد یا خیر (یعنی مستقل از تنظیم PreemptType) استفاده می‌شود. این گزینه می‌تواند علاوه بر تنظیم PreemptMode مشخص شود که دو گزینه با کاما از هم جدا می‌شوند (مانند PreemptMode=SUSPEND,GANG).
برای جزئیات بیشتر به https://slurm.schedmd.com/preempt.html و https://slurm.schedmd.com/gang_scheduling.html مراجعه کنید.

NOTE: به دلایل کارایی، زمان‌بند backfill گره‌های کامل را برای کارها رزرو می‌کند، نه گره‌های جزئی را. اگر در طول زمان‌بندی backfill، یک کار یک یا چند کار دیگر را قبضه کند، کل گره‌های مربوط به آن کارهای قبضه‌شده برای کار قبضه‌کننده (preemptor) رزرو می‌شوند، حتی اگر کار قبضه‌کننده منابع کمتری از آن مقدار درخواست کرده باشد. این گره‌های رزروشده در طول آن چرخه backfill برای کارهای دیگر در دسترس نیستند، حتی اگر کارهای دیگر بتوانند روی آن گره‌ها جا شوند. بنابراین، کارها ممکن است در طول یک تکرار منفرد backfill، منابع بیشتری را نسبت به آنچه درخواست کرده‌اند قبضه کنند.
NOTE: برای اینکه یک کار ناهمگن (heterogeneous job) برای قبضه در نظر گرفته شود، تمام مؤلفه‌های آن باید واجد شرایط قبضه باشند. هنگامی که قرار است یک کار ناهمگن قبضه شود، اولین مؤلفه شناسایی‌شده از کار با بالاترین مرتبه PreemptMode (SUSPEND (بالاترین)، REQUEUE، CANCEL (پایین‌ترین)) برای تنظیم PreemptMode برای تمام مؤلفه‌ها استفاده خواهد شد. مقدار GraceTime و سیگنال هشدار کاربر برای هر مؤلفه از کار ناهمگن منحصر‌به‌فرد باقی می‌ماند. کارهای ناهمگن از عملیات زمان‌بندی GANG مستثنی هستند.

مقدار پیش‌فرض است و قبضه کارها و زمان‌بندی گروهی را غیرفعال می‌کند. این گزینه تنها با غیرفعال بودن قبضه در سطح سراسری (global) سازگار است. یک مورد استفاده معمول برای این پارامتر، تنظیم آن روی یک پارتیشن برای غیرفعال کردن قبضه برای آن پارتیشن است.
کار قبضه‌شده لغو خواهد شد.
زمان‌بندی گروهی (تسهیم زمانی یا time slicing) کارها در همان پارتیشن را فعال می‌کند و اجازه ازسرگیری کارهای معلق‌شده (suspended) را می‌دهد. به منظور استفاده از زمان‌بندی گروهی، گزینه GANG باید در سطح کلاستر مشخص شود.

NOTE: اگر زمان‌بندی GANG با PreemptType=preempt/partition_prio فعال باشد، کنترلر مقادیر PreemptParameters زیر را نادیده خواهد گرفت: reorder_count، strict_order و youngest_first.

NOTE: زمان‌بندی گروهی به‌طور مستقل برای هر پارتیشن انجام می‌شود، بنابراین اگر فقط خواهان تسهیم زمانی با OverSubscribe بدون هیچ‌گونه قبضه‌ای هستید، پیکربندی پارتیشن‌ها با گره‌های همپوشان توصیه نمی‌شود. از سوی دیگر، اگر می‌خواهید از PreemptType=preempt/partition_prio استفاده کنید تا به کارهای پارتیشن‌های PriorityTier بالاتر اجازه دهید کارهای پارتیشن‌های PriorityTier پایین‌تر را تعلیق (Suspend) کنند، به پارتیشن‌های همپوشان و PreemptMode=SUSPEND,GANG نیاز خواهید داشت تا از زمان‌بند Gang برای ازسرگیری کار(های) معلق‌شده استفاده کنید. شما باید تنظیم OverSubscribe پارتیشن را روی FORCE برای تمام پارتیشن‌هایی که قرار است تسهیم زمانی در آن‌ها انجام شود، پیکربندی کنید. در هر صورت، تسهیم زمانی بین کارهای روی پارتیشن‌های مختلف رخ نخواهد داد.

NOTE: کارهای ناهمگن از عملیات زمان‌بندی GANG مستثنی هستند.

NOTE: در صورت وجود پارتیشن‌های همپوشان: اگر به یک گره کاری تخصیص داده شود که امکان اشتراک‌گذاری منابع را فراهم می‌کند (Oversubscribe=FORCE یا Oversubscribe=YES و کار با -s/--oversubscribe ثبت شده باشد)، آن گره فقط می‌تواند توسط کارهایی از همان پارتیشن تخصیص یابد.

کارها را با قرار دادن مجدد آن‌ها در صف (در صورت امکان) یا لغو آن‌ها قبضه می‌کند. برای اینکه کارها دوباره در صف قرار گیرند، باید گزینه sbatch به صورت --requeue تنظیم شده باشد یا پارامتر سراسری JobRequeue در slurm.conf روی 1 تنظیم شده باشد.
کارهای قبضه‌شده به حالت تعلیق درمی‌آیند و بعداً زمان‌بند Gang آن‌ها را از سر می‌گیرد. بنابراین حالت قبضه SUSPEND همیشه نیازمند مشخص شدن گزینه GANG در سطح کلاستر است. همچنین، از آنجا که کارهای معلق همچنان از حافظه روی گره‌های تخصیص‌یافته استفاده خواهند کرد، Slurm برای اینکه بتواند کارها را معلق کند باید قادر به ردیابی منابع حافظه باشد.
هنگام تعلیق کارها، Slurm سیگنال SIGTSTP را ارسال می‌کند، به میزان زمان مشخص‌شده توسط PreemptParameters=suspend_grace_time (پیش‌فرض ۲ ثانیه است) منتظر می‌ماند، سپس سیگنال SIGSTOP را ارسال می‌کند. سیگنال SIGCONT هنگام ازسرگیری کارها ارسال می‌شود.
اگر PreemptType=preempt/qos پیکربندی شده باشد و اگر کار(های) قبضه‌شده و کار قبضه‌کننده در همان پارتیشن باشند، آن‌ها منابع را با زمان‌بند Gang به اشتراک می‌گذارند (تسهیم زمانی). در غیر این صورت (یعنی اگر قبضه‌شوندگان و قبضه‌کننده در پارتیشن‌های متفاوتی باشند) کارهای قبضه‌شده تا زمانی که کار قبضه‌کننده پایان یابد در حالت تعلیق باقی خواهند ماند.

NOTE: از آنجا که زمان‌بندی گروهی به‌طور مستقل برای هر پارتیشن انجام می‌شود، در صورت استفاده از PreemptType=preempt/partition_prio، کارهای موجود در پارتیشن‌های با PriorityTier بالاتر، کارهای موجود در پارتیشن‌های با PriorityTier پایین‌تر را به حالت تعلیق درمی‌آورند تا روی منابع آزادشده اجرا شوند. تنها زمانی که کار قبضه‌کننده پایان یابد، کارهای معلق‌شده توسط زمان‌بند Gang از سر گرفته خواهند شد.
NOTE: کارهای معلق‌شده منابع GRES را آزاد نخواهند کرد. کارهای با اولویت بالاتر قادر نخواهند بود برای دسترسی به GRES اقدام به قبضه کنند.

تنها در صورتی اجازه قبضه را می‌دهد که اولویت کار قبضه‌کننده بالاتر از اولویت کار قبضه‌شونده باشد.
برای PreemptType=preempt/qos، به کارهای درون یک qos یکسان اجازه می‌دهد تا یکدیگر را قبضه کنند. در حالی که این گزینه می‌تواند در اینجا به صورت سراسری تنظیم شود، توصیه می‌شود که به جای آن فقط مستقیماً روی زیرمجموعه مربوطه‌ای از مقادیر qos سیستم تنظیم گردد.
چندین گزینه می‌توانند با کاما از هم جدا شوند.
در صورت تنظیم، ممکن است کارها برای بازپس‌گیری مجوزها پیش‌دستی شوند. در غیر این صورت کارهایی که مجوزهای مشغول را درخواست می‌کنند، حتی اگر اولویت پیش‌دستی داشته باشند، باید منتظر بمانند. منطق پشتیبانی از این گزینه تنها در افزونه select/cons_tres موجود است. کارهایی که در درخواست مجوز از OR استفاده می‌کنند واجد شرایط پیش‌دستی بر سایر کارها برای بازپس‌گیری مجوزها نیستند.
مقدار پیش‌فرض 1 است. مقادیر بالا ممکن است بر کارایی تأثیر منفی بگذارند. تغییرات در ترتیب کارها در این تلاش‌ها را می‌توان با strict_order فعال کرد. منطق پشتیبانی از این گزینه تنها در افزونه select/cons_tres موجود است.
ارسال سیگنال کاربر (مانند --signal=<sig_num>) در زمان پیش‌دستی حتی اگر زمان سیگنال فرا نرسیده باشد. در صورت پیش‌دستی با مهلت زمانی (gracetime preemption)، اگر سیگنال کاربر مشخص شده و ارسال نشده باشد ارسال خواهد شد، در غیر این صورت یک SIGTERM به وظایف ارسال می‌شود.
هنگام مرتب‌سازی مجدد کارهای قابل پیش‌دستی، آخرین کار آزمایش‌شده را در ابتدای فهرست قرار می‌دهد زیرا مطمئن هستیم که واقعاً منابع مورد نیاز کار جدید را اضافه کرده است. این تضمین می‌کند که با تلاش‌های مرتب‌سازی مجدد کافی، کمترین تعداد ممکن از کارها پیش‌دستی شوند. همچنین reorder_count را ببینید. منطق پشتیبانی از این گزینه تنها در افزونه select/cons_tres موجود است.
زمان مهلت پیش‌دستی را بر حسب ثانیه هنگام استفاده از PreemptMode=SUSPEND مشخص می‌کند. هنگامی که یک کار تعلیق می‌شود، سیگنال SIGTSTP ارسال خواهد شد و سپس پس از سپری شدن زمان مهلت تعلیق مشخص‌شده، سیگنال SIGSTOP ارسال می‌شود. مقدار پیش‌فرض 2 ثانیه است.
NOTE: این پارامتر تنها زمانی استفاده می‌شود که PreemptMode=SUSPEND پیکربندی شده باشد یا هنگام تعلیق کارها با scontrol suspend. برای تنظیم زمان مهلت پیش‌دستی هنگام استفاده از سایر حالت‌های پیش‌دستی، GraceTime را ببینید.
در صورت تنظیم، الگوریتم مرتب‌سازی پیش‌دستی تغییر خواهد کرد تا بر اساس زمان شروع کارها مرتب شود و پیش‌دستی کارهای جدیدتر نسبت به کارهای قدیمی‌تر ترجیح داده شود. (نیازمند افزونه‌های preempt/partition_prio یا preempt/qos است.)
افزونه مورد استفاده برای شناسایی اینکه کدام کارها می‌توانند به منظور شروع یک کار در انتظار پیش‌دستی شوند را مشخص می‌کند. به‌طور پیش‌فرض تنظیم نشده است.
پیش‌دستی کار بر اساس PriorityTier پارتیشن است. کارهای موجود در پارتیشن‌های با PriorityTier بالاتر می‌توانند بر کارهای پارتیشن‌های با PriorityTier پایین‌تر پیش‌دستی کنند. این با PreemptMode=OFF سازگار نیست.
قوانین پیش‌دستی کار توسط مشخصات کیفیت خدمات (QOS) در پایگاه داده Slurm مشخص می‌شوند. در صورت استفاده از PreemptMode=SUSPEND، یک کار پیش‌دستی‌کننده باید به پارتیشنی با PriorityTier بالاتر یا به همان پارتیشن ارسال شود. ارسال به همان پارتیشن نیز پشتیبانی می‌شود که باعث می‌شود QoS پیش‌دستی‌کننده، QoS پیش‌دستی‌شونده را به‌صورت گروهی زمان‌بندی (gang schedule) کند. این گزینه با PreemptMode=OFF سازگار نیست. پیکربندی PreemptMode=SUSPEND تنها توسط افزونه SelectType=select/cons_tres پشتیبانی می‌شود. برای پیکربندی گزینه‌های preempt/qos، صفحه راهنمای sacctmgr را ببینید.
گزینه سراسری برای حداقل زمان اجرای تمام کارها قبل از اینکه بتوانند برای پیش‌دستی در نظر گرفته شوند. هر PreemptExemptTime مربوط به QOS بر گزینه سراسری اولویت دارد.
زمان -1 این گزینه را غیرفعال می‌کند که معادل 0 است. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days-hours"، "days-hours:minutes" و "days-hours:minutes:seconds" هستند.
پارامترهایی که باید به PrEpPlugins منتقل شوند.
منبعی برای برنامه‌نویسانی که مایل به نوشتن افزونه‌های اختصاصی خود برای اسکریپت‌های Prolog و Epilog (PrEp) هستند. افزونه پیش‌فرض و در حال حاضر تنها افزونه پیاده‌سازی‌شده prep/script است. افزونه‌های اضافی را می‌توان در یک فهرست جداشده با کاما مشخص کرد. برای اطلاعات بیشتر لطفاً صفحه مستندات PrEp Plugin API را ببینید: https://slurm.schedmd.com/prep_plugins.html
مدت زمان بر حسب دقیقه که در آن زوال نیمه‌عمر (half-life decay) دوباره محاسبه خواهد شد. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقدار پیش‌فرض 5 (دقیقه) است.
این پارامتر کنترل می‌کند که در تعیین اولویت کار، مصرف قبلی منابع تا چه مدت برای مشخص کردن میزان سرویس‌دهی بیش از حد یا کمتر از حد به یک انتساب (association) (کاربر، حساب کاربری و کلاستر) در نظر گرفته شود. سوابق استفاده در طول زمان دچار زوال خواهند شد، به‌طوری که نیمی از مقدار اولیه در زمان رسیدن به سن PriorityDecayHalfLife پاک می‌شود. اگر روی 0 تنظیم شود، هیچ زوالی اعمال نخواهد شد. این امر در صورتی مفید است که بخواهید محدودیت‌های زمانی سختی را برای هر انتساب اعمال کنید. اگر روی 0 تنظیم شود، PriorityUsageResetPeriod باید روی یک بازه زمانی تنظیم شود. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. واحد آن یک رشته زمانی است (مانند min، hr:min:00، days-hr:min:00 یا days-hr). مقدار پیش‌فرض 7-0 (۷ روز) است.
مشخص می‌کند که کارهای کوچک باید اولویت زمان‌بندی ترجیحی دریافت کنند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقادیر پشتیبانی‌شده "YES" و "NO" هستند. مقدار پیش‌فرض "NO" است.
پرچم‌هایی برای تغییر رفتار اولویت. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. کلمات کلیدی زیر مقدار مرتبطی ندارند (مانند "PriorityFlags=ACCRUE_ALWAYS,SMALL_RELATIVE_TO_TIME").
در صورت تنظیم، عامل سن اولویت علی‌رغم واجد شرایط نبودن کار به دلیل وابستگی‌ها، نگه‌داشت‌ها (holds) یا زمان شروع در آینده، افزایش خواهد یافت. محدودیت‌های انباشت (accrue limits) نادیده گرفته می‌شوند.
در صورت تنظیم، اولویت‌ها نه تنها برای کارهای در انتظار، بلکه برای کارهای در حال اجرا و تعلیق‌شده نیز مجدداً محاسبه خواهند شد.
در صورت تنظیم، اولویت مشابه محاسبه چندعاملی معمولی محاسبه خواهد شد، اما عمق انتساب‌ها در درخت تأثیر منفی بر اولویت آن‌ها نخواهد گذاشت. این گزینه به‌طور خودکار NO_FAIR_TREE را فعال می‌کند.
الگوریتم "fair tree" را غیرفعال کرده و به زمان‌بندی اولویت سهم عادلانه "classic" بازمی‌گرداند.
در صورت تنظیم، مقادیر اولویت فقط افزایش خواهند یافت. اولویت کار هرگز کاهش نخواهد یافت.
در صورت تنظیم، مقدار وزنی TRES (TRESBillingWeights) به عنوان مجموع موارد زیر محاسبه می‌شود:
- بیشینه (MAX) مربوط به TRESهای منفرد (آن‌هایی که به یک گره خاص متصل هستند، مانند cpus، mem، gres)
- مجموع (SUM) تمام TRESهای سراسری (آن‌هایی که در هر گره‌ای در دسترس هستند، مانند licenses)
برای جزئیات بیشتر به صفحه TRES مراجعه کنید: https://slurm.schedmd.com/tres.html
در صورت تنظیم، مقدار وزنی TRES (TRESBillingWeights) به عنوان مجموع موارد زیر محاسبه می‌شود:
- مجموع (SUM) تمام GRESهای قابل صورت‌حساب (مانند GPUها)
- بیشینه (MAX) سایر TRESهای منفرد (آن‌هایی که به یک گره خاص متصل هستند، مانند cpus، mem)
- مجموع (SUM) تمام TRESهای سراسری (آن‌هایی که در هر گره‌ای در دسترس هستند، مانند licenses)
در Slurm 25.05 اضافه شده است. برای جزئیات بیشتر به صفحه TRES مراجعه کنید: https://slurm.schedmd.com/tres.html
در صورت تنظیم، تمام پرچم‌های NO_NORMAL_* تنظیم می‌شوند.
در صورت تنظیم، عامل انتساب نسبت به بالاترین اولویت انتساب نرمال‌سازی نمی‌شود.
در صورت تنظیم، عامل پارتیشن نسبت به بالاترین PriorityJobFactor پارتیشن نرمال‌سازی نمی‌شود.
در صورت تنظیم، عامل QOS نسبت به بالاترین اولویت qos نرمال‌سازی نمی‌شود.
در صورت تنظیم، عامل TRES نسبت به تعداد TRES پارتیشن کار نرمال‌سازی نمی‌شود.
در صورت تنظیم، مؤلفه اندازه کار نه تنها بر اساس اندازه کار به تنهایی، بلکه بر اساس اندازه کار تقسیم بر محدودیت زمانی آن خواهد بود.
سن کاری را مشخص می‌کند که حداکثر عامل سن در محاسبه اولویت به آن اختصاص داده می‌شود. برای مثال، مقدار 30 دقیقه منجر به این می‌شود که تمام کارهایی با بیش از 30 دقیقه سن، اولویت مبتنی بر سن یکسانی دریافت کنند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. واحد آن یک رشته زمانی است (مانند min، hr:min:00، days-hr:min:00 یا days-hr). مقدار پیش‌فرض 7-0 (۷ روز) است.
رشته دلخواهی که توسط افزونه PriorityType استفاده می‌شود.
رشته دلخواهی که توسط افزونه PrioritySiteFactorPlugin استفاده می‌شود.
این پارامتر یک افزونه اختیاری را مشخص می‌کند که در کنار "priority/multifactor" استفاده می‌شود و هدف آن تنظیم اولیه و به‌روزرسانی مداوم عامل اولویت SiteFactor است. به‌طور پیش‌فرض تنظیم نشده است.
این پارامتر افزونه‌ای را مشخص می‌کند که برای تعیین اولویت زمان‌بندی کار استفاده می‌شود. همچنین برای گزینه‌های پیکربندی PriorityFlags را ببینید. مقدار پیش‌فرض "priority/multifactor" است.
کارها به صورت ورودی اول، خروجی اول (FIFO) ارزیابی می‌شوند.
به کارها بر اساس عوامل گوناگونی که شامل اندازه، سن، سهم عادلانه (Fairshare) و غیره است، اولویت اختصاص داده می‌شود.
هنگامی که زمان‌بندی بر اساس FIFO نباشد، کارها به ترتیب زیر اولویت‌بندی می‌شوند:

1. کارهایی که می‌توانند پیش‌دستی کنند
2. کارها با رزرو پیشرفته (advanced reservation)
3. PriorityTier پارتیشن
4. اولویت کار
5. زمان ارسال کار
6. شناسه کار (Job ID)

در این بازه زمانی، میزان مصرف انتساب‌ها به 0 بازنشانی می‌شود. این گزینه در صورتی استفاده می‌شود که بخواهید محدودیت‌های سختی را برای مصرف زمانی به ازای هر انتساب اعمال کنید. اگر PriorityDecayHalfLife روی 0 تنظیم شده باشد، هیچ زوالی رخ نخواهد داد و این تنها راه برای بازنشانی میزان مصرف انباشته‌شده توسط کارهای در حال اجرا است. به‌طور پیش‌فرض این گزینه غیرفعال است و توصیه می‌شود از گزینه PriorityDecayHalfLife استفاده کنید تا از خالی ماندن کلاستر و اجرا نشدن کارها جلوگیری شود، اما اگر ساختار شما به‌گونه‌ای تنظیم شده که فقط مقدار معینی از زمان را در سیستم شما مجاز می‌داند، این روش انجام آن است. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد.
هرگز سوابق مصرف پاک نشود. مقدار پیش‌فرض.
سوابق مصرف همین حالا پاک شود. در زمان راه‌اندازی و پیکربندی مجدد اجرا می‌شود.
هر روز در نیمه‌شب پاک می‌شود.
هر هفته در روز یکشنبه در ساعت 00:00 پاک می‌شود.
در اولین روز هر ماه در ساعت 00:00 پاک می‌شود.
در اولین روز هر فصل در ساعت 00:00 پاک می‌شود.
در اولین روز هر سال در ساعت 00:00 پاک می‌شود.
یک مقدار عددی صحیح که میزان تأثیر مؤلفه زمان انتظار در صف را بر اولویت کار تعیین می‌کند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. نیازمند AccountingStorageType=accounting_storage/slurmdbd است. مقدار پیش‌فرض 0 است.
یک مقدار عددی صحیح که میزان تأثیر مؤلفه انتساب را بر اولویت کار تعیین می‌کند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقدار پیش‌فرض 0 است.
یک مقدار عددی صحیح که میزان تأثیر مؤلفه سهم عادلانه (fair-share) را بر اولویت کار تعیین می‌کند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. نیازمند AccountingStorageType=accounting_storage/slurmdbd است. مقدار پیش‌فرض 0 است.
یک مقدار عددی صحیح که میزان تأثیر مؤلفه اندازه کار را بر اولویت کار تعیین می‌کند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقدار پیش‌فرض 0 است.
عامل پارتیشن مورد استفاده توسط افزونه priority/multifactor در محاسبه اولویت کار. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقدار پیش‌فرض 0 است.
یک مقدار عددی صحیح که میزان تأثیر مؤلفه کیفیت خدمات (Quality Of Service) را بر اولویت کار تعیین می‌کند. تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد. مقدار پیش‌فرض 0 است.
فهرستی جداشده با کاما از انواع TRES و وزن‌ها که میزان تأثیر هر نوع TRES را بر اولویت کار تعیین می‌کند.
e.g.
PriorityWeightTRES=CPU=1000,Mem=2000,GRES/gpu=3000

تنها در صورتی کاربرد دارد که PriorityType=priority/multifactor باشد و AccountingStorageTRES با هر نوع TRES پیکربندی شده باشد. مقادیر منفی مجاز هستند. مقادیر پیش‌فرض 0 هستند.

این پارامتر کنترل می‌کند چه نوع اطلاعاتی از کاربران عادی پنهان شود. به‌طور پیش‌فرض، تمام اطلاعات برای همه کاربران قابل مشاهده است. کاربران SlurmUser و root همیشه می‌توانند تمام اطلاعات را مشاهده کنند. این گزینه در صورت تنظیم، باعث می‌شود نقاط پایانی افزونه‌های متریک محدود شوند (به علاوه فعال‌سازی احراز هویت JWT برای کوئری گرفتن) و تنها برای SlurmUser و root در دسترس باشند، مگر اینکه MetricsAuthUsers یا MetricsParameters=ignore_private_data پیکربندی شده باشند. چندین مقدار را می‌توان با جداکننده کاما مشخص کرد. مقادیر قابل قبول عبارتند از:
(فقط در حالت حسابداری بدون SlurmDBD) از مشاهده هرگونه تعاریف حساب کاربری توسط کاربران جلوگیری می‌کند، مگر اینکه آن‌ها هماهنگ‌کننده (coordinator) آن حساب‌ها باشند.
از مشاهده اطلاعات رویداد توسط کاربران جلوگیری می‌کند، مگر اینکه وضعیت عملگر (operator) یا بالاتر داشته باشند.
از مشاهده کارها یا گام‌های کاری متعلق به سایر کاربران جلوگیری می‌کند. (فقط در حالت حسابداری بدون SlurmDBD) هنگام استفاده از sacct، از مشاهده سوابق کاری متعلق به سایر کاربران توسط کاربران جلوگیری می‌کند، مگر اینکه هماهنگ‌کننده انتسابِ اجراکننده کار باشند.
از مشاهده اطلاعات وضعیت گره‌ها توسط کاربران جلوگیری می‌کند.
از مشاهده اطلاعات وضعیت پارتیشن‌ها توسط کاربران جلوگیری می‌کند.
از مشاهده رزروهایی که کاربران عادی نمی‌توانند از آن‌ها استفاده کنند، جلوگیری می‌کند.

NOTE: محدودیت‌های QOS و AllowedPartitions روی رزرو برای این گزینه اعمال نمی‌شوند.

از مشاهده میزان مصرف هر کاربر دیگر توسط کاربران جلوگیری می‌کند؛ این امر در مورد 'sshare' و سوابق انتساب از طریق 'scontrol show assoc_mgr' اعمال می‌شود. (فقط در حالت حسابداری بدون SlurmDBD) از مشاهده میزان مصرف هر کاربر دیگر توسط کاربران جلوگیری می‌کند؛ این امر در مورد sreport اعمال می‌شود.
(فقط در حالت حسابداری بدون SlurmDBD) از مشاهده اطلاعات هر کاربری به جز خودشان توسط کاربران جلوگیری می‌کند؛ این همچنین باعث می‌شود کاربران تنها بتوانند انتساب‌هایی را ببینند که با آن‌ها سر و کار دارند. هماهنگ‌کننده‌ها می‌توانند انتساب‌های تمام کاربران حسابی را که هماهنگ‌کننده آن هستند ببینند، اما هنگام فهرست کردن کاربران، فقط می‌توانند خودشان را ببینند.
افزونه‌ای را مشخص می‌کند که برای ردیابی فرآیندها بر اساس گام کار (job step) استفاده می‌شود. دیمن slurmd از این سازوکار برای شناسایی تمام فرآیندهایی که فرزند فرآیندهای ایجادشده توسط آن برای یک گام کاری کاربر هستند، استفاده می‌کند. NOTE: گزینه‌های "proctrack/linuxproc" و "proctrack/pgid" می‌توانند در شناسایی تمام فرآیندهای مرتبط با یک کار ناموفق باشند، زیرا فرآیندها می‌توانند فرزند فرآیند init شوند (زمانی که فرآیند والد پایان می‌یابد) یا گروه فرآیندی خود را تغییر دهند. برای ردیابی قابل اطمینان تمام فرآیندها، "proctrack/cgroup" به‌شدت توصیه می‌شود. NOTE: پارامتر NamespaceType برای جداسازی فضای نام کار اعمال می‌شود، در حالی که ProctrackType برای محدودیت‌های منابع کار و ردیابی آن کاربرد دارد. مقادیر قابل قبول در حال حاضر عبارتند از:
از cgroupهای لینوکس برای محدود کردن و ردیابی فرآیندها استفاده می‌کند و برای سیستم‌هایی با پشتیبانی از cgroup پیش‌فرض است.
NOTE: برای جزئیات پیکربندی "man cgroup.conf" را ببینید.
از درخت فرآیند لینوکس با استفاده از شناسه‌های فرآیند والد (parent process IDs) استفاده می‌کند.
از شناسه‌های گروه فرآیند (Process Group IDs) استفاده می‌کند.
NOTE: این مقدار پیش‌فرض برای خانواده BSD است.
مسیر پرونده برنامه‌ای که دیمن slurmd هر زمان که از آن خواسته شود یک گام کاری را از یک تخصیص کار جدید اجرا کند، باید اجرا نماید. اگر این مسیر یک مسیر مطلق نباشد (یعنی با اسلش شروع نشود)، باید نسبت به شاخه حاوی پرونده slurm.conf باشد. همچنین می‌توان از یک الگوی glob (به glob (7) مراجعه کنید) برای مشخص کردن بیش از یک برنامه جهت اجرا استفاده کرد (مانند "/etc/slurm/prolog.d/*"). هنگامی که بیش از یک اسکریپت prolog پیکربندی شده باشد، آن‌ها به ترتیب الفبای معکوس (z-a -> Z-A -> 9-0) اجرا می‌شوند. دیمن slurmd پیش از شروع اولین گام کاری، prolog را اجرا می‌کند. اسکریپت یا اسکریپت‌های prolog ممکن است برای پاکسازی پرونده‌ها، فعال کردن ورود کاربر و غیره استفاده شوند. به‌طور پیش‌فرض هیچ prologای وجود ندارد. انتظار می‌رود هر اسکریپت پیکربندی‌شده اجرای خود را به سرعت (در زمانی کمتر از MessageTimeout) به پایان برساند. اگر prolog با شکست مواجه شود (یک کد خروج غیر صفر برگرداند)، این امر منجر به قرار گرفتن گره در وضعیت DRAIN و قرارگیری مجدد کار در صف (requeue) خواهد شد. کار در وضعیت نگه‌داشته (held) قرار خواهد گرفت، مگر اینکه nohold_on_prolog_fail در SchedulerParameters پیکربندی شده باشد. برای اطلاعات بیشتر Prolog and Epilog Scripts را ببینید.

NOTE: می‌توان با گنجاندن این گزینه در چندین خط، چندین اسکریپت prolog را پیکربندی کرد.

مدت زمان بر حسب ثانیه که Slurm پیش از خاتمه دادن به اسکریپت‌های Prolog و Epilog منتظر آن‌ها می‌ماند. رفتار پیش‌فرض این است که به طور نامحدود منتظر بماند. این بازه زمانی برای Prolog و Epilog اجراشده توسط دیمن slurmd قبل و بعد از کار، PrologSlurmctld و EpilogSlurmctld اجراشده توسط دیمن slurmctld، و فراخوانی‌های prolog/epilog افزونه SPANK یعنی slurm_spank_job_prolog و slurm_spank_job_epilog اعمال می‌شود.
اگر مهلت PrologSlurmctld به پایان برسد، کار در صورت امکان مجدداً در صف قرار می‌گیرد. اگر مهلت Prolog یا slurm_spank_job_prolog به پایان برسد، کار در صورت امکان مجدداً در صف قرار می‌گیرد و گره تخلیه (drain) می‌شود. اگر مهلت Epilog یا slurm_spank_job_epilog به پایان برسد، گره تخلیه می‌شود. در تمام موارد، خطاها ثبت می‌شوند.
NOTE: این مقدار در صورتی که PrologTimeout پیکربندی شده باشد برای prologها استفاده نمی‌شود. به همین ترتیب، این مقدار در صورتی که EpilogTimout پیکربندی شده باشد برای epilogها استفاده نمی‌شود.
مدت زمان بر حسب ثانیه که Slurm پیش از خاتمه دادن به Prolog منتظر آن می‌ماند. مقدار پیش‌فرض PrologEpilogTimeout است. این بازه زمانی برای Prolog اجراشده توسط دیمن slurmd قبل از کار، PrologSlurmctld اجراشده توسط دیمن slurmctld، و فراخوانی prolog افزونه SPANK یعنی slurm_spank_job_prolog اعمال می‌شود.
اگر مهلت PrologSlurmctld به پایان برسد، کار در صورت امکان مجدداً در صف قرار می‌گیرد. اگر مهلت Prolog یا slurm_spank_job_prolog به پایان برسد، کار در صورت امکان مجدداً در صف قرار می‌گیرد و گره تخلیه (drain) می‌شود. در تمام موارد، خطاها ثبت می‌شوند.
پرچم‌هایی برای کنترل رفتار Prolog. به‌طور پیش‌فرض هیچ پرچمی تنظیم نشده است. چندین پرچم را می‌توان در یک فهرست جداشده با کاما مشخص کرد. گزینه‌های پشتیبانی‌شده در حال حاضر عبارتند از:
در صورت تنظیم، اسکریپت Prolog همیشه هنگام تخصیص کار اجرا خواهد شد. در غیر این صورت، Prolog درست قبل از راه‌اندازی اولین وظیفه اجرا می‌شود که شامل گام‌های دسته‌ای و تعاملی است (به LaunchParameters=use_interactive_step مراجعه کنید). گزینه Alloc می‌تواند برای آماده‌سازی موارد قبل از شروع استفاده کاربر از منابع تخصیص‌یافته مفید باشد. به ویژه، این پرچم در سیستم‌های Cray هنگامی که حالت سازگاری کلاستر فعال است، مورد نیاز است.

NOTE: استفاده از پرچم Alloc زمان لازم برای شروع کارها را افزایش می‌دهد.

در زمان تخصیص کار، از افزونه ProcTrack برای ایجاد یک ظرف کار (job container) روی تمام گره‌های محاسباتی تخصیص‌یافته استفاده می‌کند. این ظرف ممکن است برای فرآیندهای کاربری که تحت کنترل Slurm راه‌اندازی نشده‌اند استفاده شود؛ برای مثال pam_slurm_adopt ممکن است فرآیندهایی را که از طریق ورود مستقیم کاربر راه‌اندازی شده‌اند در این ظرف قرار دهد. در صورت استفاده از pam_slurm_adopt، مقدار ProcTrackType باید روی proctrack/cgroup تنظیم شود.

تنظیم پرچم Contain به‌طور ضمنی پرچم Alloc را نیز تنظیم می‌کند.

در صورت تنظیم، slurmctld پیش از ارسال درخواست راه‌اندازی کار دسته‌ای، منتظر می‌ماند تا prolog روی تمام گره‌های تخصیص‌یافته تکمیل شود. اگر فقط پرچم Alloc تنظیم شده باشد، slurmctld به محض اینکه گره دسته‌ای کار، prolog را تکمیل کند، گام دسته‌ای را راه‌اندازی خواهد کرد.

تنظیم پرچم DeferBatch به‌طور ضمنی پرچم Alloc را نیز تنظیم می‌کند.

این پرچم به salloc اجازه می‌دهد تا زمانی که prolog در هر گره به پایان نرسیده است مسدود نشود. مسدودسازی زمانی رخ خواهد داد که گام‌ها به slurmd برسند و قبل از اینکه هرگونه اجرایی در گام صورت گرفته باشد. این روشی بسیار سریع‌تر برای کار است و اگر از srun برای راه‌اندازی وظایف خود استفاده می‌کنید باید از این پرچم استفاده کنید. این پرچم را نمی‌توان با پرچم‌های Contain یا X11 ترکیب کرد.

تنظیم پرچم NoHold به‌طور ضمنی پرچم Alloc را نیز تنظیم می‌کند.

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

تنظیم پرچم ForceRequeueOnFail به‌طور ضمنی پرچم Alloc را نیز تنظیم می‌کند.

باعث می‌شود Prolog/Epilog در slurmstepd خارجی اجرا شود. این کار آن را در یکی از فرآیندهای کار مهار می‌کند. در صورت پیکربندی، این کار آن را در cgroup مهار خواهد کرد.

تنظیم پرچم RunInJob به‌طور ضمنی پرچم‌های Contain و Alloc را تنظیم می‌کند.

به‌طور پیش‌فرض، اسکریپت‌های Prolog و Epilog به‌صورت هم‌روند روی هر گره اجرا می‌شوند. این پرچم این اسکریپت‌ها را وادار می‌کند تا در هر گره به‌صورت متوالی اجرا شوند، اما با افت قابل توجهی در توان عملیاتی کار (job throughput) روی هر گره همراه است.

NOTE: این گزینه با RunInJob ناسازگار است.

قابلیت‌های داخلی فورواردینگ X11 در Slurm را فعال می‌کند. این گزینه با ProctrackType=proctrack/linuxproc ناسازگار است.

تنظیم پرچم X11 به‌طور ضمنی پرچم‌های Contain و Alloc را تنظیم می‌کند.

مسیر کامل پرونده برنامه‌ای که دیمن slurmctld باید قبل از اعطای یک تخصیص کار جدید اجرا کند (مانند "/usr/local/slurm/prolog_controller"). این برنامه به عنوان SlurmUser روی همان گره‌ای که دیمن slurmctld اجرا می‌شود اجرا می‌گردد و به آن اجازه می‌دهد تا در صورت بروز خرابی، گره‌ها را تخلیه (drain) کرده و کار را مجدداً در صف قرار دهد یا در صورت لزوم کار را لغو کند. دقیقاً اینکه برنامه چه کاری انجام می‌دهد و چگونه به آن دست می‌یابد کاملاً به صلاحدید مدیر سیستم است. اطلاعات مربوط به کاری که در حال شروع است، گره‌های تخصیص‌یافته به آن و غیره با استفاده از متغیرهای محیطی به برنامه منتقل می‌شوند. در حین اجرای این برنامه، گره‌های مرتبط با کار پرچم POWER_UP/CONFIGURING را در وضعیت خود تنظیم خواهند داشت که به راحتی قابل مشاهده است. دیمن slurmctld برای تکمیل این برنامه به طور نامحدود منتظر می‌ماند. پس از اینکه برنامه با کد خروج صفر به پایان رسید، گره‌ها آماده استفاده در نظر گرفته شده و برنامه راه‌اندازی خواهد شد. اگر گره‌ای نتواند برای استفاده در دسترس قرار گیرد، برنامه باید گره را تخلیه کند (معمولاً با استفاده از دستور scontrol) و با یک کد خروج غیر صفر پایان یابد. یک کد خروج غیر صفر منجر به قرارگیری مجدد کار در صف (در صورت امکان) یا پایان دادن به آن خواهد شد. توجه داشته باشید که تنها کارهای دسته‌ای می‌توانند مجدداً در صف قرار گیرند. برای اطلاعات بیشتر Prolog and Epilog Scripts را ببینید.

NOTE: می‌توان با گنجاندن این گزینه در چندین خط، چندین اسکریپت prolog را پیکربندی کرد.

اولویت زمان‌بندی (nice value) وظایف ایجادشده توسط کاربر را کنترل می‌کند.
0
وظایف اولویت زمان‌بندی را از دیمن slurm به ارث خواهند برد. این مقدار پیش‌فرض است.
1
وظایف اولویت زمان‌بندی دستوری را که برای ارسال آن‌ها استفاده شده است (مانند srun یا sbatch) به ارث خواهند برد. مگر اینکه کار توسط کاربر root ارسال شده باشد، وظایف اولویت زمان‌بندی بالاتر از دیمن slurm ایجادکننده آن‌ها نخواهند داشت.
2
وظایف اولویت زمان‌بندی دستوری را که برای ارسال آن‌ها استفاده شده است (مانند srun یا sbatch) به ارث خواهند برد با این محدودیت که مقدار nice آن‌ها همیشه یک واحد بالاتر از دیمن slurm خواهد بود (یعنی اولویت زمان‌بندی وظایف پایین‌تر از دیمن slurm خواهد بود).
فهرستی جداشده با کاما از نام‌های محدودیت منابع. دیمن slurmd از این نام‌ها برای به‌دست آوردن مقادیر محدودیت (نرم یا soft) مرتبط از محیط فرآیند کاربر در گره ارسال استفاده می‌کند. سپس این محدودیت‌ها انتشار یافته و روی کارهایی که روی گره‌های محاسباتی اجرا خواهند شد اعمال می‌شوند. این پارامتر می‌تواند زمانی مفید باشد که محدودیت‌های سیستم بین گره‌ها متفاوت باشد. هرگونه محدودیت منابعی که در فهرست نمایش داده نشود انتشار نمی‌یابد. با این حال، کاربر می‌تواند با مشخص کردن اینکه کدام محدودیت‌های منابع انتشار یابند با استفاده از گزینه "--propagate" در sbatch یا srun این رفتار را لغو کند. اگر هیچ‌یک از PropagateResourceLimits یا PropagateResourceLimitsExcept پیکربندی نشده باشند و گزینه "--propagate" مشخص نشده باشد، اقدام پیش‌فرض انتشار تمام محدودیت‌ها است. فقط یکی از پارامترهای PropagateResourceLimits یا PropagateResourceLimitsExcept ممکن است مشخص شود. محدودیت‌های کاربر نمی‌تواند از محدودیت‌های سخت (hard limits) که دیمن slurmd تحت آن‌ها کار می‌کند تجاوز کند. اگر محدودیت‌های کاربر انتشار نیابند، محدودیت‌های مربوط به دیمن slurmd به کار کاربر منتقل خواهند شد. محدودیت‌های استفاده‌شده برای دیمن‌های Slurm را می‌توان در پرونده /etc/sysconf/slurm تنظیم کرد. برای اطلاعات بیشتر، ببینید: https://slurm.schedmd.com/faq.html#memlock نام‌های محدودیت زیر توسط Slurm پشتیبانی می‌شوند (اگرچه ممکن است برخی گزینه‌ها در برخی سیستم‌ها پشتیبانی نشوند):
تمام محدودیت‌های ذکرشده در زیر (پیش‌فرض)
هیچ‌یک از محدودیت‌های ذکرشده در زیر
حداکثر فضای آدرس (حافظه مجازی) برای یک فرآیند.
حداکثر اندازه پرونده core
حداکثر میزان زمان CPU
حداکثر اندازه بخش داده (data segment) یک فرآیند
حداکثر اندازه پرونده‌های ایجادشده. توجه داشته باشید که اگر کاربر FSIZE را کمتر از اندازه فعلی slurmd.log تنظیم کند، راه‌اندازی کارها با خطای 'File size limit exceeded' با شکست مواجه خواهد شد.
حداکثر اندازه‌ای که ممکن است در حافظه قفل شود
حداکثر تعداد پرونده‌های باز
حداکثر تعداد فرآیندهای در دسترس
حداکثر اندازه مجموعه مقیم (resident set size). توجه داشته باشید که این فقط در هسته‌های لینوکس 2.4.30 یا قدیمی‌تر یا BSD تأثیر دارد.
حداکثر اندازه پشته
فهرستی از نام‌های محدودیت منبع که با کاما از هم جدا شده‌اند. به‌طور پیش‌فرض، تمام محدودیت‌های منبع منتشر خواهند شد (همان‌طور که توسط پارامتر PropagateResourceLimits شرح داده شده است)، به جز محدودیت‌هایی که در این فهرست ظاهر می‌شوند. کاربر می‌تواند با مشخص کردن اینکه کدام محدودیت‌های منبع با گزینهٔ «--propagate» در sbatch یا srun منتشر شوند، این رفتار را بازنویسی کند. برای مشاهدهٔ فهرستی از نام‌های محدودیت معتبر، PropagateResourceLimits را در بالا ببینید.
برنامه‌ای که باید روی هر گره محاسباتی برای راه‌اندازی مجدد آن اجرا شود. پس از اجرای دستور «scontrol reboot» توسط یک کاربر مجاز یا ثبت کاری با گزینهٔ «--reboot»، این برنامه به محض اینکه گره بیکار شود روی آن فراخوانی می‌گردد. پس از راه‌اندازی مجدد، گره به وضعیت استفادهٔ عادی بازگردانده می‌شود. این مورد همچنین می‌تواند با نام یک PowerAction مقداردهی شود. برای پیکربندی مدت‌زمانی که انتظار دارید راه‌اندازی مجدد تمام شود، به ResumeTimeout مراجعه کنید. اگر یک گره ظرف مدت ResumeTimeout راه‌اندازی مجدد نشود، به عنوان DOWN علامت‌گذاری خواهد شد.
پرچم‌هایی برای کنترل اقدامات مختلفی که ممکن است هنگام اجرای دستور «scontrol reconfig» انجام شود. در حال حاضر گزینه‌ها عبارتند از:
در صورت تنظیم، دستور «scontrol reconfig» مقدار درون‌حافظه‌ای وضعیت («state») پارتیشن و سایر پارامترهایی را که ممکن است به‌صورت پویا توسط «scontrol update» به‌روزرسانی شده باشند حفظ خواهد کرد. اطلاعات پارتیشن در پروندهٔ slurm.conf با داده‌های درون‌حافظه‌ای ادغام خواهد شد. این پرچم جایگزین پرچم KeepPartState می‌شود.
در صورت تنظیم، دستور «scontrol reconfig» تنها مقدار فعلی «state» پارتیشن‌های درون‌حافظه‌ای را حفظ می‌کند و تمام پارامترهای دیگر پارتیشن‌ها را که ممکن است به‌صورت پویا توسط «scontrol update» به‌روزرسانی شده باشند، به مقادیر پروندهٔ slurm.conf بازنشانی خواهد کرد. اطلاعات پارتیشن در پروندهٔ slurm.conf با داده‌های درون‌حافظه‌ای ادغام خواهد شد.
در صورت تنظیم، دستور «scontrol reconfig» وضعیت فعلی SuspendExcNodes، SuspendExcParts و SuspendExcStates را حفظ خواهد کرد.
حالت پیش‌فرض برای پرچم‌های بالا تنظیم‌نشده است و «scontrol reconfig» اطلاعات پارتیشن را تنها با استفاده از تعاریف موجود در پروندهٔ slurm.conf بازسازی خواهد کرد.
صف‌بندی مجدد خودکار را برای کارهای دسته‌ای (batch) که با مقادیر مشخص‌شده خارج می‌شوند، فعال می‌کند. کدهای خروج متعدد را با کاما جدا کنید و/یا با استفاده از جداکنندهٔ «-» محدوده‌های عددی را مشخص نمایید (به عنوان مثال "RequeueExit=1-9,18"). کارها مجدداً در وضعیت در انتظار (pending) قرار گرفته و بعداً دوباره زمان‌بندی خواهند شد. کارهای بازراه‌اندازی‌شده متغیر محیطی SLURM_RESTART_COUNT را برابر با تعداد دفعاتی که کار بازراه‌اندازی شده است، تنظیم خواهند داشت.
صف‌بندی مجدد خودکار را برای کارهای دسته‌ای که با مقادیر مشخص‌شده خارج می‌شوند فعال می‌کند، به‌طوری که این کارها تا زمان آزادسازی دستی توسط کاربر در حالت نگه‌داشته (held) قرار می‌گیرند. کدهای خروج متعدد را با کاما جدا کنید و/یا با استفاده از جداکنندهٔ «-» محدوده‌های عددی را مشخص نمایید (به عنوان مثال "RequeueExitHold=10-12,16"). این کارها در وضعیت خروج JOB_SPECIAL_EXIT قرار می‌گیرند. کارهای بازراه‌اندازی‌شده متغیر محیطی SLURM_RESTART_COUNT را برابر با تعداد دفعاتی که کار بازراه‌اندازی شده است، تنظیم خواهند داشت.
برنامه‌ای که در صورت عدم موفقیت گره‌ها در ازسرگیری تا زمان ResumeTimeout اجرا خواهد شد. آرگومان برنامه نام‌های گره‌های ناموفق خواهد بود (با استفاده از قالب عبارت hostlist در Slurm). این مورد همچنین می‌تواند با نام یک PowerAction مقداردهی شود. اگر برنامه‌ها بیش از بزرگ‌ترین ResumeTimeout یا SuspendTimeout پیکربندی‌شده (سراسری یا پارتیشن) اجرا شوند، متوقف (kill) خواهند شد.
اسلورم (Slurm) از سازوکاری برای کاهش مصرف انرژی در گره‌هایی که برای مدت طولانی بیکار می‌مانند پشتیبانی می‌کند. این کار معمولاً با کاهش ولتاژ و فرکانس یا خاموش کردن گره انجام می‌شود. ResumeProgram برنامه‌ای است که هنگام تخصیص کار به گره‌ای در حالت ذخیرهٔ انرژی، اجرا خواهد شد. این گزینه همچنین می‌تواند با نام یک PowerAction تنظیم شود. به دلایل قابلیت اطمینان، در صورت خرابی و راه‌اندازی مجدد دیمن slurmctld، ممکن است ResumeProgram بیش از یک بار برای یک گره اجرا شود. اگر ResumeProgram نتواند گره را با یک slurmd پاسخگو و یک BootTime به‌روزشده به سرویس بازگرداند، باید وضعیت گره را روی DOWN تنظیم کند که منجر به صف‌بندی مجدد هر کار مرتبط با گره می‌شود - اگر گره ظرف ResumeTimeout ثبت نشود، این اتفاق به‌طور خودکار رخ خواهد داد. می‌توان از SchedulerParameters=requeue_on_resume_failure استفاده کرد تا کارهای دسته‌ای در این وضعیت همیشه در صف مجدد قرار گیرند، حتی اگر کار درخواست عدم صف‌بندی مجدد کرده باشد. اگر گره واقعاً راه‌اندازی مجدد نشده باشد (یعنی زمانی که multiple-slurmd پیکربندی شده است)، شروع slurmd با گزینهٔ «-b» ممکن است مفید باشد. برنامه به عنوان SlurmUser اجرا می‌شود. آرگومان برنامه نام‌های گره‌هایی خواهد بود که باید از حالت ذخیرهٔ انرژی خارج شوند (با استفاده از قالب عبارت hostlist در Slurm). نگاشت کار به گره با خواندن پروندهٔ موقت مشخص‌شده توسط متغیر محیطی SLURM_RESUME_FILE در قالب JSON در دسترس است. این پرونده پس از خاموش شدن slurmctld بسته می‌شود. اگر ResumeProgram در حال اجرا باشد، خاموش شدن slurmctld تا ده ثانیه به تعویق می‌افتد تا به ResumeProgram فرصت خواندن این پرونده داده شود. بنابراین، این پرونده باید در ابتدای ResumeProgram خوانده شود. به‌طور پیش‌فرض هیچ برنامه‌ای اجرا نمی‌شود. اگر برنامه‌ها بیش از بزرگ‌ترین ResumeTimeout یا SuspendTimeout پیکربندی‌شده (سراسری یا پارتیشن) اجرا شوند، متوقف (kill) خواهند شد.
نرخی که در آن گره‌های حالت ذخیرهٔ انرژی توسط ResumeProgram به عملکرد عادی بازگردانده می‌شوند. این مقدار تعداد گره‌ها در دقیقه است و می‌تواند برای جلوگیری از نوسانات شدید مصرف برق در صورت تخصیص هم‌زمان کار به تعداد زیادی از گره‌های در حالت ذخیرهٔ انرژی (مثلاً شروع یک کار بزرگ) استفاده شود. مقدار صفر منجر به عدم اعمال هیچ محدودیتی می‌شود. مقدار پیش‌فرض ۳۰۰ گره در دقیقه است.
حداکثر زمان مجاز (به ثانیه) بین زمان صدور درخواست ازسرگیری گره و زمانی که گره عملاً برای استفاده در دسترس قرار می‌گیرد. گره‌هایی که در این بازهٔ زمانی پاسخ ندهند، به عنوان DOWN علامت‌گذاری شده و در صورت امکان کارهای زمان‌بندی‌شده روی آن گره مجدداً در صف قرار می‌گیرند. گره‌هایی که پس از این بازهٔ زمانی راه‌اندازی مجدد شوند، با دلیل "Node unexpectedly rebooted." به عنوان DOWN علامت‌گذاری خواهند شد. مقدار پیش‌فرض ۶۰ ثانیه است و حداکثر مقدار یا ۶۵۵۳۳ یا INFINITE می‌باشد. همچنین ReturnToService را ببینید.
نام مسیر کامل برنامه‌ای برای اجرای slurmctld هنگام پایان یافتن یک رزرو. این برنامه هنگام حذف یک رزرو در حال اجرا، اجرا نمی‌شود. برنامه می‌تواند برای لغو کارها، اصلاح پیکربندی پارتیشن و غیره استفاده شود. نام رزرو به عنوان یک آرگومان به برنامه ارسال خواهد شد. به‌طور پیش‌فرض هیچ پس‌درآمدی (epilog) وجود ندارد.
مشخص می‌کند که کاری که از قبل در یک رزرو در حال اجرا بوده، پس از رسیدن به زمان پایان رزرو تا چه مدت مجاز به اجرا است. این بازهٔ زمانی بر حسب دقیقه مشخص می‌شود و مقدار پیش‌فرض 0 است (توقف فوری کار). این مقدار نباید از ۶۵۵۳۳ دقیقه بیشتر باشد، هرچند مقدار "UNLIMITED" برای مجاز ساختن اجرای نامحدود کار پس از پایان رزرو آن پشتیبانی می‌شود.
نام مسیر کامل برنامه‌ای برای اجرای slurmctld هنگام شروع یک رزرو. برنامه می‌تواند برای لغو کارها، اصلاح پیکربندی پارتیشن و غیره استفاده شود. نام رزرو به عنوان یک آرگومان به برنامه ارسال خواهد شد. به‌طور پیش‌فرض هیچ پیش‌درآمدی (prolog) وجود ندارد.
کنترل می‌کند که چه زمانی یک گره در وضعیت DOWN به سرویس بازگردانده می‌شود. مقدار پیش‌فرض 0 است. مقادیر پشتیبانی‌شده عبارتند از:
0
یک گره در وضعیت DOWN باقی خواهد ماند تا زمانی که یک مدیر سیستم به‌طور صریح وضعیت آن را تغییر دهد (حتی اگر دیمن slurmd ثبت شود و ارتباطات را از سر بگیرد).
1
یک گره DOWN پس از ثبت‌نام با یک پیکربندی معتبر در دسترس برای استفاده قرار می‌گیرد، تنها در صورتی که به دلیل پاسخگو نبودن در وضعیت DOWN قرار گرفته باشد. اگر گره به هر دلیل دیگری (کمبود حافظه، راه‌اندازی مجدد غیرمنتظره و غیره) روی DOWN تنظیم شده باشد، وضعیت آن به‌طور خودکار تغییر نخواهد کرد. یک گره زمانی با پیکربندی معتبر ثبت می‌شود که حافظه، GRES، تعداد CPU و غیره در آن مساوی یا بیشتر از مقادیر پیکربندی‌شده در slurm.conf باشد.
2
یک گره DOWN پس از ثبت‌نام با یک پیکربندی معتبر در دسترس برای استفاده قرار می‌گیرد. گره می‌توانسته به هر دلیلی روی DOWN تنظیم شده باشد. یک گره زمانی با پیکربندی معتبر ثبت می‌شود که حافظه، GRES، تعداد CPU و غیره در آن مساوی یا بیشتر از مقادیر پیکربندی‌شده در slurm.conf باشد.
تفسیر این پارامتر بسته به SchedulerType متغیر است. گزینه‌های متعدد می‌توانند با کاما از یکدیگر جدا شوند.
در صورت تنظیم، درخواست‌های ثبت کاری که مجوزی بیش از مجوزهای پیکربندی‌شده می‌خواهند، رد نخواهند شد.
در صورت تنظیم و عدم امکان شروع یک کار به دلیل محدودیت‌های انتساب (association limits)، برای شروع کارهای با اولویت پایین‌تر در آن پارتیشن تلاشی صورت نمی‌گیرد. تنظیم این گزینه می‌تواند توان عملیاتی و بهره‌وری سیستم را کاهش دهد، اما با جلوگیری از تأخیر نامحدود در راه‌اندازی کارهای بزرگ‌تر، از گرسنگی احتمالی آن‌ها جلوگیری می‌کند.
این می‌تواند در یک محیط با توان عملیاتی بالا که در آن کارهای دسته‌ای با نرخ بسیار بالایی ثبت می‌شوند (یعنی با استفاده از دستور sbatch) و شخص مایل به کاهش سربار ناشی از تلاش برای زمان‌بندی هر کار در زمان ثبت است، مفید باشد. مقدار پیش‌فرض ۳ ثانیه است.
مقدار پیش‌فرض 10 است.
به‌طور پیش‌فرض، زمان‌بند پس‌پرکننده (backfill) هنگامی که یک کار تلاش می‌کند از یک رزرو مغناطیسی استفاده کند، شکافی در طرح bf اضافه نمی‌کند. این گزینه این رفتار را معکوس می‌کند تا زمان‌بند backfill هنگام واجد شرایط بودن کارها برای اجرا در یک رزرو مغناطیسی، شکاف‌هایی را در طرح bf اضافه نماید. با فعال بودن این گزینه، کارهای درون رزروهای مغناطیسی اولویت‌ها را رعایت کرده و همچنین در محدودیت‌های backfill مانند bf_max_job_test شمرده می‌شوند. NOTE: زمان‌بند پس‌پرکننده ابتدا کارهای درون رزروها را ارزیابی می‌کند، بدین معنا که تمام کارهای مغناطیسی ابتدا آزمایش خواهند شد. هنگام فعال کردن این گزینه، حتماً محدودیت‌های پیکربندی‌شدهٔ backfill را بازبینی (و در صورت لزوم افزایش) دهید تا مطمئن شوید چرخهٔ backfill به آزمایش کارهای مورد انتظار در صف می‌رسد. NOTE: اگر bf_one_resv_per_job همراه با این گزینه استفاده شود، شکاف رزرو مغناطیسی تنها شکاف در طرح bf خواهد بود. در غیر این صورت، این شکاف نخستین شکاف خارج از رزرو مغناطیسی خواهد بود.
هنگام انتخاب منابع برای کارهای معلق جهت رزرو برای اجرای آینده (یعنی زمانی که کار نمی‌تواند فوراً شروع شود)، ترجیحاً گره‌هایی که در حال استفاده هستند انتخاب شوند. این تمایل ایجاد می‌کند که منابع فعلی بیکار برای پس‌پرکردن کارهای با مدت اجرای طولانی‌تر در دسترس باقی بمانند، اما ممکن است منجر به تخصیص‌هایی با توپولوژی شبکه کمتر از حد بهینه شود. این گزینه در حال حاضر تنها توسط افزونهٔ select/cons_tres پشتیبانی می‌شود.
زمان‌بند پس‌پرکننده به‌طور دوره‌ای قفل‌ها را آزاد می‌کند تا به جای مسدود کردن تمام فعالیت‌ها برای مدتی طولانی، به سایر عملیات‌ها اجازهٔ پیشرفت دهد. تنظیم این گزینه باعث می‌شود زمان‌بند backfill پس از آزادسازی قفل‌ها، پردازش کارهای معلق را از فهرست اصلی کارها ادامه دهد، حتی اگر وضعیت کار یا گره تغییر کرده باشد.
به زمان‌بند پس‌پرکننده دستور می‌دهد تا به محض اینکه مشخص شد تمام اجزای یک کار ناهمگن قادر به شروع هستند، برای شروع آن تلاش کند. در غیر این صورت، زمان‌بند backfill تلاش‌های شروع کارهای ناهمگن را تا پس از پردازش بقیهٔ صف به تعویق می‌اندازد. این تأخیر ممکن است منجر به تخصیص منابع به کارهای با اولویت پایین‌تر شود، که خود می‌تواند به دلیل رسیدن به محدودیت‌های حساب کاربری و/یا QOS، شروع کار ناهمگن را به تأخیر بیندازد. این گزینه به‌طور پیش‌فرض غیرفعال است. اگر فعال شود و bf_hetjob_prio=min تنظیم نشده باشد، به‌طور خودکار تنظیم خواهد شد.
در ابتدای هر چرخهٔ زمان‌بندی پس‌پرکننده (backfill)، فهرستی از کارهای معلق برای زمان‌بندی بر اساس ترتیب اولویت پیکربندی‌شده در PriorityType مرتب می‌شود. این گزینه به زمان‌بند دستور می‌دهد تا الگوریتم مرتب‌سازی را تغییر دهد تا اطمینان حاصل شود که برای زمان‌بندی تمام مؤلفه‌های متعلق به یک کار ناهمگن، به‌صورت متوالی تلاش خواهد شد (بنابراین در فهرست حاصل پراکنده نمی‌شوند). به‌طور مشخص‌تر، با تمام مؤلفه‌های یک کار ناهمگن هنگام مقایسه با سایر کارها (یا مؤلفه‌های سایر کارهای ناهمگن)، طوری رفتار خواهد شد که گویی همگی دارای اولویت یکسانی هستند (حداقل، میانگین یا حداکثر بسته به پارامتر این گزینه). ترتیب اولیه در درون همان کار ناهمگن حفظ خواهد شد. توجه داشته باشید که این عملیات برای لایهٔ PriorityTier و برای Priority حاصل از محاسبات افزونهٔ priority/multifactor محاسبه می‌شود. در صورت فعال بودن، اگر هر کار ناهمگنی درخواست یک رزرو پیشرفته (advanced reservation) کرده باشد، با تمام مؤلفه‌های آن کار به گونه‌ای رفتار خواهد شد که گویی درخواست رزرو پیشرفته داشته‌اند (و در زمان‌بندی رفتار ترجیحی دریافت می‌کنند).

توجه داشته باشید که این عملیات مقادیر Priority مؤلفه‌های کار ناهمگن را به‌روزرسانی نمی‌کند، بلکه تنها ترتیب آن‌ها را در فهرست تغییر می‌دهد؛ بنابراین خروجی دستور sprio تحت تأثیر قرار نخواهد گرفت.

کارهای ناهمگن دارای ویژگی‌های زمان‌بندی خاصی هستند: آن‌ها تنها توسط افزونهٔ زمان‌بندی backfill زمان‌بندی می‌شوند، هر یک از مؤلفه‌های آن‌ها هنگام رزرو منابع به‌طور جداگانه در نظر گرفته می‌شود (و ممکن است مقادیر PriorityTier یا Priority متفاوتی داشته باشند)، و عملاً به هیچ مؤلفهٔ کار ناهمگنی منبع تخصیص داده نمی‌شود مگر اینکه تمام مؤلفه‌های آن بتوانند راه‌اندازی شوند. این امر می‌تواند سناریوهای بن‌بست احتمالی زمان‌بندی ایجاد کند زیرا مؤلفه‌های کارهای ناهمگن مختلف می‌توانند به صورت متناوب (نه متوالی) شروع به رزرو منابع کنند، اما هیچ‌یک از کارها نتوانند منابع را برای همهٔ مؤلفه‌ها رزرو کرده و شروع شوند. فعال کردن این گزینه می‌تواند به کاهش این مشکل کمک کند. به‌طور پیش‌فرض، این گزینه غیرفعال است.

مقادیر بالاتر منجر به سربار کمتر و پاسخگویی بهتر می‌شود. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. پیش‌فرض: 30، حداقل: 1، حداکثر: 10800 (۳ ساعت). تنظیم مقدار -1 حلقهٔ زمان‌بندی backfill را غیرفعال می‌کند.
به عنوان مثال، bf_job_part_count_reserve=10 باعث می‌شود زمان‌بند backfill منابع را برای ۱۰ کار با بالاترین اولویت در هر پارتیشن رزرو کند. هر کار با اولویت پایین‌تر که بتواند با استفاده از منابع موجود فعلی شروع شود و تأثیر منفی بر زمان شروع مورد انتظار این کارهای با اولویت بالاتر نگذارد، توسط زمان‌بند backfill شروع خواهد شد. مقدار پیش‌فرض صفر است که منابع را برای هر کار معلق رزرو می‌کند و شروع کارهای با اولویت پایین‌تر را به تأخیر می‌اندازد. همچنین bf_min_age_reserve و bf_min_prio_reserve را ببینید. پیش‌فرض: 0، حداقل: 0، حداکثر: 100000.
منطق زمان‌بندی پس‌پرکننده را ملزم به ردیابی و برنامه‌ریزی برای در دسترس بودن مجوزها (license) می‌کند. به‌طور پیش‌فرض، برای هر کاری که به دلیل در دسترس نبودن مجوز مسدود شده باشد منبعی رزرو نمی‌شود که این امر می‌تواند منجر به گرسنگی کار شود. این گزینه به‌طور ضمنی bf_running_job_reserve را فعال می‌کند.
از آنجا که آرایه‌های کاری می‌توانند به صورت بالقوه میلیون‌ها تسک داشته باشند، سربار رزرو منابع برای همهٔ تسک‌ها می‌تواند بسیار سنگین باشد. علاوه بر این، محدودیت‌های مختلف ممکن است مانع از شروع همهٔ کارها در زمان‌های مورد انتظار شود. این گزینه هیچ تأثیری بر تعداد تسک‌های یک آرایه کاری که می‌توانند فوراً شروع شوند ندارد، بلکه فقط بر تسک‌هایی تأثیر می‌گذارد که انتظار می‌رود در زمانی در آینده شروع شوند. پیش‌فرض: 20، حداقل: 0، حداکثر: 1000. NOTE: کارهای ثبت‌شده در چندین پارتیشن، به ازای هر پارتیشن یک بار در صف کار ظاهر می‌شوند. اگر نسخه‌های مختلف یک رکورد آرایه کاری در صف کار متوالی نباشند و رکورد آرایه کاری دیگری بین آن‌ها قرار گیرد، آن‌گاه به ازای هر پارتیشنی که کار در آن ثبت شده است، bf_max_job_array_resv تسک در نظر گرفته می‌شود.
این تنظیم مشابه bf_max_job_user است اما در صورتی که یک کاربر دارای چندین انتساب باشد که اساساً معادل کاربران متفاوتی هستند، کاربردی است. می‌توان این محدودیت را تنظیم کرد تا از پر شدن صف backfill توسط کاربران با کارهایی که نمی‌توانند شروع شوند و مانع از شروع کارهای سایر کاربران می‌شوند، جلوگیری کرد. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. همچنین گزینه‌های bf_max_job_user، bf_max_job_part، bf_max_job_test و bf_max_job_user_part را ببینید. مقدار bf_max_job_test را روی مقداری بسیار بالاتر از bf_max_job_assoc تنظیم کنید. پیش‌فرض: 0 (بدون محدودیت)، حداقل: 0، حداکثر: bf_max_job_test.
این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. همچنین گزینه‌های partition_job_depth و bf_max_job_test را ببینید. مقدار bf_max_job_test را روی مقداری بسیار بالاتر از bf_max_job_part تنظیم کنید. پیش‌فرض: 0 (بدون محدودیت)، حداقل: 0، حداکثر: bf_max_job_test.
این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. پیش‌فرض: 0 (بدون محدودیت)، حداقل: 0، حداکثر: 10000.
مقادیر بالاتر منجر به سربار بیشتر و پاسخگویی کمتر می‌شود. تا زمانی که تلاشی برای زمان‌بندی backfill یک کار صورت نگیرد، مقدار زمان راه‌اندازی مورد انتظار آن تنظیم نخواهد شد. در مورد خوشه‌های بزرگ، پیکربندی یک مقدار نسبتاً کوچک ممکن است مطلوب باشد. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. پیش‌فرض: 500، حداقل: 1، حداکثر: 1,000,000.
می‌توان این محدودیت را تنظیم کرد تا از پر شدن صف backfill توسط کاربران با کارهایی که نمی‌توانند شروع شوند و مانع از شروع کارهای سایر کاربران می‌شوند، جلوگیری کرد. این شبیه به محدودیت MAXIJOB در Maui است. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. همچنین گزینه‌های bf_max_job_part، bf_max_job_test و bf_max_job_user_part را ببینید. مقدار bf_max_job_test را روی مقداری بسیار بالاتر از bf_max_job_user تنظیم کنید. پیش‌فرض: 0 (بدون محدودیت)، حداقل: 0، حداکثر: bf_max_job_test.
این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. همچنین گزینه‌های bf_max_job_part، bf_max_job_test و bf_max_job_user را ببینید. پیش‌فرض: 0 (بدون محدودیت)، حداقل: 0، حداکثر: bf_max_job_test.
این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. مقدار پیش‌فرض، مقدار bf_interval است (که پیش‌فرض آن ۳۰ ثانیه است). پیش‌فرض: مقدار bf_interval (پیش‌فرض ۳۰ ثانیه)، حداقل: 1، حداکثر: 3600 (۱ ساعت). NOTE: اگر bf_interval کوتاه و bf_max_time بزرگ باشد، ممکن است باعث شود قفل‌ها مکرراً اخذ شوند و سایر RPCهای تحت سرویس دچار گرسنگی شوند. در صورت استفاده از این پارامتر، توصیه می‌شود max_rpc_cnt به اندازهٔ کافی بالا تنظیم شود تا زمان‌بندی همیشه غیرفعال نشود، و به اندازهٔ کافی پایین باشد تا بار کاری تعاملی بتواند در یک بازهٔ زمانی معقول پردازش شود. مقدار max_rpc_cnt باید کمتر از ۲۵۶ (محدودیت پیش‌فرض نخ‌های RPC) باشد. مقداری در حدود میانه (۱۵۰) ممکن است نتایج خوبی به شما بدهد. NOTE: هنگام افزایش مدت‌زمان صرف‌شده در چرخهٔ زمان‌بندی backfill، ممکن است Slurm از پاسخگویی به‌موقع به درخواست‌های کلاینت باز بماند. برای رفع این مشکل می‌توانید از max_rpc_cnt برای مشخص کردن تعداد RPCهای در صف پیش از توقف زمان‌بند جهت پاسخگویی به این درخواست‌ها استفاده کنید.
علاوه بر این، کارهایی که کمتر از تعداد ثانیه‌های مشخص‌شده منتظر مانده‌اند، مانع از شروع فوری یک کار تازه ثبت‌شده نخواهند شد، حتی اگر کار تازه ثبت‌شده اولویت پایین‌تری داشته باشد. این می‌تواند در صورتی که کارها فاقد محدودیت زمانی باشند یا تمام محدودیت‌های زمانی مقدار یکسانی داشته باشند، ارزشمند باشد. مقدار پیش‌فرض صفر است که برای هر کار معلق منابع را رزرو می‌کند و شروع کارهای با اولویت پایین‌تر را به تأخیر می‌اندازد. همچنین bf_job_part_count_reserve و bf_min_prio_reserve را ببینید. پیش‌فرض: 0، حداقل: 0، حداکثر: 2592000 (۳۰ روز).
علاوه بر این، کارهای با اولویت پایین‌تر مانع از شروع فوری یک کار تازه ثبت‌شده نخواهند شد، حتی اگر کار تازه ثبت‌شده اولویت پایین‌تری داشته باشد. این می‌تواند در صورتی که شخص بخواهد بهره‌وری سیستم را بدون توجه به اولویت کارهای زیر یک آستانهٔ مشخص به حداکثر برساند، ارزشمند باشد. مقدار پیش‌فرض صفر است که برای هر کار معلق منابع را رزرو می‌کند و شروع کارهای با اولویت پایین‌تر را به تأخیر می‌اندازد. همچنین bf_job_part_count_reserve و bf_min_age_reserve را ببینید. پیش‌فرض: 0، حداقل: 0، حداکثر: 2^63.
در مورد خوشه‌های بزرگ، پیکربندی یک مقدار نسبتاً کوچک ممکن است مطلوب باشد. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. همچنین bf_max_job_test و bf_running_job_reserve را ببینید. پیش‌فرض: bf_max_job_test، حداقل: 2، حداکثر: 2,000,000.
عدم اجازهٔ افزودن بیش از یک رزرو پس‌پرکننده به ازای هر کار. منطق زمان‌بندی یک فهرست مرتب‌شده از جفت‌های کار-پارتیشن ایجاد می‌کند. کارهای ثبت‌شده در چندین پارتیشن به تعداد پارتیشن‌های درخواستی، مدخل در فهرست دارند. به‌طور پیش‌فرض، زمان‌بند backfill ممکن است تمام مدخل‌های کار-پارتیشن یک کار را ارزیابی کند و بالقوه برای هر جفت منابع رزرو کند، اما کار را تنها در رزروی شروع کند که زودترین زمان شروع را ارائه می‌دهد. رزرو منابع برای چندین پارتیشن توسط یک کار واحد می‌تواند مانع از رزرو منابعی توسط سایر کارها (یا مؤلفه‌های hetjob) شود که قبلاً برای پارتیشن‌هایی رزرو شده‌اند که زودترین زمان شروع را ارائه نمی‌دهند. یک کار واحد که درخواست چندین پارتیشن می‌کند همچنین می‌تواند در صورتی که پارتیشن‌ها هم‌پوشانی گره داشته باشند و رزرو backfill در پارتیشن با اولویت بالاتر گره‌هایی را مسدود کند که در پارتیشن با اولویت پایین‌تر نیز هستند، مانع از شروع زودتر خود در پارتیشن با اولویت پایین‌تر شود. این گزینه باعث می‌شود که کاری که در چندین پارتیشن ثبت شده است، به محض اینکه اولین جفت کار-پارتیشن یک رزرو backfill ثبت کرد، رزرو منابع را متوقف کند. جفت‌های بعدی از همان کار تنها برای شروع در لحظه آزمایش خواهند شد. این امر به سایر کارها اجازه می‌دهد تا بتوانند منابع سایر جفت‌ها را رزرو کنند، به بهای عدم تضمین اینکه کار چندپارتیشنی در پارتیشنی که زودترین زمان شروع را ارائه می‌دهد شروع شود (مگر اینکه بتواند فوراً شروع شود). این گزینه به‌طور پیش‌فرض غیرفعال است.
با این حال، مقادیر بالاتر منجر به برنامه‌ریزی سیستمی با کارایی کمتر می‌شود و ممکن است فرصت‌های بهبود بهره‌وری سیستم را از دست بدهد. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. پیش‌فرض: 60، حداقل: 1، حداکثر: 3600 (۱ ساعت).
افزودن یک مرحلهٔ اضافی به منطق پس‌پرکننده که رزروهای backfill را برای کارهایی که روی کل گره‌ها در حال اجرا هستند ایجاد می‌کند. این گزینه به‌طور پیش‌فرض غیرفعال است.
فعال‌سازی قلاب آزمایشی برای کنترل این موضوع که آیا کارها در backfill برای جای‌گذاری بهتر به تأخیر بیفتند یا خیر. برای آزمایش، src/plugins/sched/backfill/oracle.c را تغییر دهید.

توصیه می‌شود زمان‌بند اصلی را غیرفعال کنید تا همهٔ کارها از طریق backfill برنامه‌ریزی شوند و از تابع ()oracle استفاده کنند. این کار می‌تواند با تنظیم SchedulerParameters=sched_interval=-1 انجام شود.

همچنین توصیه می‌شود برای برنامه‌ریزی بهتر با SchedulerParameters=bf_running_job_reserve اجرا شود.

تعداد شکاف‌های متوالی نقشهٔ backfill که یک کار ممکن است به تأخیر بیفتد. این گزینه تنها زمانی اعمال می‌شود که bf_topopt_enable تنظیم شده باشد.
مقادیر بالاتر منجر به سربار بیشتر و پاسخگویی کمتر می‌شود. مقداری حداقل به اندازهٔ بیشترین محدودیت زمانی مجاز به‌طور کلی برای جلوگیری از گرسنگی کارها توصیه می‌شود. به منظور محدود کردن حجم داده‌های مدیریت‌شده توسط زمان‌بند پس‌پرکننده، در صورت افزایش مقدار bf_window، معمولاً توصیه می‌شود bf_resolution نیز افزایش یابد. این گزینه فقط برای SchedulerType=sched/backfill اعمال می‌شود. پیش‌فرض: 1440 (۱ روز)، حداقل: 1، حداکثر: 43200 (۳۰ روز).
این مقدار بر حسب واحد ثانیه مشخص می‌شود. به عنوان مثال، مقدار 60 باعث می‌شود که زمان‌بند پس‌پرکننده در اولین تکرار، کاری را که زودتر از همه به پایان می‌رسد شناسایی کرده و مشخص کند آیا کار معلق می‌تواند پس از آن کار به علاوهٔ تمام کارهای دیگری که انتظار می‌رود ظرف ۳۰ ثانیه (مقدار اولیهٔ پیش‌فرض) از کار اول به پایان برسند، شروع شود یا خیر. در تکرار بعدی، کار معلق برای شروع پس از کار بعدی که انتظار می‌رود به پایان برسد به علاوهٔ تمام کارهایی که ظرف ۹۰ ثانیه از آن زمان به پایان می‌رسند (۳۰ ثانیه پیش‌فرض به علاوهٔ مقدار ۶۰ ثانیه‌ای گزینه) ارزیابی خواهد شد. تکرار سوم یک پنجرهٔ ۱۵۰ ثانیه‌ای و تکرار چهارم ۲۱۰ ثانیه خواهد داشت. بدون این گزینه، پنجره‌های زمانی در هر تکرار دو برابر می‌شوند و بنابراین ۳۰، ۶۰، ۱۲۰، ۲۴۰ ثانیه و غیره خواهند بود. استفاده از bf_window_linear با بیش از چند صد کار در حال اجرای هم‌زمان توصیه نمی‌شود.
این گزینه زمان‌هایی را که قفل‌ها واگذار می‌شوند به میکروثانیه مشخص می‌کند. مقادیر کوچک‌تر در صورت استفاده همراه با گزینهٔ bf_continue ممکن است برای رایانش با توان عملیاتی بالا مفید باشند. همچنین گزینهٔ bf_yield_sleep را ببینید. پیش‌فرض: 2,000,000 (۲ ثانیه)، حداقل: 1، حداکثر: 10,000,000 (۱۰ ثانیه).
اگر تعداد نخ‌های فعال در دیمن slurmctld کمتر از این مقدار باشد، زمان‌بندی کارها ادامه می‌یابد. زمان‌بند این شرط را در نقاط خاصی از کد بررسی می‌کند و در صورت لزوم قفل‌های قبلاً واگذارشده را آزاد می‌نماید. این گزینه برای تعیین این مورد استفاده می‌شود که چه زمانی Slurm پردازش درخواست‌ها را متوقف کرده و زمان‌بندی کارهای جدید را آغاز کند، که عکس عمل max_rpc_cnt است. همراه با max_rpc_cnt، این گزینه می‌تواند پاسخگویی Slurm را در برابر جهش‌های ناگهانی درخواست‌ها بهبود بخشد. پیش‌فرض: MAX((max_rpc_cnt / 10), 20) (گزینه غیرفعال است)، حداقل: 0، حداکثر: 200.
NOTE: اگر مقداری تنظیم شود، مقداری کمتر از max_rpc_cnt توصیه می‌شود. ممکن است نیاز به مقداری تنظیم برای هر سیستم داشته باشد، اما باید به اندازهٔ کافی بالا باشد که زمان‌بندی همیشه غیرفعال نشود، و به اندازهٔ کافی پایین باشد که درخواست‌ها بتوانند در یک بازهٔ زمانی معقول عبور کنند. از نزدیک بودن بیش از حد هر دو مقدار که باعث سوئیچ مداوم بین پردازش درخواست و زمان‌بندی می‌شود خودداری کنید.
این گزینه مدت زمانی را که قفل‌ها واگذار می‌شوند به میکروثانیه مشخص می‌کند. همچنین گزینهٔ bf_yield_interval را ببینید. پیش‌فرض: 500,000 (۰٫۵ ثانیه)، حداقل: 1، حداکثر: 10,000,000 (۱۰ ثانیه).
اگر سیستم تعداد بسیار زیادی کار دارای وابستگی داشته باشد، صرفاً ساخت صف کارها می‌تواند آن‌قدر زمان ببرد که تأثیر منفی بر عملکرد کلی سیستم بگذارد و این پارامتر را می‌توان بر اساس نیاز تنظیم کرد. مقدار پیش‌فرض 2,000,000 میکروثانیه (۲ ثانیه) است.
پیش‌فرض: 10.
حلقهٔ زمان‌بندی اصلی با بسامد کمتری طبق تعریف گزینهٔ sched_interval که در ادامه توضیح داده شده است (با نادیده گرفتن این محدودیت) اجرا خواهد شد. مقدار پیش‌فرض 100 است. برای محدود کردن عمق بر اساس پارتیشن، گزینهٔ partition_job_depth را ببینید.
تنظیم این گزینه از تلاش برای زمان‌بندی تک‌تک کارها در زمان ثبت کار خودداری می‌کند و آن را به زمان دیگری که ممکن است زمان‌بندی هم‌زمان چندین کار امکان‌پذیر باشد، موکول می‌نماید. این گزینه در صورتی که تعداد زیادی کار (چندین صد کار) به طور هم‌زمان ثبت شوند ممکن است پاسخگویی سیستم را بهبود بخشد، اما زمان شروع کارهای تکی را به تأخیر می‌اندازد. همچنین default_queue_depth را در بالا ببینید.
مشابه defer، اما تنها زمان‌بندی کارهای دسته‌ای را به تعویق می‌اندازد. تخصیص‌های تعاملی از salloc/srun همچنان بلافاصله پس از ثبت، برای زمان‌بندی تلاش خواهند کرد.
اگر کار کمتر از بازهٔ مشخص‌شده منتظر مانده باشد، تنها از گره‌هایی استفاده خواهد کرد که از قبل ویژگی‌های مشخص‌شده را دارا هستند. آرگومان بر حسب دقیقه است. کارهای تکی می‌توانند این مقدار پیش‌فرض را با گزینهٔ --delay-boot بازنویسی کنند.
رد درخواست‌های کاربر برای کاهش اندازهٔ کارهای در حال اجرا. (با این حال، کارهای در حال اجرا در صورت تنظیم گزینهٔ --no-kill همچنان ممکن است به دلیل خرابی گره کاهش یابند.)
غیرفعال‌سازی گام‌های کاری که تخصیص‌های کارهای ناهمگن را در بر می‌گیرند.
فعال‌سازی گام‌های کاری که تخصیص‌های کارهای ناهمگن را در بر می‌گیرند. مقدار پیش‌فرض است.
فعال‌سازی استفاده از دستور «scontrol top» توسط کاربران غیرممتاز.
فعال‌سازی پالایش گره با گزینهٔ --extra برای salloc، sbatch و srun و فیلد Extra گره.
در صورت تنظیم، و در صورتی که کاری --constraint درخواست کند، هر ویژگی در درخواست که درخواستی نامعتبر در سیستم فعلی ایجاد کند خطایی تولید نخواهد کرد. این امر برای سیستم‌های پویایی که در آن‌ها گره‌های دارای ویژگی‌ها می‌آیند و می‌روند مفید است. کارها در صف کار باقی خواهند ماند تا زمانی که ویژگی درخواستی در خوشه و در دسترس باشد. لطفاً توجه داشته باشید که استفاده از این گزینه از شما در برابر اشتباهات تایپی محافظت نخواهد کرد. همچنین ignore_prefer_validation را ببینید.
برخی از پردازنده‌ها (مانند سری AMD Opteron 6000) شامل چندین گره NUMA در هر سوکت هستند. این پیکربندی با موجودیت‌های سخت‌افزاری که Slurm تخصیص منابع را برای آن‌ها بهینه‌سازی می‌کند (PU/نخ، هسته، سوکت، بیس‌بورد، گره و سوئیچ شبکه) نگاشت نمی‌شود. به منظور بهینه‌سازی تخصیص منابع روی چنین سخت‌افزاری، Slurm به‌طور پیش‌فرض هر گره NUMA در داخل سوکت را به عنوان یک سوکت جداگانه در نظر می‌گیرد. از گزینهٔ Ignore_NUMA برای گزارش تعداد صحیح سوکت‌ها استفاده کنید، اما تخصیص منابع را روی گره‌های NUMA بهینه‌سازی نکنید.

NOTE: از نسخهٔ hwloc 2.0 به بعد گره‌های NUMA بخشی از درخت توپولوژی اصلی/CPU نیستند، به همین دلیل اگر Slurm با hwloc 2.0 یا بالاتر ساخته شده باشد، Slurm با HWLOC_OBJ_PACKAGE مانند Socket رفتار خواهد کرد؛ می‌توانید این رفتار را با استفاده از SlurmdParameters=l3cache_as_socket تغییر دهید.

در صورت تنظیم، و در صورتی که کاری --prefer درخواست کند، هر ویژگی در درخواست که درخواستی نامعتبر در سیستم فعلی ایجاد کند خطایی تولید نخواهد کرد. این امر برای سیستم‌های پویایی که در آن‌ها گره‌های دارای ویژگی‌ها می‌آیند و می‌روند مفید است. لطفاً توجه داشته باشید که استفاده از این گزینه از شما در برابر اشتباهات تایپی محافظت نخواهد کرد. همچنین ignore_constraint_validation را ببینید.
حداکثر تعداد تسک‌هایی را که می‌توانند در یک آرایه کاری گنجانده شوند مشخص می‌کند. حد پیش‌فرض MaxArraySize است، اما این گزینه می‌تواند برای تنظیم یک حد پایین‌تر استفاده شود. به عنوان مثال، max_array_tasks=1000 و MaxArraySize=100001 حداکثر شناسهٔ تسک 100000 را مجاز می‌داند، اما تعداد تسک‌ها در هر آرایه کاری واحد را به 1000 محدود می‌کند.
این امر می‌تواند توانایی Slurm را در پردازش درخواست‌ها بهبود بخشد، به قیمت راه‌اندازی کارهای جدید با بسامد کمتر. پیش‌فرض: 0 (گزینه غیرفعال است)، حداقل: 0، حداکثر: 1000.
NOTE: حداکثر تعداد نخ‌ها (MAX_SERVER_THREADS) در داخل برنامه روی ۲۵۶ تنظیم شده است و تعداد RPCهای تحت سرویس را در یک زمان مشخص تعریف می‌کند. تنظیم max_rpc_cnt روی بیش از ۲۵۶ تنها برای این مفید خواهد بود که به backfill اجازه دهد پس از واگذاری قفل‌ها (یعنی هر ۲ ثانیه یک‌بار) در صورتی که حداکثر MAX(max_rpc_cnt/10, 20) RPC در صف وجود داشته باشد، به کار زمان‌بندی ادامه دهد؛ یعنی با max_rpc_cnt=1000، زمان‌بند تنها زمانی مجاز به ادامه پس از واگذاری قفل‌ها خواهد بود که ۱۰۰ یا کمتر RPC معلق وجود داشته باشد. اگر مقداری تنظیم شده باشد، مقدار ۱۰ یا بالاتر توصیه می‌شود. ممکن است برای هر سیستم به مقداری تنظیم نیاز داشته باشد، اما باید به اندازهٔ کافی بالا باشد که زمان‌بندی همیشه غیرفعال نشود، و به اندازهٔ کافی پایین باشد که درخواست‌ها بتوانند در یک بازهٔ زمانی معقول پردازش شوند.
توجه داشته باشید که تمام عملیات‌های دیگر Slurm، از جمله پاسخ به RPCها، در حین اجرای حلقهٔ زمان‌بندی به تعویق خواهند افتاد.

در بیشتر موارد به‌طور پیش‌فرض ۲ ثانیه است، یا اگر MessageTimeout روی ۳ یا کمتر تنظیم شده باشد، ۱ ثانیه است. حداکثر مقدار نصف MessageTimeout است. مقادیر بزرگ‌تر با مقدار پیش‌فرض قابل اعمال جایگزین خواهند شد.

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

مقدار پیش‌فرض ۴ مگابایت است. مقادیر بزرگ‌تر ممکن است تأثیر منفی بر عملکرد سیستم بگذارند.
مقدار پیش‌فرض ۱ مگابایت است. این گزینه نمی‌تواند از ۲ مگابایت بیشتر باشد.
در صورت استفاده، کنترل‌کنندهٔ پشتیبان هنگام به دست گرفتن کنترل، کارها را زمان‌بندی نخواهد کرد. کنترل‌کنندهٔ پشتیبان اجازهٔ ثبت، اصلاح و لغو کارها را می‌دهد اما کارهای جدید را زمان‌بندی نخواهد کرد. این مورد در محیط‌های Cray زمانی که کنترل‌کنندهٔ پشتیبان روی یک گره خارجی Cray قرار دارد مفید است.
به‌طور پیش‌فرض، اگر Prolog با یک مقدار غیرصفر خارج شود، کار در وضعیت نگه‌داشته (held) مجدداً در صف قرار می‌گیرد. با مشخص کردن این پارامتر، کار مجدداً در صف قرار می‌گیرد اما نگه داشته نمی‌شود تا زمان‌بند بتواند آن را به میزبان دیگری اعزام کند.
در صورت استفاده با افزونهٔ select/cons_tres، کارهای سریالی را به جای استفاده از الگوریتم بهترین برازش، در انتهای گره‌های موجود قرار می‌دهد. این ممکن است برای برخی از بارهای کاری، تکه‌تکه‌شدن منابع را کاهش دهد.
این محدودیت برای تمام چرخه‌های زمان‌بند اصلی اعمال خواهد شد. عملکرد آن مشابه عملکرد ارائه‌شده توسط گزینهٔ bf_max_job_part برای منطق زمان‌بندی پس‌پرکننده است. مقدار پیش‌فرض 0 (بدون محدودیت) است. کارهایی که بر اساس پارتیشن از تلاش برای زمان‌بندی کنار گذاشته می‌شوند، در محدودیت default_queue_depth شمرده نخواهند شد. همچنین گزینهٔ bf_max_job_part را ببینید.
این گزینه برای کنترل نحوهٔ انجام زمان‌بندی منابع زمانی که کارها در وضعیت COMPLETING هستند استفاده می‌شود، که بر تکه‌تکه‌شدگی بالقوه اثر می‌گذارد. اگر این گزینه تنظیم نشده باشد، زمانی که هر کاری برای کمتر از CompleteWait ثانیه در وضعیت COMPLETING باشد، هیچ کاری در هیچ پارتیشنی شروع نخواهد شد. اگر این گزینه تنظیم شده باشد، در هر پارتیشن خاصی که کاری در وضعیت COMPLETING برای کمتر از CompleteWait ثانیه دارد، هیچ کاری شروع نخواهد شد. علاوه بر این، در هیچ پارتیشنی با گره‌هایی که با هر یک از گره‌های موجود در پارتیشن کار در حال اتمام هم‌پوشانی دارند، کاری شروع نخواهد شد. این گزینه باید همراه با CompleteWait استفاده شود.

NOTE: برای کارکرد این گزینه، CompleteWait باید تنظیم شده باشد. اگر CompleteWait=0 باشد، این گزینه هیچ کاری انجام نمی‌دهد.

NOTE: reduce_completing_frag فقط بر زمان‌بند اصلی اثر می‌گذارد، نه زمان‌بند پس‌پرکننده.

تأخیر قبل از واجد شرایط شدن یک کار صف‌بندی‌مجدد غیرفوری برای اجرا پس از قرار گرفتن مجدد در صف. به‌طور پیش‌فرض برابر با تنظیم AuthInfo=cred_expire است که خود به‌طور پیش‌فرض ۱۲۰ ثانیه می‌باشد.
در صورتی که گره‌ها تا موعد ResumeTimeout موفق به ازسرگیری نشوند، تمام کارهای دسته‌ای مجدداً در صف قرار می‌گیرند -- حتی اگر کارها درخواست کرده باشند که در صف مجدد قرار نگیرند. این شبیه به PrologFlags=ForceRequeueOnFail است.
در صورت تعریف، دستور salloc تا زمانی که تمام گره‌های تخصیص‌یافته آمادهٔ استفاده (یعنی بوت‌شده) باشند قبل از بازگشت دستور منتظر خواهد ماند. به‌طور پیش‌فرض، salloc به محض انجام تخصیص منابع بازمی‌گردد. دستور salloc می‌تواند از گزینهٔ --wait-all-nodes برای بازنویسی این پارامتر پیکربندی استفاده کند.
در صورت تعریف، اسکریپت sbatch تا زمانی که تمام گره‌های تخصیص‌یافته آمادهٔ استفاده (یعنی بوت‌شده) باشند قبل از شروع منتظر می‌ماند. به‌طور پیش‌فرض، اسکریپت sbatch به محض آماده شدن اولین گره در تخصیص کار آغاز می‌شود. دستور sbatch می‌تواند از گزینهٔ --wait-all-nodes برای بازنویسی این پارامتر پیکربندی استفاده کند.
مقدار پیش‌فرض ۶۰ ثانیه است. تنظیم مقدار -1 حلقهٔ زمان‌بندی اصلی را غیرفعال می‌کند.
مقدار پیش‌فرض صفر است که هیچ محدودیتی اعمال نمی‌کند.
زمان‌بند با وقوع هر رویدادی که بتواند شروع یک کار را ممکن سازد (مانند ثبت کار، خاتمهٔ کار و غیره)، به صورت محدود اجرا می‌شود. اگر این رویدادها با بسامد بالایی رخ دهند، زمان‌بند ممکن است بسیار مکرر اجرا شود و اگر توسط این گزینه مهار نشود، منابع قابل توجهی مصرف کند. این گزینه حداقل زمان بین پایان یک چرخهٔ زمان‌بندی و شروع چرخهٔ زمان‌بندی بعدی را مشخص می‌کند. مقدار صفر مهار بازهٔ منطق زمان‌بندی را غیرفعال می‌کند. مقدار پیش‌فرض ۲ میکروثانیه است.
هسته‌های تخصصی از هسته‌های نخستینِ سوکت‌های نخستین انتخاب خواهند شد و به صورت نوبت‌گردشی بین سوکت‌ها پیمایش انجام می‌شود. به‌طور پیش‌فرض، هسته‌های تخصصی از آخرین هسته‌های آخرین سوکت‌ها انتخاب می‌شوند و به صورت نوبت‌گردشی بین سوکت‌ها پیمایش انجام می‌شود.
همچنین step_retry_time را ببینید. مقدار پیش‌فرض ۸ گام است.
همچنین step_retry_count را ببینید. مقدار پیش‌فرض ۶۰ ثانیه است.
محدودیت --time-min را به عنوان یک محدودیت زمانی نرم برای کار در نظر می‌گیرد. زمان‌بندی برای مدت‌زمان کوتاه‌تر برنامه‌ریزی می‌کند، در حالی که به کار اجازه می‌دهد تا زمان رسیدن به محدودیت زمانی («سخت») --time به اجرای خود ادامه دهد.
درخواست‌های لغو، نگه‌داشتن یا آزادسازی هر یک از مؤلفه‌های یک کار ناهمگن روی تمام مؤلفه‌های آن کار اعمال خواهد شد.

NOTE: این گزینه پیش‌تر whole_pack نامیده می‌شد و این نام همچنان برای سازگاری با گذشته پشتیبانی می‌شود.

تعداد ثانیه‌ها در هر برش زمانی (time slice) هنگامی که زمان‌بندی گروهی (gang scheduling) فعال است (PreemptMode=SUSPEND,GANG). این مقدار باید بین 5 ثانیه تا 65533 ثانیه باشد. مقدار پیش‌فرض 30 ثانیه است.
نوع زمان‌بند مورد استفاده را مشخص می‌کند. در صورت تمایل می‌توان از دستور scontrol برای تغییر دستی اولویت کارها (jobs) استفاده کرد. مقادیر قابل قبول عبارتند از:
برای ماژول زمان‌بندی پس‌پرکننده (backfill) جهت تقویت زمان‌بندی پیش‌فرض FIFO. زمان‌بندی پس‌پرکننده (backfill) کارهای با اولویت پایین‌تر را در صورتی شروع می‌کند که انجام این کار زمان تخمینی شروع هیچ کاری با اولویت بالاتر را به تاخیر نیندازد. اثربخشی زمان‌بندی backfill به تعیین محدودیت زمانی کارها (time limits) توسط کاربران بستگی دارد، در غیر این صورت همه کارها محدودیت زمانی یکسانی خواهند داشت و پس‌پرکنی (backfilling) غیرممکن خواهد بود. به مستندات گزینه SchedulerParameters در بالا توجه کنید. این پیکربندی پیش‌فرض است.
این زمان‌بند FIFO است که کارها را به ترتیب اولویت شروع می‌کند. اگر هر کاری در پارتیشن نتواند زمان‌بندی شود، هیچ کار با اولویت پایین‌تری در آن پارتیشن زمان‌بندی نخواهد شد. یک استثنا برای کارهایی وجود دارد که به دلیل محدودیت‌های پارتیشن (مانند محدودیت زمانی) یا گره‌های down/drained نمی‌توانند اجرا شوند. در این صورت، کارهای با اولویت پایین‌تر می‌توانند آغاز شوند بدون آن‌که بر کار با اولویت بالاتر تأثیری بگذارند. تنظیم این نوع زمان‌بند، کارهای ناهمگن (heterogeneous jobs) را غیرفعال می‌کند، زیرا آن‌ها توسط زمان‌بند backfill مدیریت می‌شوند.
چندین گزینه می‌توانند با کاما از هم جدا شوند.
فعال‌سازی استفاده از scrontab برای ارسال و مدیریت کارهای دوره‌ای تکرارشونده.
هنگام لغو یک کار scrontab، کاربر ملزم می‌شود تا به طور صریح لغو کار را با پرچم --cron در scancel درخواست کند.
نوع الگوریتم انتخاب منبع (resource selection) مورد استفاده را مشخص می‌کند. در صورت تغییر، تمام اطلاعات کارها (در حال اجرا و در انتظار) از دست خواهد رفت، زیرا قالب ذخیره وضعیت کار مورد استفاده در هر پلاگین متفاوت است. تنها استثنا در این مورد، تغییر از cons_res قدیمی (legacy) به cons_tres است.

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

منابع (هسته‌ها، حافظه، پردازنده‌های گرافیکی GPU و تمام منابع قابل ردیابی دیگر) درون یک گره به صورت جداگانه به عنوان منابع مصرفی (consumable resources) تخصیص می‌یابند. توجه داشته باشید که با استفاده از پارامتر Exclusive در پارتیشن (مانند Exclusive=NODE)، می‌توان گره‌های کامل را برای پارتیشن‌های انتخاب‌شده به کارها تخصیص داد. برای اطلاعات بیشتر به Exclusive و OverSubscribe مراجعه کنید. این مقدار پیش‌فرض است.
برای تخصیص کل گره‌ها با فرض یک آرایه یک‌بعدی از گره‌ها که در آن گره‌های دارای ترتیب متوالی ترجیح داده می‌شوند. برای یک کلاستر ناهمگن (مانند تعداد CPU متفاوت در گره‌های مختلف)، در صورتی که TopologyPlugin=topology/flat پیکربندی شده باشد، تخصیص منابع بر اساس مشخصات گره و CPU مورد نیاز کار، در صورت لزوم گره‌های با تعداد CPU بالا را ترجیح می‌دهد. استفاده از سایر پلاگین‌های توپولوژی با select/linear و گره‌های ناهمگن توصیه نمی‌شود و ممکن است منجر به رد شدن درخواست‌های معتبر تخصیص کار شود. پلاگین linear برای ردیابی منابع عمومی (generic resources) روی یک گره طراحی نشده است. در مواردی که منابع عمومی (مانند GPUها) باید ردیابی شوند، باید به جای آن از پلاگین cons_tres استفاده شود.
نحوه تخصیص گره‌ها به کارها توسط الگوریتم SelectType را کنترل می‌کند. تا زمانی که تداخل‌های شرح‌داده‌شده در زیر وجود نداشته باشد، می‌توان چندین گزینه جداشده با کاما را مشخص کرد. مقادیر مجاز به مقدار پیکربندی‌شده SelectType بستگی دارد.

به طور پیش‌فرض SelectType=select/linear گره‌های کامل را بدون در نظر گرفتن میزان مصرف حافظه به کارها تخصیص می‌دهد. تنها گزینه‌های پشتیبانی‌شده برای select/linear عبارتند از CR_ONE_TASK_PER_CORE (که در زیر توضیح داده شده) و CR_Memory، که با حافظه به عنوان یک منبع مصرفی رفتار می‌کند و از بیش‌اشتراکی (oversubscription) حافظه با آزادسازی انحصاری کارها (job preemption) یا زمان‌بندی گروهی (gang scheduling) جلوگیری می‌کند.

به طور پیش‌فرض SelectType=select/cons_tres از CR_Core_Memory استفاده می‌کند، که هسته‌ها را ضمن در نظر گرفتن مصرف حافظه آن‌ها به کارها تخصیص می‌دهد.

هر یک از گزینه‌های زیر را می‌توان با پلاگین select/cons_tres استفاده کرد تا تعیین شود که آیا منابع CPU بر اساس سوکت، هسته یا CPU منطقی مصرف می‌شوند، و این‌که آیا حافظه مصرف می‌شود یا خیر:

پردازنده‌ها (CPUها) منابع مصرفی هستند. تعداد CPUs را روی هر گره پیکربندی کنید، که بسته به حداقل تخصیص منبع مورد نظر می‌تواند برابر با تعداد هسته‌ها یا hyper-threadها روی گره باشد. پارامترهای Boards، Sockets، CoresPerSocket و ThreadsPerCore گره می‌توانند به صورت اختیاری پیکربندی شوند و منجر به تخصیص کارهایی شوند که محلی‌سازی (locality) بهتری دارند؛ با این حال، انجام این کار مانع از تخصیص بیش از یک کار روی هر هسته خواهد شد.
پردازنده‌ها (CPUها) و حافظه منابع مصرفی هستند. برای جزئیات نحوه مصرف CPUها به CR_CPU مراجعه کنید. تنظیم یک مقدار برای DefMemPerCPU اکیداً توصیه می‌شود.
هسته‌ها منابع مصرفی هستند. روی گره‌های دارای hyper-threads، هر رشته (thread) برای برآورده کردن نیاز منبع یک کار به عنوان یک CPU شمارش می‌شود، اما رشته‌های روی یک هسته یکسان به چند کار تخصیص داده نمی‌شوند. تعداد CPUهای تخصیص‌یافته به یک کار به بالا گرد می‌شود تا تمام CPUهای روی یک هسته تخصیص‌یافته را شامل شود، که این موضوع در صورتی که حافظه از --mem-per-cpu مشتق شده باشد ممکن است بر کل حافظه تخصیص‌یافته نیز تأثیر بگذارد.
هسته‌ها و حافظه منابع مصرفی هستند. برای جزئیات نحوه مصرف هسته‌ها به CR_Core مراجعه کنید. تنظیم یک مقدار برای DefMemPerCPU اکیداً توصیه می‌شود.
سوکت‌ها منابع مصرفی هستند. روی گره‌های با چندین هسته، هر هسته یا رشته به عنوان یک CPU برای برآورده کردن نیاز منبع کار محاسبه می‌شود، اما منابع روی یک سوکت یکسان به چند کار تخصیص داده نمی‌شوند.
سوکت‌ها و حافظه منابع مصرفی هستند. برای جزئیات نحوه مصرف سوکت‌ها به CR_Socket مراجعه کنید. تنظیم یک مقدار برای DefMemPerCPU اکیداً توصیه می‌شود.
هر تعدادی از گزینه‌های زیر را می‌توان با پلاگین select/cons_tres برای تنظیم بیشتر رفتار انتخاب منبع استفاده کرد:
به طور پیش‌فرض یک تسک به ازای هر هسته تخصیص می‌دهد. بدون این گزینه، به طور پیش‌فرض روی گره‌هایی که بیش از یک ThreadsPerCore پیکربندی شده باشد، به ازای هر رشته (thread) یک تسک تخصیص داده می‌شود.

NOTE: این گزینه نمی‌تواند همراه با CR_CPU* استفاده شود.

به طور پیش‌فرض هسته‌های درون یک گره را با استفاده از توزیع بلوکی (block distribution) تخصیص می‌دهد. این یک الگوریتم شبه-بهترین برازش (pseudo-best-fit) است که تعداد بردهای مورد استفاده برای تخصیص و همچنین تعداد سوکت‌ها (درون حداقل بردها) را به حداقل می‌رساند. این رفتار پیش‌فرض را می‌توان با مشخص کردن یک گزینه --distribution خاص هنگام ارسال کار لغو کرد. بدون این گزینه، هسته‌ها به صورت چرخشی (cyclically) در سراسر سوکت‌ها تخصیص می‌یابند.
منابع را بر روی کم‌بارترین گره‌ها (بر اساس تعداد CPUهای بیکار) برای کارها زمان‌بندی می‌کند. این گزینه عموماً فقط برای محیطی با کارهای ترتیبی (serial jobs) توصیه می‌شود، زیرا منابع بیکار تمایل به قطعه‌قطعه شدن شدید (fragmentation) خواهند داشت که منجر به توزیع کارهای موازی در گره‌های متعددی می‌شود. توجه داشته باشید که Weight گره بر میزان منابع بیکار روی هر گره اولویت دارد. همچنین پارامتر پیکربندی پارتیشن LLN را برای استفاده از کم‌بارترین گره‌ها در پارتیشن‌های انتخاب‌شده بررسی کنید.
اگر تخصیص یک کار شامل منابع بیشتری نسبت به آنچه برای راه‌اندازی تسک‌ها استفاده می‌شود باشد (مثلاً اگر گره‌های کامل به یک کار تخصیص داده شوند)، آن‌گاه تسک‌های کار به جای توزیع یکنواخت در میان گره‌های تخصیص‌یافته، تا حد امکان به طور متراکم (pack) روی این گره‌ها قرار می‌گیرند. به عنوان مثال، تخصیص کاری را در نظر بگیرید که شامل دو گره کامل با هشت CPU در هر کدام است. اگر کار ده تسک را در این دو گره بدون این گزینه راه‌اندازی کند، روی هر یک از دو گره پنج تسک اجرا خواهد کرد. با این گزینه، هشت تسک روی گره اول و دو تسک روی گره دوم شروع خواهند شد. این حالت فقط زمانی اعمال می‌شود که گزینه --distribution=block استفاده شده باشد. این رفتار را می‌توان با تنظیم گزینه توزیع NoPack لغو کرد.
هنگام تخصیص منابع برای یک GRES اشتراکی (gres/mps، gres/shard)، دستگاهی را ترجیح می‌دهد که بار کمتری دارد (از نظر کسری از ظرفیت که از قبل تخصیص یافته است). به این ترتیب، کارها در میان دستگاه‌های GRES روی گره توزیع می‌شوند، به جای رفتار پیش‌فرض که در آن از اولین دستگاه در دسترس استفاده می‌شود.
به طور پیش‌فرض، از درخواست‌های GRES اشتراکی فقط یک GRES اشتراکی به ازای هر کار روی هر گره مجاز است. این گزینه اجازه می‌دهد تا چندین GRES اشتراکی روی یک گره واحد برای برآورده کردن نیازمندی‌های GRES اشتراکی به ازای هر کار استفاده شود. مثال: اگر یک GPU دارای 10 بخش (shard) باشد و 12 بخش درخواست شود، به جای رد شدن درخواست، کار با 2 پردازنده گرافیکی (GPU) تخصیص می‌یابد: یکی با استفاده از 10 بخش و دیگری با استفاده از 2 بخش.
تنظیم --gres-flags=enforce-binding به عنوان مقدار پیش‌فرض در هر کار. این مقدار می‌تواند با --gres-flags=disable-binding لغو (override) شود.
تنظیم --gres-flags=one-task-per-sharing به عنوان مقدار پیش‌فرض در هر کار. این مقدار می‌تواند با --gres-flags=multiple-tasks-per-sharing لغو شود.
غیرفعال‌سازی توزیع تسک با آگاهی از توپولوژی (topology-aware) برای گام‌ها (steps). به طور پیش‌فرض، هنگامی که یک پلاگین توپولوژی پیکربندی شده باشد، تسک‌ها بر اساس ترتیب توپولوژی بین گره‌ها توزیع می‌شوند. این گزینه ترتیب را به ترتیب استاندارد بیت‌مپ (bitmap order) بازمی‌گرداند.
NOTE: اگر حافظه به عنوان یک منبع مصرفی پیکربندی نشده باشد (CR_CPU، CR_Core یا CR_Socket بدون _Memory)، حافظه می‌تواند بیش‌اشتراکی (oversubscribe) شود و حتی اگر در cgroup.conf پیکربندی شده باشد، توسط task/cgroup محدود نخواهد شد. در این حالت گزینه --mem فقط برای فیلتر کردن گره‌هایی با حافظه پیکربندی‌شده کمتر استفاده می‌شود و کارهای در حال اجرا را در نظر نمی‌گیرد. به عنوان مثال، دو کار که هر کدام تمام حافظه یک گره را درخواست می‌کنند می‌توانند به طور همزمان اجرا شوند.
یک آدرس اختیاری برای استفاده در ارتباطات با دیمن slurmctld فعال کنونی، که معمولاً با آدرس‌دهی IP مجازی (Virtual IP) برای سرور فعال کنونی استفاده می‌شود. اگر این پارامتر مشخص نشده باشد، هر سرور اصلی و پشتیبان دارای آدرس منحصربه‌فرد خود برای ارتباطات خواهد بود که در پارامتر SlurmctldHost تعیین شده است. اگر این پارامتر مشخص شده باشد، پارامتر SlurmctldHost همچنان برای ارتباط با سرورهای اصلی یا پشتیبان خاص slurmctld استفاده خواهد شد؛ برای مثال جهت وادار کردن همه آن‌ها به خواندن فایل‌های پیکربندی فعلی یا خاموش شدن. همچنین پارامترهای پیکربندی SlurmctldPrimaryOffProg و SlurmctldPrimaryOnProg را برای پیکربندی برنامه‌های دستکاری آدرس IP مجازی بررسی کنید.
سطح جزئیات برای ثبت گزارش‌های (logs) دیمن slurmctld. مقدار پیش‌فرض info است. اگر دیمن slurmctld با گزینه‌های -v یا --verbose راه‌اندازی شود، آن سطح اشکال‌زدایی (debug level) در هنگام پیکربندی مجدد حفظ یا بازیابی خواهد شد.
چیزی ثبت نمی‌شود
فقط خطاهای مهلک (fatal) ثبت می‌شوند
فقط خطاها ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی عمومی ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی مشروح ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی باز هم بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و بیشترین مقدار پیام‌های اشکال‌زدایی ثبت می‌شوند
نام میزبان کوتاه یا بلند دستگاهی که دیمن کنترل Slurm در آن اجرا می‌شود (یعنی نامی که توسط دستور "hostname -s" بازگردانده می‌شود). این نام میزبان می‌تواند به صورت اختیاری با یک آدرس IP یا نامی که بتوان آدرس را با آن شناسایی کرد درون پرانتز همراه باشد، مانند: 
SlurmctldHost=slurmctl-primary(12.34.56.78)

هر میزبانی که یک نمونه از slurmctld را اجرا می‌کند باید دارای یک مدخل SlurmctldHost= باشد، مانند:

SlurmctldHost=slurmctl-primary1
SlurmctldHost=slurmctl-primary2
SlurmctldHost=slurmctl-primary3(12.34.56.78)

پارامتر SlurmctldHost باید حداقل یک بار مشخص شود. اگر بیش از یک بار مشخص شود، مدخل اول به عنوان سرور اصلی (primary) و تمام مدخل‌های دیگر به عنوان پشتیبان‌های آماده‌به‌کار (standby backups) اجرا خواهند شد. اگر میزبان اصلی دچار خرابی شود، اولین پشتیبان از حالت standby به primary تغییر وضعیت می‌دهد تا زمانی که میزبان اول دوباره آنلاین شود. همین فرآیند در صورت خرابی سرور اصلی جدید نیز تکرار خواهد شد.

دیمن‌های Slurm برای اعمال تغییرات این پارامتر باید مجدداً پیکربندی شوند (مثلاً با "scontrol reconfig"). اجرای کارها در حین اعمال این تغییرات مشکلی ایجاد نمی‌کند، زیرا گام‌های در حال اجرا اطلاعات به‌روزشده SlurmctldHost را دریافت خواهند کرد.

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

در صورت نیاز به تغییر این مقدار، به بخش RELOCATING CONTROLLERS مراجعه کنید.

فهرستی از گزینه‌های جداشده با کاما که نحوه احراز هویت درخواست‌های دریافتی توسط شنونده HTTP دیمن slurmctld را کنترل می‌کند. کلیدهای شناخته‌شده همان کلیدهای مرتبط با JWT مستندشده تحت AuthAltParameters هستند. در صورت تنظیم، کلیدهای احراز هویت مستقل به ازای هر دیمن از این پارامترها بارگیری می‌شوند. توکن‌های ارائه‌شده به نقاط پایانی (endpoints) HTTP دیمن slurmctld به جای AuthAltParameters، در برابر این کلیدهای پیکربندی‌شده اعتبارسنجی می‌شوند.
مسیر کامل (مطلق) فایلی که گزارش‌های دیمن slurmctld در آن نوشته می‌شود. مقدار پیش‌فرض none است (ثبت گزارش از طریق syslog انجام می‌شود).
در صورت تعیین مسیر فایل، به بخش LOGGING مراجعه کنید.
چندین گزینه می‌توانند با کاما از هم جدا شوند.
اجازه تنظیم تریگرها (محرک‌ها) توسط کاربرانی غیر از root/slurm_user را می‌دهد. SlurmUser نیز باید روی root تنظیم شده باشد تا این تریگرها کار کنند. برای جزئیات بیشتر به صفحه راهنمای (man page) strigger مراجعه کنید.
به طور پیش‌فرض، Slurm انتظار دارد که آدرس شبکه یک گره ابری تا زمان ایجاد گره مشخص نباشد و آدرس گره به Slurm اطلاع داده شود (مثلاً scontrol update nodename=<name> nodeaddr=<addr>). از آنجا که ارتباطات Slurm به پیکربندی گره در slurm.conf متکی است، Slurm پس از انتظار برای بوت شدن همه گره‌ها، آدرس IP هر گره را به دستور کلاینت اعلام می‌کند. با این حال، در محیط‌هایی که گره‌ها در DNS ثبت شده‌اند، با پیکربندی این گزینه می‌توان از این مرحله صرف‌نظر کرد.
مدت زمان انتظار به اندازه <seconds> ثانیه پیش از آن‌که تلاش برای برقراری اتصال خروجی منقضی‌شده (timed out) تلقی شود. پیش‌فرض برابر با مقدار MessageTimeout است.
حداکثر تعداد اتصالاتی که در هر زمان معین پردازش می‌شوند را مشخص می‌کند. این گزینه بر حداکثر تعداد اتصالات در انتظار تاثیری ندارد زیرا این مورد توسط هسته (kernel) کنترل می‌شود. افزایش این مقدار ردپای حافظه (memory footprint) دیمن slurmctld را افزایش می‌دهد. به مراکز توصیه می‌شود هنگام افزایش این مقدار، میزان مصرف حافظه را نظارت کنند. مقدار پیش‌فرض 512 است.
مدت زمان انتظار به اندازه <seconds> ثانیه پیش از آن‌که فرایند سکون (quiesce) منقضی‌شده تلقی شود. پس از اتمام زمان، تمام اتصالات فعال (غیرشنونده) بسته خواهند شد تا امکان شروع سکون فراهم شود. مقدار پیش‌فرض دو برابر مقدار MessageTimeout است.
مدت زمان انتظار به اندازه <seconds> ثانیه پیش از آن‌که خواندن از یک توصیف‌کننده فایل (file descriptor) منقضی‌شده تلقی شود. پیش‌فرض برابر با مقدار MessageTimeout است.
تعداد رشته‌های پردازشی در استخر رشته‌ها (thread pool) که برای دریافت و پردازش اتصالات روی سوکت‌های شنونده استفاده می‌شود. در اغلب موارد، باید برای بهبود عملکرد زمان‌بندی، conmgr_threads را کاهش دهید.
استفاده از poll(2) به جای epoll(7) برای نظارت بر توصیف‌کننده‌های فایل.
هنگام انتظار برای تخلیه بافر خروجی توسط هسته، هر <seconds> ثانیه یک‌بار هسته را برای تغییرات بررسی (poll) می‌کند. پیش‌فرض برابر با مقدار MessageTimeout است.
مدت زمان انتظار به اندازه <seconds> ثانیه پیش از آن‌که نوشتن در یک توصیف‌کننده فایل منقضی‌شده تلقی شود. پیش‌فرض برابر با مقدار MessageTimeout است.
غیرفعال‌سازی قابلیت ثبت تریگرهای جدید.
فعال کردن slurmctld برای پاسخ‌گویی ناهمگام (asynchronous) به RPCهای ورودی (پشتیبانی‌شده) بدون مسدود کردن یک رشته در استخر رشته‌های conmgr.
اجازه اجرای عملیات "بدون پیکربندی" (configless) توسط slurmd، slurmstepd و دستورات کاربر را می‌دهد. در صورت فعال بودن، slurmd مجاز خواهد بود فایل‌های پیکربندی و اسکریپت‌های Prolog، Epilog، TaskProlog و TaskEpilog را از slurmctld دریافت کند و با هر دستور 'scontrol reconfigure'، پیکربندی‌ها و اسکریپت‌های جدید به طور خودکار ارسال شده و بر روی گره‌هایی که در این حالت "configless" اجرا می‌شوند اعمال می‌گردند. برای جزئیات بیشتر به https://slurm.schedmd.com/configless_slurm.html مراجعه کنید.

NOTE: فایل‌های گنجانده‌شده با دستورالعمل Include تنها در صورتی ارسال می‌شوند که نام فایل فاقد جداکننده مسیر باشد و در مجاورت slurm.conf قرار داشته باشد.

NOTE: اسکریپت‌های Prolog و Epilog تنها در صورتی ارسال می‌شوند که نام‌های فایل فاقد جداکننده مسیر بوده و در مجاورت slurm.conf قرار داشته باشند. الگوهای تطبیق سراسری (Glob patterns) (به glob (7) مراجعه کنید) پشتیبانی نمی‌شوند.

اجازه می‌دهد کارها در رخدادهای خاصی درخواست صف‌بندی مجدد سریع (expedited requeue) داشته باشند. یک صف‌بندی مجدد سریع تضمین می‌کند که کار بلافاصله واجد شرایط اجرا شده و در بالای صف قرار می‌گیرد.
فعال‌سازی مدیریت گام slurmstepd در سراسر سیستم. این گزینه امکان مدیریت گام‌های کار را توسط یک slurmstepd خارجی واحد مرتبط با کار برای مدیریت گام‌ها فراهم می‌کند. این امر برای کارهایی که گام‌های زیادی را در تخصیص‌های خود ارسال می‌کنند مفید است. PrologFlags=contain باید تنظیم شده باشد.
هنگام تعلیق گره‌ها با SuspendProgram، صرف‌نظر از وضعیت فعلی، گره‌ها را به عنوان بیکار (idle) علامت‌گذاری می‌کند تا گره‌ها در زمان‌های بعدی واجد شرایط ازسرگیری (resumed) باشند.
عملیاتی که پس از رسیدن به حد MaxDBDMsgs انجام می‌شود، گزینه‌ها شامل 'discard' (پیش‌فرض) و 'exit' هستند.

هنگامی که 'discard' مشخص شده و به MaxDBDMsgs برسد، با پاکسازی پیام‌های در انتظار از نوع Step start و Step complete شروع می‌کنیم، و اگر دوباره به MaxDBDMsgs برسد، پیام‌های Job start پاکسازی می‌شوند. پیام‌های Job completes و تغییرات وضعیت گره همچنان فضای خالی ایجادشده از پاکسازی‌ها را مصرف می‌کنند تا زمانی که دوباره به MaxDBDMsgs برسد، که در آن نقطه هیچ پیام جدیدی ردیابی نمی‌شود و این امر باعث از دست رفتن داده‌ها و احتمالاً ایجاد کارهای مهارنشدنی (runaway jobs) می‌گردد.

هنگامی که 'exit' مشخص شده و به MaxDBDMsgs برسد، دیمن slurmctld به جای دور ریختن هر پیامی، متوقف خواهد شد (exit می‌کند). با فعال بودن این گزینه، در صورتی که slurmdbd از کار افتاده باشد و slurmctld بیش از MaxDBDMsgs پیام را ردیابی کند، راه‌اندازی slurmctld غیرممکن خواهد بود.

حداکثر تعداد گره‌های روشن‌شده (powered up) در سراسر کلاستر. پس از رسیدن به این حد، کارهایی که گره‌های اضافی درخواست می‌کنند شروع نخواهند شد، و دستور "scontrol power up <nodes>" با شکست مواجه می‌شود.

توصیه می‌شود task/cgroup همراه با ConstrainRamSpace پیکربندی شود. محدودیت cgroup حافظه بیشتر از حافظه واقعی موجود در گره تنظیم نخواهد شد. در صورت نیاز، AllowedRamSpace را در cgroup.conf برای افزودن یک بافر پیکربندی کنید.

به طور پیش‌فرض، راه‌اندازی یک نمونه جدید از slurmctld نمونه قبلی در حال اجرا را پیش از به دست گرفتن کنترل متوقف می‌کند (kill می‌کند). اگر این گزینه تنظیم شده باشد، این اتفاق بدون گزینه -i رخ نخواهد داد.
فواصل زمانی بررسی رشته power_save جهت ازسرگیری و تعلیق گره‌ها. در صورت وجود تغییرات وضعیت گره، رشته power_save زودتر کار را انجام می‌دهد. مقدار پیش‌فرض 10 ثانیه است.
حداقل فواصل زمانی بررسی رشته power_save جهت ازسرگیری و تعلیق گره‌ها. مقدار پیش‌فرض 0 است.
اجرای RebootProgram از کنترل‌کننده به جای اجرا روی slurmdها. به RebootProgram یک فهرست جداشده با کاما از گره‌ها جهت راه‌اندازی مجدد به عنوان آرگومان اول و در صورت وجود، ویژگی‌های مورد نیاز برای راه‌اندازی مجدد به عنوان آرگومان دوم ارسال می‌شود. اگر RebootProgram روی یک PowerAction تنظیم شده باشد، این پارامتر به نفع Location مربوط به PowerAction نادیده گرفته می‌شود.
هر بار راه‌اندازی مجدد slurmctld (راه‌اندازی مجدد فرآیند که توسط "scontrol reconfigure" آغاز نشده باشد) یک درخواست پیکربندی مجدد را به تمام دیمن‌های slurmd و sackd ارسال می‌کند. برای سیستم‌های "configless"، این کار تضمین می‌کند که تمام فرآیندها با پیکربندی فعلی اجرا می‌شوند.

NOTE: هنگام انجام ارتقاهای تدریجی (rolling upgrades) با احتیاط استفاده شود، زیرا ممکن است سهواً باعث ارتقای دیمن‌های slurmd یا sackd زودتر از زمان مورد نظر شود.

اندازه سطل توکن (token bucket). این گزینه امکان مقدار مشخصی از بار ناگهانی (burst) RPC از طرف یک کاربر را پیش از اعمال محدودیت نرخ در حالت پایدار (steady-state) فراهم می‌کند. مقدار پیش‌فرض 30 است.
فعال‌سازی پشتیبانی از محدودسازی نرخ RPC به ازای هر کاربر (per-user rate-limiting). پس از رسیدن به این محدودیت، به دستورات کلاینت اعلام می‌شود که عقب‌نشینی (back off) کرده و به مدت یک ثانیه به حالت تعلیق (sleep) بروند. این ویژگی به صورت یک "سطل توکن" (token bucket) پیاده‌سازی شده است، که میزان مشخصی از بار RPC ناگهانی و پرحجم را از سوی یک کاربر مجاز می‌شمارد قبل از اینکه آن‌ها را به یک بار RPC با حالت پایدار تعیین‌شده توسط دوره پر کردن مجدد و نرخ آن محدود کند.
حداکثر بسامد (به ثانیه) برای ثبت گزارش‌های مربوط به فراتر رفتن از حد مجاز RPC توسط یک کاربر در لاگ‌ها. برای مشاهده هر رخداد، مقدار را روی 0 تنظیم کنید. برای غیرفعال کردن کامل پیام گزارش، مقدار را روی -1 قرار دهید. مقدار پیش‌فرض 0 است.
فاصله زمانی (بر حسب ثانیه) که طی آن توکن‌های اضافی به سطل هر کاربر افزوده می‌شود. مقدار پیش‌فرض 1 است.
تعداد توکن‌هایی که در هر دوره به سطل اضافه می‌شوند. مقدار پیش‌فرض 2 است.
تعداد مدخل‌ها در جدول درهم‌سازی (hash table) کاربران. مقدار توصیه‌شده باید حداقل دو برابر تعداد حساب‌های کاربری فعال روی سیستم باشد. مقدار پیش‌فرض 8192 است.
به هر کاربری که قادر به اجرا در یک رزرو باشد اجازه حذف آن را می‌دهد.
در طول راه‌اندازی، slurmctld آدرس هر گره محاسباتی در سیستم را جستجو می‌کند. در سیستم‌های بزرگ این امر می‌تواند باعث تاخیر قابل توجهی شود؛ این گزینه به slurmctld اجازه می‌دهد تا فراخوانی‌های جستجو را به طور همزمان پردازش کند و زمان راه‌اندازی سیستم را به میزان قابل توجهی کاهش دهد. مقدار پیش‌فرض 1 است. حداکثر مقدار مجاز 64 است.
مسیر کامل (مطلق) فایلی که دیمن slurmctld می‌تواند شناسه فرآیند (PID) خود را در آن بنویسد. این فایل می‌تواند برای پردازش خودکار سیگنال استفاده شود. مقدار پیش‌فرض "/var/run/slurmctld.pid" است.
شماره پورتی که کنترل‌کننده Slurm، یعنی slurmctld، برای انجام کارها به آن گوش می‌دهد. مقدار پیش‌فرض SLURMCTLD_PORT است که در زمان ساخت سیستم (build time) تعیین شده است. در صورت عدم تعیین صریح، روی 6817 تنظیم خواهد شد. SlurmctldPort همچنین می‌تواند برای پشتیبانی از محدوده‌ای از شماره پورت‌ها برای پیکربندی‌های قدیمی موجود تنظیم شود. NOTE: دیمن‌های slurmctld و slurmd نباید روی گره‌های یکسانی اجرا شوند یا این‌که مقادیر SlurmctldPort و SlurmdPort باید با یکدیگر متفاوت باشند.

NOTE: در سیستم‌های Cray، آدرس‌دهی IP مخصوص قلمرو (RSIP) به طور خودکار سعی می‌کند با هر چیزی که روی پورت‌های 8192-60000 باز شده تعامل برقرار کند. مقدار SlurmctldPort را طوری پیکربندی کنید که از پورتی خارج از SrunPortRange پیکربندی‌شده و محدوده پورت RSIP استفاده کند.

این برنامه زمانی اجرا می‌شود که یک دیمن slurmctld در حال اجرا به عنوان سرور اصلی، به یک سرور پشتیبان تبدیل شود. کنترل‌کننده قبل از خاموش شدن کامل، منتظر پایان یافتن این اسکریپت خواهد ماند. به طور پیش‌فرض هیچ برنامه‌ای اجرا نمی‌شود. همچنین پارامتر مرتبط "SlurmctldPrimaryOnProg" را ببینید.
این برنامه زمانی اجرا می‌شود که یک دیمن slurmctld در حال اجرا به عنوان سرور پشتیبان، به سرور اصلی تبدیل شود. کنترل‌کننده قبل از راه‌اندازی کامل، منتظر پایان یافتن این اسکریپت خواهد ماند. به طور پیش‌فرض هیچ برنامه‌ای اجرا نمی‌شود. هنگام استفاده از آدرس‌های IP مجازی برای مدیریت سرویس‌های دسترسی‌پذیری بالای (High Available) Slurm، این برنامه می‌تواند برای افزودن آدرس IP به یک رابط (اینترفیس) استفاده شود (و به صورت اختیاری برای خاتمه دادن به دیمن پاسخ‌نداده slurmctld و پاکسازی حافظه‌های نهان ARP در گره‌های روی بستر اترنت محلی تلاش کند). همچنین پارامتر مرتبط "SlurmctldPrimaryOffProg" را ببینید.
دیمن slurmctld رخدادها را در فایل syslog با سطح جزئیات مشخص‌شده ثبت خواهد کرد. اگر تنظیم نشده باشد، دیمن slurmctld در syslog با سطح fatal گزارش ثبت می‌کند، مگر این‌که هیچ SlurmctldLogFile وجود نداشته باشد و در پس‌زمینه در حال اجرا باشد، که در این صورت در syslog با سطح مشخص‌شده توسط SlurmctldDebug گزارش ثبت می‌کند (با سطح fatal در صورتی که SlurmctldDebug روی quiet تنظیم شده باشد) یا در صورتی که در پیش‌زمینه اجرا شود، روی quiet تنظیم خواهد شد.
چیزی ثبت نمی‌شود
فقط خطاهای مهلک (fatal) ثبت می‌شوند
فقط خطاها ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی عمومی ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی مشروح ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی باز هم بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی مشروح و بیشترین مقدار پیام‌های اشکال‌زدایی ثبت می‌شوند
NOTE: به طور پیش‌فرض، فایل سرویس systemd مربوط به Slurm دیمن slurmctld را در پیش‌زمینه همراه با گزینه --systemd راه‌اندازی می‌کند. این بدان معناست که systemd خروجی stdout/stderr را ضبط کرده و مستقل از ثبت مستقیم Slurm در syslog، آن را در syslog چاپ می‌کند. برای جلوگیری از انجام این کار توسط systemd، مقدار "StandardOutput=null" و "StandardError=null" را به فایل‌های سرویس مربوطه یا فایل‌های override اضافه کنید.
مدت زمان (به ثانیه) که کنترل‌کننده پشتیبان پیش از به دست گرفتن کنترل، منتظر پاسخ کنترل‌کننده اصلی می‌ماند. مقدار پیش‌فرض ۱۲۰ ثانیه است. نباید از ۶۵۵۳۳ تجاوز کند.
سطح جزئیات ثبت وقایع (لاگ‌های) دیمن slurmd. مقدار پیش‌فرض info است.
هیچ چیزی ثبت نمی‌شود
تنها خطاهای مهلک ثبت می‌شوند
تنها خطاها ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی عمومی ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی پرجزئیات ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
فهرستی از گزینه‌های جداشده با ویرگول که نحوه احراز هویت درخواست‌های ورودی توسط شنونده HTTP دیمن slurmd را کنترل می‌کند. کلیدهای شناخته‌شده همان کلیدهای مرتبط با JWT هستند که در بخش AuthAltParameters مستند شده‌اند. هنگام تنظیم، کلیدهای احراز هویت مستقل به ازای هر دیمن از این پارامترها بارگذاری می‌شوند. توکن‌های ارائه‌شده به نقاط پایانی HTTP دیمن slurmd به‌جای AuthAltParameters در برابر این زمینه (context) اعتبارسنجی می‌شوند.
مسیر کامل (مطلق) فایلی که گزارش‌ها و لاگ‌های دیمن slurmd در آن نوشته می‌شوند. مقدار پیش‌فرض none است (ثبت وقایع از طریق syslog انجام می‌شود). اولین "%h" در نام با نام میزبانی (hostname) که slurmd روی آن در حال اجرا است جایگزین می‌شود. اولین "%n" در نام با نام گره اسلورمی که slurmd روی آن در حال اجرا است جایگزین می‌شود.
در صورت مشخص شدن مسیر فایل، بخش LOGGING را ببینید.
پارامترهای مختص Slurmd. چندین گزینه می‌توانند با ویرگول از هم جدا شوند.

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

در صورت تنظیم، و در صورتی که پردازنده‌های گره‌های شما دارای E-Core باشند، اجازه می‌دهد از آن‌ها برای زمان‌بندی و جای‌گذاری وظایف استفاده شود. (به‌طور پیش‌فرض، E-Coreها نادیده گرفته می‌شوند.)
در صورت تنظیم، پیکربندی هر گره همان پیکربندی مشخص‌شده در فایل پیکربندی slurm.conf در نظر گرفته می‌شود و هیچ گره‌ای با منابع کمتر از منابع پیکربندی‌شده در وضعیت INVAL/INVALID_REG قرار نخواهد گرفت. این گزینه عموماً فقط برای مقاصد آزمایشی مفید است. معادل گزینه منسوخ‌شده FastSchedule=2 می‌باشد.
به مدت <seconds> پیش از در نظر گرفتن تلاش اتصال خروجی به عنوان منقضی‌شده (تایم‌اوت) منتظر می‌ماند. مقدار پیش‌فرض آن برابر با مقدار MessageTimeout است.
حداکثر تعداد اتصالاتی که باید در هر لحظه پردازش شوند را مشخص می‌کند. این گزینه روی حداکثر تعداد اتصالات در انتظار (pending) تأثیری ندارد زیرا توسط هسته لینوکس کنترل می‌شود. افزایش این مقدار باعث افزایش ردپای حافظه slurmd می‌شود. به مراکز توصیه می‌شود هنگام افزایش این مقدار، مصرف حافظه را پایش کنند. مقدار پیش‌فرض ۵۱۲ است.
به مدت <seconds> پیش از منقضی شدن زمان سکون (quiesce) منتظر می‌ماند. پس از انقضای زمان، تمام اتصالات فعال (غیرشنونده) بسته خواهند شد تا سکون بتواند آغاز شود. مقدار پیش‌فرض دو برابر مقدار MessageTimeout است.
به مدت <seconds> پیش از منقضی در نظر گرفتن زمان خواندن از یک توصیف‌گر فایل (file descriptor) منتظر می‌ماند. مقدار پیش‌فرض آن برابر با مقدار MessageTimeout است.
تعداد رشته‌های پردازشی (threads) در مخزن رشته‌ها که برای دریافت و پردازش اتصالات روی سوکت‌های شنونده استفاده می‌شود. در اکثر موارد، باید conmgr_threads را کاهش دهید تا کارایی زمان‌بندی بهبود یابد. مقدار پیش‌فرض ۶ رشته است.
استفاده از poll(2) به‌جای epoll(7) جهت پایش توصیف‌گرهای فایل.
هنگام انتظار برای تخلیه بافر خروجی توسط هسته، هر <seconds> برای بررسی تغییرات هسته را پایش (poll) می‌کند. مقدار پیش‌فرض آن برابر با مقدار MessageTimeout است.
به مدت <seconds> پیش از منقضی در نظر گرفتن زمان نوشتن در یک توصیف‌گر فایل منتظر می‌ماند. مقدار پیش‌فرض آن برابر با مقدار MessageTimeout است.
در صورت تنظیم و مشخص بودن یک پلاگین namespace، فراخوانی‌های spank_user()، spank_task_post_fork() و spank_task_exit() درون فضای نام (namespace) کار اجرا خواهند شد.
استفاده از l3cache در hwloc به عنوان تعداد سوکت. این گزینه می‌تواند بر روی پردازنده‌های خاصی که سطح سوکت در آن‌ها بسیار درشت‌دانه است مفید باشد، و l3cache ممکن است توزیع وظایف بهتری را فراهم کند (برای مثال در راستای مرزهای CCX به‌جای مرزهای سوکت). مانعةالجمع با numa_node_as_socket است. نیازمند hwloc v2 است.

NOTE: هنگامی که این پارامتر تنظیم می‌شود، تعاریف گره در slurm.conf (Sockets یا SocketsPerBoard، CoresPerSocket و ThreadsPerCore) باید به‌روزرسانی شوند تا منعکس‌کننده توپولوژی حاصله مطابق با گزارش slurmd -C --parameters=l3cache_as_socket باشند، نه چیدمان فیزیکی سخت‌افزار. عدم به‌روزرسانی این مقادیر منجر به عدم تطابق بین آنچه slurmd شناسایی می‌کند و آنچه کنترل‌کننده انتظار دارد خواهد شد.

استفاده از گره NUMA در hwloc برای تعیین شیء سلسله‌مراتبی اصلی که به عنوان سوکت استفاده می‌شود. اگر این گزینه تنظیم شود، اسلورم شیء والد گره NUMA را بررسی کرده و از آن به عنوان سوکت استفاده می‌کند. این گزینه ممکن است برای معماری‌هایی مانند AMD Epyc مفید باشد که تعداد گره‌ها در هر سوکت در آن‌ها قابل پیکربندی است. مانعةالجمع با l3cache_as_socket است. نیازمند hwloc v2 است.

NOTE: هنگامی که این پارامتر تنظیم می‌شود، تعاریف گره در slurm.conf (Sockets یا SocketsPerBoard، CoresPerSocket و ThreadsPerCore) باید به‌روزرسانی شوند تا منعکس‌کننده توپولوژی حاصله مطابق با گزارش slurmd -C --parameters=numa_node_as_socket باشند، نه چیدمان فیزیکی سخت‌افزار. عدم به‌روزرسانی این مقادیر منجر به عدم تطابق بین آنچه slurmd شناسایی می‌کند و آنچه کنترل‌کننده انتظار دارد خواهد شد.

در صورت تنظیم، Slurmd هنگام دریافت درخواست راه‌اندازی مجدد (reboot)، خود را خاموش خواهد کرد.
مسیر کامل فایلی که دیمن slurmd ممکن است شناسه فرایند (PID) خود را در آن بنویسد. این می‌تواند برای پردازش خودکار سیگنال‌ها استفاده شود. اولین "%h" در نام با نام میزبانی که slurmd روی آن در حال اجرا است جایگزین می‌شود. اولین "%n" در نام با نام گره اسلورمی که slurmd روی آن در حال اجرا است جایگزین می‌شود. مقدار پیش‌فرض "/var/run/slurmd.pid" است.
شماره پورتی که دیمن گره محاسباتی اسلورم، slurmd، برای دریافت کار به آن گوش می‌دهد. مقدار پیش‌فرض SLURMD_PORT است که در زمان ساخت سیستم تعیین شده است. اگر هیچ مقداری به‌صراحت مشخص نشود، مقدار آن ۶۸۱۸ خواهد بود. NOTE: یا دیمن‌های slurmctld و slurmd نباید روی یک گره یکسان اجرا شوند، یا اینکه مقادیر SlurmctldPort و SlurmdPort باید متفاوت باشند.

NOTE: در سیستم‌های Cray، سازوکار Realm-Specific IP Addressing (RSIP) به‌طور خودکار تلاش می‌کند با هر پورت باز در محدوده ۸۱۹۲-۶۰۰۰۰ تعامل داشته باشد. SlurmdPort را به گونه‌ای پیکربندی کنید که از پورتی خارج از SrunPortRange پیکربندی‌شده و محدوده پورت RSIP استفاده کند.

مسیر کامل دایرکتوری که اطلاعات وضعیت دیمن slurmd و اطلاعات اسکریپت کارهای دسته‌ای (batch job) در آن نوشته می‌شوند. این باید یک مسیر مشترک برای همه گره‌ها باشد، اما باید نشان‌دهنده دایرکتوری محلی در هر گره باشد (به یک سیستم فایل محلی اشاره کند). مقدار پیش‌فرض "/var/spool/slurmd" است. اولین "%h" در نام با نام میزبانی که slurmd روی آن در حال اجرا است جایگزین می‌شود. اولین "%n" در نام با نام گره اسلورمی که slurmd روی آن در حال اجرا است جایگزین می‌شود.
دیمن slurmd رویدادها را در فایل syslog در سطح مشخص‌شده‌ای از جزئیات ثبت می‌کند. در صورت عدم تنظیم، دیمن slurmd در سطح fatal وقایع را در syslog ثبت می‌کند، مگر اینکه SlurmdLogFile وجود نداشته باشد و در پس‌زمینه اجرا شود که در این صورت در سطح مشخص‌شده توسط SlurmdDebug در syslog ثبت خواهد شد (و در صورتی که SlurmdDebug روی quiet تنظیم شده باشد، در سطح fatal)، یا اینکه در پیش‌زمینه اجرا شود که روی quiet تنظیم خواهد شد.
هیچ چیزی ثبت نمی‌شود
تنها خطاهای مهلک ثبت می‌شوند
تنها خطاها ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی عمومی ثبت می‌شوند
خطاها و پیام‌های اطلاعاتی پرجزئیات ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
خطاها، پیام‌های اطلاعاتی پرجزئیات و پیام‌های اشکال‌زدایی حتی بیشتر ثبت می‌شوند
NOTE: به‌طور پیش‌فرض، فایل سرویس systemd اسلورم، دیمن slurmd را با گزینه --systemd در پیش‌زمینه راه‌اندازی می‌کند. این بدان معناست که systemd خروجی‌های stdout/stderr را گرفته و مستقل از ثبت مستقیم اسلورم در syslog، آن‌ها را در syslog چاپ می‌کند. برای جلوگیری از این کار توسط systemd، مقدار "StandardOutput=null" و "StandardError=null" را به فایل‌های سرویس مربوطه یا فایل‌های override اضافه کنید.
مدت زمان (به ثانیه) که کنترل‌کننده اسلورم پیش از تنظیم وضعیت آن گره به DOWN، منتظر پاسخ slurmd می‌ماند. مقدار صفر نشان می‌دهد که گره توسط slurmctld برای تأیید وضعیت slurmd آزمایش نخواهد شد، گره به‌طور خودکار به وضعیت DOWN برای نشان دادن یک slurmd بدون پاسخ تنظیم نخواهد شد، و ابزار دیگری مسئولیت پایش وضعیت هر گره محاسباتی و دیمن slurmd آن را بر عهده خواهد گرفت. مکانیزم ارتباطی سلسله‌مراتبی اسلورم برای ارسال پینگ به دیمن‌های slurmd جهت به حداقل رساندن نویز و بار اضافی سیستم استفاده می‌شود. مقدار پیش‌فرض ۳۰۰ ثانیه است. مقدار نباید از ۶۵۵۳۳ ثانیه تجاوز کند.
نام کاربری که دیمن slurmd با آن اجرا می‌شود. این کاربر باید در تمام گره‌های کلاستر جهت احراز هویت ارتباطات بین اجزای اسلورم وجود داشته باشد. مقدار پیش‌فرض "root" است که تقریباً در همه موارد باید حفظ شود تا slurmd بتواند کارها را با همان کاربری که آن‌ها را ارسال کرده است اجرا کند.
مسیر کامل فایل ثبت رویدادهای زمان‌بندی (scheduling). سینتکس این پارامتر همانند SlurmctldLogFile است. برای پیکربندی ثبت رویدادهای زمان‌بند، هر دو پارامتر SlurmSchedLogFile و SlurmSchedLogLevel را تنظیم کنید.
سطح اولیه ثبت رویدادهای زمان‌بندی، مشابه پارامتر SlurmctldDebug که برای کنترل سطح اولیه ثبت لاگ‌های slurmctld استفاده می‌شود. مقادیر معتبر برای SlurmSchedLogLevel شامل "0" (غیرفعال بودن لاگ زمان‌بند) و "1" (فعال بودن لاگ زمان‌بند) است. اگر این پارامتر حذف شود، مقدار پیش‌فرض "0" (غیرفعال) خواهد بود. برای پیکربندی ثبت رویدادهای زمان‌بند، هر دو پارامتر SlurmSchedLogFile و SlurmSchedLogLevel را تنظیم کنید. سطح ثبت لاگ زمان‌بند می‌تواند به‌صورت پویا با استفاده از scontrol تغییر یابد.
نام کاربری که دیمن slurmctld با آن اجرا می‌شود. به دلایل امنیتی، کاربری غیر از "root" توصیه می‌شود. این کاربر باید در تمام گره‌های کلاستر جهت احراز هویت ارتباطات بین اجزای اسلورم وجود داشته باشد. مقدار پیش‌فرض "root" است.
مسیر کامل برنامه‌ای که srun پس از اتمام یک گام کاری (job step) اجرا می‌کند. آرگومان‌های خط فرمان این برنامه اجرایی، همان دستور و آرگومان‌های گام کاری خواهند بود. این پارامتر پیکربندی می‌تواند توسط پارامتر --epilog در srun بازنویسی (override) شود. توجه داشته باشید در حالی که سایر برنامه‌های اجرایی "Epilog" (مانند TaskEpilog) توسط slurmd روی گره‌های محاسباتی که وظایف در آن‌ها اجرا می‌شوند اجرا می‌گردند، SrunEpilog روی گره‌ای اجرا می‌شود که "srun" در حال اجرا در آن است.
دستور srun مجموعه‌ای از پورت‌های شنونده را برای برقراری ارتباط با کنترل‌کننده، slurmstepd و مدیریت ورودی/خروجی برنامه (I/O) ایجاد می‌کند. به‌طور پیش‌فرض این پورت‌ها گذرا (ephemeral) هستند، به این معنی که شماره پورت‌ها توسط هسته انتخاب می‌شوند. استفاده از این پارامتر به مراکز اجازه می‌دهد تا محدوده‌ای از پورت‌ها را پیکربندی کنند که پورت‌های srun از بین آن‌ها انتخاب شوند. این امر زمانی مفید است که مراکز بخواهند تنها محدوده خاصی از پورت‌ها را در شبکه خود مجاز کنند.

NOTE: در سیستم‌های Cray، سازوکار Realm-Specific IP Addressing (RSIP) به‌طور خودکار تلاش می‌کند با هر چیزی که روی پورت‌های ۸۱۹۲-۶۰۰۰۰ باز شده است تعامل برقرار کند. SrunPortRange را طوری پیکربندی کنید که از محدوده‌ای از پورت‌ها بالاتر از پورت‌های مورداستفاده توسط RSIP استفاده کند، در حالت ایده‌آل ۱۰۰۰ پورت یا بیشتر، برای مثال "SrunPortRange=60001-63000".

NOTE: پارامتر SrunPortRange باید به اندازه کافی بزرگ باشد تا تعداد مورد انتظار پورت‌های ایجادشده توسط srun را پوشش دهد. یک srun منفرد ۴ پورت شنونده به علاوه ۲ پورت بیشتر به ازای هر ۴۸ میزبان فراتر از ۴۸ میزبان اول باز می‌کند. استفاده از گزینه --pty منجر به استفاده از یک پورت اضافه خواهد شد.

مثال:

srun -N 1        از ۴ پورت شنونده استفاده خواهد کرد.
srun --pty -N 1  از ۵ پورت شنونده استفاده خواهد کرد.
srun -N 48       از ۴ پورت شنونده استفاده خواهد کرد.
srun -N 50       از ۶ پورت شنونده استفاده خواهد کرد.
srun -N 200      از ۱۲ پورت شنونده استفاده خواهد کرد.
مسیر کامل برنامه‌ای که srun پیش از راه‌اندازی یک گام کاری اجرا می‌کند. آرگومان‌های خط فرمان این برنامه اجرایی، همان دستور و آرگومان‌های گام کاری خواهند بود. این پارامتر پیکربندی می‌تواند توسط پارامتر --prolog در srun بازنویسی (override) شود. توجه داشته باشید در حالی که سایر برنامه‌های اجرایی "Prolog" (مانند TaskProlog) توسط slurmd روی گره‌های محاسباتی که وظایف در آن‌ها اجرا می‌شوند اجرا می‌گردند، SrunProlog روی گره‌ای اجرا می‌شود که "srun" در حال اجرا در آن است.
مسیر کامل دایرکتوری که کنترل‌کننده اسلورم، slurmctld، وضعیت خود را در آن ذخیره می‌کند (مانند "/usr/local/slurm/checkpoint"). وضعیت اسلورم در اینجا ذخیره خواهد شد تا امکان بازیابی پس از خرابی‌های سیستم وجود داشته باشد. کاربر SlurmUser باید بتواند در این دایرکتوری فایل ایجاد کند. اگر یک SlurmctldHost ثانویه پیکربندی کرده‌اید، این مکان باید برای هر دو سیستم قابل خواندن و نوشتن باشد. از آنجا که تمام اطلاعات کارهای در حال اجرا و در انتظار در اینجا ذخیره می‌شود، استفاده از یک سیستم فایل قابل اطمینان (مانند RAID) توصیه می‌شود. مقدار پیش‌فرض "/var/spool" است. در صورت خاتمه غیرعادی هر یک از دیمن‌های اسلورم، فایل‌های core dump آن‌ها نیز در این دایرکتوری نوشته خواهد شد.
گره‌هایی را مشخص می‌کند که نباید در حالت ذخیره انرژی (power save mode) قرار گیرند، حتی اگر گره برای مدت طولانی بیکار (idle) بماند. از عبارت hostlist یا NodeSets اسلورم برای شناسایی گره‌ها با جداکننده اختیاری ":" و تعداد گره‌هایی که باید از محدوده قبلی مستثنی شوند استفاده کنید. برای مثال "nid[10-20]:4" مانع از خاموش شدن ۴ گره روشن در مجموعه "nid[10-20]" می‌شود. مجموعه‌های متعددی از گره‌ها را می‌توان با یا بدون تعداد در یک فهرست جداشده با ویرگول مشخص کرد (مانند "nid[10-20]:4,nid[80-90]:2"). به‌طور پیش‌فرض هیچ گره‌ای مستثنی نمی‌شود. این مقدار می‌تواند با scontrol به‌روزرسانی شود. برای ماندگاری تنظیمات، ReconfigFlags=KeepPowerSaveSettings را ببینید.
پارتیشن‌هایی را مشخص می‌کند که گره‌های آن‌ها نباید در حالت ذخیره انرژی قرار گیرند، حتی اگر گره برای مدت طولانی بیکار بماند. چندین پارتیشن را می‌توان مشخص کرده و با ویرگول از هم جدا نمود. به‌طور پیش‌فرض هیچ گره‌ای مستثنی نمی‌شود. این مقدار می‌تواند با scontrol به‌روزرسانی شود. برای ماندگاری تنظیمات، ReconfigFlags=KeepPowerSaveSettings را ببینید.
وضعیت‌های گره‌ای را مشخص می‌کند که نباید به‌طور خودکار خاموش شوند. وضعیت‌های معتبر شامل CLOUD، DOWN، DRAIN، DYNAMIC_FUTURE، DYNAMIC_NORM، FAIL، INVALID_REG، MAINTENANCE، NOT_RESPONDING، PLANNED و RESERVED هستند. به‌طور پیش‌فرض، هر یک از این وضعیت‌ها در صورتی که به مدت SuspendTime بیکار باشند، خاموش خواهند شد. این مقدار می‌تواند با scontrol به‌روزرسانی شود. برای ماندگاری تنظیمات، ReconfigFlags=KeepPowerSaveSettings را ببینید.
برنامه SuspendProgram برنامه‌ای است که هنگام بیکار ماندن یک گره برای مدت طولانی اجرا خواهد شد. این پارامتر همچنین می‌تواند روی نام یک PowerAction تنظیم شود. انتظار می‌رود این برنامه گره را در حالتی از ذخیره انرژی قرار دهد. از این قابلیت می‌توان برای کاهش فرکانس و ولتاژ یک گره یا خاموش کردن کامل آن استفاده کرد. آرگومان ورودی این برنامه، نام گره‌هایی خواهد بود که باید در حالت ذخیره انرژی قرار گیرند (با استفاده از قالب عبارت hostlist اسلورم). به‌طور پیش‌فرض، هیچ برنامه‌ای اجرا نمی‌شود. اگر اجرای برنامه‌ها بیشتر از بزرگ‌ترین مقدار پیکربندی‌شده سراسری یا پارتیشن برای ResumeTimeout یا SuspendTimeout طول بکشد، متوقف (kill) خواهند شد.
نرخی که گره‌ها توسط SuspendProgram در حالت ذخیره انرژی قرار می‌گیرند. این مقدار بر حسب تعداد گره در دقیقه است و می‌تواند برای جلوگیری از افت شدید در مصرف برق (برای مثال پس از اتمام یک کار بزرگ) استفاده شود. مقدار صفر منجر به عدم اعمال هرگونه محدودیت می‌شود. مقدار پیش‌فرض ۶۰ گره در دقیقه است.
گره‌هایی که به مدت این تعداد ثانیه در وضعیت بیکار (idle) یا خاموش/خراب (down) باقی بمانند، توسط SuspendProgram در حالت ذخیره انرژی قرار خواهند گرفت. این مقدار می‌تواند بر اساس هر پارتیشن یا هر گره بازنویسی (override) شود. تنظیم SuspendTime روی هر مقداری به جز INFINITE (یا -1) حالت ذخیره انرژی را فعال می‌کند. مقدار پیش‌فرض INFINITE است.
حداکثر زمان مجاز (به ثانیه) بین زمان صدور درخواست تعلیق (suspend) گره و زمان خاموش شدن گره. در آن زمان، گره باید آماده باشد تا در صورت نیاز به کار جدید، درخواست ازسرگیری (resume) برای آن صادر شود. مقدار پیش‌فرض ۳۰ ثانیه است.
پارامترهای اختیاری برای پلاگین سوییچ (switch plugin).

در سیستم‌های HPE Slingshot که با SwitchType=switch/hpe_slingshot پیکربندی شده‌اند، پارامترهای زیر پشتیبانی می‌شوند (چندین پارامتر را با ویرگول از هم جدا کنید):

محدوده VNIها جهت تخصیص به کارها و برنامه‌ها. مقدار پیش‌فرض 1024-65535 است.
پیکربندی تعداد دفعاتی که تخریب (destroying) سرویس‌های CXI در پایان گام دوباره امتحان می‌شود. بین هر بار تلاش مجدد، یک ثانیه مکث وجود دارد. مقدار پیش‌فرض ۵ است.
مجموعه‌ای از کلاس‌های ترافیک (traffic classes) جهت پیکربندی برای برنامه‌ها. کلاس‌های ترافیک پشتیبانی‌شده عبارتند از DEDICATED_ACCESS، LOW_LATENCY، BULK_DATA و BEST_EFFORT. کلاس‌های ترافیک ممکن است به‌صورت TC_DEDICATED_ACCESS، TC_LOW_LATENCY، TC_BULK_DATA و TC_BEST_EFFORT نیز مشخص شوند.
در صورت تنظیم روی 'all'، یک VNI برای تمام گام‌های کاری تخصیص می‌یابد (به‌طور پیش‌فرض، هیچ VNIای برای گام‌های کاری تک‌گره‌ای تخصیص داده نمی‌شود). در صورت تنظیم روی 'user'، یک VNI برای گام‌های کاری تک‌گره‌ای با استفاده از گزینه --network=single_node_vni در srun یا متغیر محیطی SLURM_NETWORK=single_node_vni تخصیص داده می‌شود. در صورت تنظیم روی 'none' (یا در صورتی که single_node_vni تنظیم نشده باشد)، هیچ VNIای برای گام‌های کاری تک‌گره‌ای تخصیص نمی‌یابد. برای سازگاری با نسخه‌های پیشین، تنظیم single_node_vni بدون آرگومان معادل با 'all' است.
در صورت تنظیم روی 'all'، یک VNI اضافی برای کارها تخصیص می‌یابد که بین تمام گام‌های کاری مشترک است. در صورت تنظیم روی 'user'، یک VNI اضافی برای هر کاری که از گزینه --network=job_vni در srun یا متغیر محیطی SLURM_NETWORK=job_vni استفاده کند، تخصیص داده می‌شود. در صورت تنظیم روی 'none' (یا در صورتی که job_vni تنظیم نشده باشد)، هیچ VNI اضافی برای کارها تخصیص نمی‌یابد. برای سازگاری با نسخه‌های پیشین، تنظیم job_vni بدون آرگومان معادل با 'all' است.
در صورت تنظیم، slurmd با گرفتن حداکثر مقدار منبع به ازای هر کارت شبکه (NIC) و کم کردن مقادیر رزروشده یا استفاده‌شده (هر کدام که بیشتر باشد) برای هر یک از سرویس‌های شبکه سیستم، یک حد بالا برای رزرو منابع شبکه تعیین می‌کند؛ این مقدار پیش‌فرض است.
در صورت تنظیم، slurmd رزرو منابع شبکه را صرفاً بر اساس پیش‌فرض پیکربندی به ازای هر منبع و تعداد وظایف در برنامه محاسبه می‌کند؛ این پارامتر بر اساس مصرف منابع سرویس‌های شبکه سیستمی از قبل موجود، حد بالایی برای آن درخواست‌های رزرو تعیین نمی‌کند. تنظیم این گزینه به این معنی است که اجرای برنامه‌های بیشتری ممکن است به دلیل اتمام منابع شبکه با شکست مواجه شود، اما اگر برنامه برای کارکرد خود قطعاً به مقدار مشخصی از منابع نیاز داشته باشد، این گزینه آن را تضمین می‌کند.
تعداد آدرس‌های چندپخشی (multicast) سخت‌افزاری جمعی (hardware collectives) در Slingshot جهت تخصیص به ازای هر کار (کارهایی که بزرگ‌تر از گره‌های hwcoll_min_nodes هستند).
حداقل تعداد گره‌ها برای یک کار تا بتواند عملیات جمعی سخت‌افزاری Slingshot به آن اختصاص یابد؛ زیرا انتظار نمی‌رود موتور عملیات جمعی سخت‌افزاری بهبود عملکرد چشمگیری برای کارهایی که تعداد کمی گره را در بر می‌گیرند ارائه دهد.
در صورت تنظیم، اسلورم از URL پیکربندی‌شده برای ارتباط با fabric manager جهت فعال‌سازی عملیات جمعی سخت‌افزاری Slingshot استفاده می‌کند. توجه داشته باشید که برای اجرای عملیات جمعی سخت‌افزاری باید enable_stepmgr تنظیم شده باشد.
نوع احراز هویت REST API مدیریت فابریک HPE (BASIC یا OAUTH، پیش‌فرض OAUTH).
دایرکتوری حاوی فایل‌های اطلاعات احراز هویت (پیش‌فرض /etc/fmsim برای احراز هویت BASIC، و /etc/wlm-client-auth برای احراز هویت OAUTH).
دایرکتوری حاوی فایل‌های اطلاعات احراز هویت که slurmctld استفاده خواهد کرد. مقدار پیش‌فرض آن برابر با مقدار fm_authdir است.
این پارامتر یک URL جایگزین برای fm_url تعیین می‌کند که دیمن‌های اسلورم هنگام فعال بودن احراز هویت mTLS، از آن برای ارتباط با fabric manager جهت فعال‌سازی عملیات جمعی سخت‌افزاری Slingshot استفاده می‌کنند. در صورت عدم تنظیم، به‌جای آن از fm_url استفاده خواهد شد. برای فعال‌سازی احراز هویت mTLS، به fm_mtls_ca، fm_mtls_cert و fm_mtls_key مراجعه کنید.

Note: تنظیم fm_url و enable_stepmgr برای فعال‌سازی عملیات جمعی سخت‌افزاری Slingshot الزامی است.

مسیر فایل بسته مرجع صدور گواهی (CA bundle) یا دایرکتوری حاوی فایلی که با گواهی fabric manager امضا شده است. در صورت تنظیم، در صورت فعال بودن عملیات جمعی سخت‌افزاری Slingshot، هویت سرور fabric manager اعتبارسنجی خواهد شد. همچنین fm_mtls_cert و fm_mtls_key را ببینید.

Note: این گزینه برای فعال‌سازی احراز هویت mTLS با fabric manager الزامی نیست. با این حال، بدون آن، کلاینت (فرایندهای slurmctld و stepmgr) قادر به تأیید هویت سرور نخواهد بود.

مسیر گواهی عمومی (public certificate) کلاینت. این برای فعال‌سازی احراز هویت mTLS با fabric manager هنگامی که عملیات جمعی سخت‌افزاری Slingshot فعال است الزامی می‌باشد. همچنین fm_mtls_ca و fm_mtls_key را ببینید.
مسیر کلید خصوصی (private key) کلاینت. این برای فعال‌سازی احراز هویت mTLS با fabric manager هنگامی که عملیات جمعی سخت‌افزاری Slingshot فعال است الزامی می‌باشد. همچنین fm_mtls_ca و fm_mtls_cert را ببینید.
تعداد پیش‌فرض کارت‌های شبکه (NIC) که کاربران وظایف خود را به‌طور مساوی روی آن‌ها توزیع می‌کنند. کاربران می‌توانند این مقدار را با استفاده از گزینه --network=nic_distribution_count=<val> یا متغیر محیطی SLURM_NETWORK=nic_distribution_count=<val> لغو و بازنویسی کنند. مقدار پیش‌فرض برابر با تعداد NICها در هر گره است.
تخصیص رزروشده به ازای هر CPU برای این منبع.
تخصیص رزروشده به ازای هر گره برای این منبع. در صورت تنظیم، تخصیص به ازای هر CPU را بازنویسی می‌کند.
حداکثر تخصیص برنامه به ازای هر گره برای این منبع.

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

صف‌های دستور ارسال (Transmit command queues). پیش‌فرض ۲ به ازای هر CPU، حداکثر ۱۰۲۴ به ازای هر گره.
صف‌های دستور هدف (Target command queues). پیش‌فرض ۱ به ازای هر CPU، حداکثر ۵۱۲ به ازای هر گره.
صف‌های رویداد (Event queues). پیش‌فرض ۲ به ازای هر CPU، حداکثر ۲۰۴۷ به ازای هر گره.
شمارنده‌ها (Counters). پیش‌فرض ۱ به ازای هر CPU، حداکثر ۲۰۴۷ به ازای هر گره.
ورودی‌های فهرست راه‌انداز (Trigger list entries). پیش‌فرض ۱ به ازای هر CPU، حداکثر ۲۰۴۸ به ازای هر گره.
ورودی‌های جدول قابل‌حمل (Portable table entries). پیش‌فرض ۶ به ازای هر CPU، حداکثر ۲۰۴۸ به ازای هر گره.
ورودی‌های فهرست (List entries). پیش‌فرض ۱۶ به ازای هر CPU، حداکثر ۱۶۳۸۴ به ازای هر گره.
زمینه‌های آدرس‌دهی (Addressing contexts). پیش‌فرض ۲ به ازای هر CPU، حداکثر ۱۰۲۲ به ازای هر گره.

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

تعداد کانال‌هایی که می‌توان پیکربندی کرد. کانال‌ها به گره‌ها اجازه می‌دهند تا روشی امن برای اشتراک‌گذاری حافظه ایجاد کنند. مقدار پیش‌فرض ۲۰۴۸ است.

به‌طور پیش‌فرض، به هر کار یک کانال IMEX تخصیص داده می‌شود که توسط گام‌های کاری دسته‌ای (batch)، تعاملی (interactive) و عادی روی تمام گره‌های درون آن کار قابل دسترسی است. در صورت استفاده از --network=unique-channel-per-segment هنگام ارسال کار و پیکربندی بودن topology/block، به هر سگمنت یک کانال IMEX اختصاص می‌یابد که توسط گام‌های کاری دسته‌ای، تعاملی و عادی روی تمام گره‌های درون آن سگمنت خاص قابل دسترسی است.

نوع سوییچ یا اینترکانکت (interconnect) مورد استفاده برای ارتباطات برنامه‌های کاربردی را مشخص می‌کند. مقدار پیش‌فرض هیچ پلاگین خاصی نیست که نیازمند پردازش ویژه برای راه‌اندازی یا خاتمه کار باشد (Ethernet و InfiniBand). تمام دیمن‌های Slurm، دستورات و کارهای در حال اجرا برای اعمال تغییرات در SwitchType باید مجدداً راه‌اندازی یا بازپیکربندی شوند. اگر در زمانی که slurmctld با مقدار جدیدی از SwitchType مجدداً راه‌اندازی می‌شود، کارهای در حال اجرا وجود داشته باشند، ممکن است سوابق تمام کارها در هر وضعیتی از بین بروند. مقادیر قابل قبول عبارتند از:
برای سیستم‌های HPE Slingshot.
برای تخصیص کانال‌های منحصربه‌فرد در یک دامنه NVIDIA IMEX.
نام مسیر برنامه‌ای که باید به عنوان کاربر کار پس از خاتمه هر وظیفه (task) اجرا شود. اگر یک نام مسیر مطلق نباشد (یعنی با اسلش شروع نشود)، باید نسبت به دایرکتوری حاوی فایل slurm.conf باشد. در صورت پیکربندی، داخل کانتینر کار اجرا خواهد شد. نباید برای اعمال خط‌مشی استفاده شود. برای جزئیات ترتیب اجرا به TaskProlog مراجعه کنید.
نوع پلاگین راه‌اندازی وظیفه را مشخص می‌کند، که معمولاً برای ارائه مدیریت منابع در یک گره استفاده می‌شود (به عنوان مثال پین کردن وظایف به پردازنده‌های خاص). بیش از یک پلاگین وظیفه را می‌توان در یک فهرست جداشده با ویرگول مشخص کرد. پیشوند "task/" اختیاری است. به‌طور پیش‌فرض تنظیم نشده است. مقادیر قابل قبول عبارتند از:
با استفاده از ()sched_setaffinity، فرآیندها را به منابع مشخص‌شده متصل (bind) می‌کند. این گزینه، گزینه‌های --cpu-bind و/یا --mem-bind در srun را فعال می‌کند.
محدودسازی فرآیند به منابع مشخص‌شده را با استفاده از رابط cpuset در Cgroups فعال می‌کند. این گزینه، گزینه‌های --cpu-bind و/یا --mem-bind در srun را فعال می‌کند. NOTE: برای جزئیات پیکربندی به "man cgroup.conf" مراجعه کنید.
NOTE: توصیه می‌شود هنگام پیکربندی TaskPlugin، موارد task/cgroup,task/affinity را با هم ترکیب (stack) کرده و ConstrainCores=yes را در cgroup.conf تنظیم کنید. این پیکربندی از پلاگین task/affinity برای تنظیم ماسک cpu برای وظایف و از پلاگین task/cgroup برای محصور کردن وظایف در cpuهای تخصیص‌یافته استفاده می‌کند.
پارامترهای اختیاری برای پلاگین وظیفه. گزینه‌های متعدد باید با ویرگول جدا شوند. گزینه‌های None، Sockets، Cores و Threads مانعة‌الجمع هستند و به عنوان آخرین منبع ممکن برای مقدار پیش‌فرض --cpu-bind در نظر گرفته می‌شوند. همچنین به گزینه‌های CpuBind مربوط به Node و Partition مراجعه کنید.
اتصال وظایف به هسته‌ها به‌طور پیش‌فرض. اتصال خودکار را لغو (override) می‌کند.
عدم انجام اتصال وظیفه به‌طور پیش‌فرض. اتصال خودکار را لغو می‌کند.
اتصال به سوکت‌ها به‌طور پیش‌فرض. اتصال خودکار را لغو می‌کند.
اتصال به ریسه‌ها (threads) به‌طور پیش‌فرض. اتصال خودکار را لغو می‌کند.
اگر slurmd در یک cgroup راه‌اندازی شود که دارای محدودیت‌های cpuset یا حافظه باشد، آنگاه CpuSpecList و MemSpecLimit تنظیم خواهند شد و مقادیر پیکربندی‌شده را بازنویسی (override) خواهند کرد. این کار از زمان‌بندی منابع حاصل از این محدودیت‌ها جلوگیری می‌کند. در cgroup/v1، دیمن‌های slurmd و slurmstepd دیگر قادر به استفاده از هیچ‌یک از این منابع نخواهند بود، در حالی که در رفتار عادی، cgroup/v1 دیمن‌ها را به CpuSpecList و MemSpecLimit محدود می‌کند.
اگر هسته‌ها یا CPUهای تخصصی برای گره مشخص شده باشند (یعنی CoreSpecCount یا CpuSpecList برای گره پیکربندی شده باشند)، آنگاه دیمن‌های Slurm در حال اجرا روی گره محاسباتی (یعنی slurmd و slurmstepd) باید خارج از آن منابع اجرا شوند (یعنی منابع تخصصی کاملاً برای دیمن‌های Slurm و کارهای ایجادشده توسط Slurm غیرقابل دسترس هستند).
این پارامتر را تنظیم کنید تا در صورتی که یک رخداد OOM در هر وظیفه‌ای از گام کاری رخ دهد، کل گام در تمام گره‌ها متوقف (kill) شود.

این مورد برای کل تخصیص‌ها اعمال می‌شود اما برای گام خارجی (external step) اعمال نمی‌شود. می‌تواند توسط کاربر بازنویسی شود.

NOTE: این پارامتر به پلاگین task/cgroup، Cgroups v2 و یک هسته جدیدتر از 4.19 نیاز دارد.

گزارش مشروح اتصال قبل از اجرای وظایف به‌طور پیش‌فرض.
تنظیم یک اتصال پیش‌فرض در صورتی که "اتصال خودکار" (auto binding) تطابقی پیدا نکند. به Threads، Cores یا Sockets تنظیم می‌شود (مانند TaskPluginParam=autobind=threads).
نام مسیر برنامه‌ای که باید به عنوان کاربر کار قبل از شروع هر وظیفه اجرا شود. اگر یک نام مسیر مطلق نباشد (یعنی با اسلش شروع نشود)، باید نسبت به دایرکتوری حاوی فایل slurm.conf باشد. در صورت پیکربندی، داخل کانتینر کار اجرا خواهد شد. نباید برای اعمال خط‌مشی استفاده شود. علاوه بر متغیرهای محیطی معمولی، این برنامه دارای SLURM_TASK_PID است تا شناسه فرآیند (PID) وظیفه‌ای را که در حال شروع است مشخص کند. خروجی استاندارد این برنامه می‌تواند برای کنترل متغیرهای محیطی و خروجی برنامه کاربر استفاده شود.
متغیرهای محیطی را برای وظیفه‌ای که ایجاد می‌شود تنظیم می‌کند. هر چیزی بعد از علامت مساوی تا انتهای خط به عنوان مقدار متغیر محیطی استفاده خواهد شد. صادر کردن توابع (exporting of functions) در حال حاضر پشتیبانی نمی‌شود.
باعث می‌شود که آن خط (بدون "print " اولیه) در خروجی استاندارد کار چاپ شود.
متغیرهای محیطی را برای وظیفه‌ای که ایجاد می‌شود پاک می‌کند.
ترتیب اجرای پرولوگ/اپیلوگ وظیفه (task prolog/epilog) به شرح زیر است:
1. pre_launch_priv()
تابع در TaskPlugin
1. pre_launch()
تابع در TaskPlugin
2. TaskProlog
برنامه به ازای هر وظیفه در سطح کل سیستم، تعریف‌شده در slurm.conf
3. User prolog
برنامه وظیفه مختص به گام کار، تعریف‌شده با استفاده از گزینه --task-prolog در srun یا متغیر محیطی SLURM_TASK_PROLOG
4. Task
اجرای وظیفه گام کار
5. User epilog
برنامه وظیفه مختص به گام کار، تعریف‌شده با استفاده از گزینه --task-epilog در srun یا متغیر محیطی SLURM_TASK_EPILOG
6. TaskEpilog
برنامه به ازای هر وظیفه در سطح کل سیستم، تعریف‌شده در slurm.conf
7. post_term()
تابع در TaskPlugin
زمان مجاز برای برقراری اتصال TCP. مقدار پیش‌فرض ۲ ثانیه است.
گزینه‌های جداشده با ویرگول برای پلاگین TLS پیکربندی‌شده توسط TLSType. مقادیر پشتیبانی‌شده عبارتند از:
مسیر گواهی مرجع صدور گواهی (CA). باید روی همه میزبان‌ها وجود داشته باشد و برای تمام اجزای Slurm قابل دسترسی باشد. مجوزهای دسترسی فایل باید 644 باشد و مالکیت آن متعلق به SlurmUser/root باشد.

مسیر پیش‌فرض "ca_cert.pem" در دایرکتوری پیکربندی Slurm است

مسیر گواهی مورد استفاده توسط slurmctld. باید به ca_cert_file زنجیره شود. فقط باید روی میزبانی که slurmctld را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "ctld_cert.pem" در دایرکتوری پیکربندی Slurm است

مسیر کلید خصوصی همراه با ctld_cert_file. فقط باید روی میزبانی که slurmctld را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "ctld_cert_key.pem" در دایرکتوری پیکربندی Slurm است

مسیر گواهی مورد استفاده توسط slurmrestd. باید به ca_cert_file زنجیره شود. فقط باید روی میزبانی که slurmrestd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به کاربری باشد که slurmrestd را اجرا می‌کند.

مسیر پیش‌فرض "restd_cert.pem" در دایرکتوری پیکربندی Slurm است

مسیر کلید خصوصی همراه با restd_cert_file. فقط باید روی میزبانی که slurmrestd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به کاربری باشد که slurmrestd را اجرا می‌کند.

مسیر پیش‌فرض "restd_cert_key.pem" در دایرکتوری پیکربندی Slurm است

مسیر گواهی مورد استفاده توسط sackd. باید به ca_cert_file زنجیره شود. فقط باید روی میزبانی که sackd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "sackd_cert.pem" در دایرکتوری پیکربندی Slurm است

NOTE: در صورت عدم استفاده از پلاگین certmgr، این فایل باید وجود داشته باشد.

مسیر کلید خصوصی همراه با sackd_cert_file. فقط باید روی میزبانی که sackd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "sackd_cert_key.pem" در دایرکتوری پیکربندی Slurm است

NOTE: در صورت عدم استفاده از پلاگین certmgr، این فایل باید وجود داشته باشد.

مسیر گواهی مورد استفاده توسط slurmd. باید به ca_cert_file زنجیره شود. فقط باید روی میزبانی که slurmd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "slurmd_cert.pem" در دایرکتوری پیکربندی Slurm است

NOTE: در صورت عدم استفاده از پلاگین certmgr، این فایل باید وجود داشته باشد.

مسیر کلید خصوصی همراه با slurmd_cert_file. فقط باید روی میزبانی که slurmd را اجرا می‌کند وجود داشته باشد. مجوزهای دسترسی فایل باید 600 باشد و مالکیت آن متعلق به SlurmUser باشد.

مسیر پیش‌فرض "slurmd_cert_key.pem" در دایرکتوری پیکربندی Slurm است

NOTE: در صورت عدم استفاده از پلاگین certmgr، این فایل باید وجود داشته باشد.

بارگذاری گواهی‌های یافت‌شده در مکان‌های پیش‌فرض سیستم (مانند /etc/ssl) در مخزن اعتماد (trust store).

حالت پیش‌فرض عدم بارگذاری گواهی‌های سیستم و اتکای صرف به ca_cert_file برای برقراری اعتماد است.

نسخه خط‌مشی امنیتی مورد استفاده توسط s2n. برای جزئیات بیشتر به مستندات s2n مراجعه کنید. خط‌مشی امنیتی پیش‌فرض "20230317" است که سازگار با FIPS بوده و شامل TLS 1.3 می‌شود.
پیاده‌سازی TLS مورد استفاده را مشخص می‌کند. هنگامی که روی یک پلاگین TLS تنظیم شود، سوکت‌های شنود RPC اتصالاتی را که با TLS پوشش داده نشده‌اند رد می‌کنند. برای جزئیات بیشتر به راهنمای TLS مراجعه کنید: https://slurm.schedmd.com/tls.html مقدار پیش‌فرض tls/none است.
مقادیر قابل قبول در حال حاضر عبارتند از:
بدون TLS. این مقدار پیش‌فرض است.
استفاده از پلاگین TLS مبتنی بر s2n. نیازمند پیکربندی بیشتر است و بار پردازشی قابل توجهی ایجاد می‌کند، اما امکان رمزنگاری تمام ارتباطات Slurm را فراهم می‌سازد.
نام مسیر کاملاً واجد شرایط فایل سیستمی که برای ذخیره‌سازی موقت در دسترس کارهای کاربر قرار دارد. این پارامتر در تعیین فضای TmpDisk یک گره استفاده می‌شود. مقدار پیش‌فرض "/tmp" است.
گزینه‌های جداشده با ویرگول برای مشخص کردن گزینه‌های توپولوژی شبکه.
بهینه‌سازی تخصیص برای شبکه Dragonfly. هنگامی معتبر است که TopologyPlugin=topology/tree باشد.
به جای استفاده از محاسبه مسیر پیش‌فرض پلاگین، از فهرست گره‌های پارتیشن برای مسیریابی ارتباطات از سمت کنترل‌کننده استفاده می‌کند. پس از رسیدن به گره محاسباتی، ارتباطات با استفاده از الگوریتم عادی پلاگین درخواستی، و با رعایت TreeWidth در صورت کاربرد، مسیریابی خواهند شد. اگر گره‌ای در چندین پارتیشن باشد، اولین پارتیشن مشاهده‌شده استفاده خواهد شد. کنترل‌کننده مستقیماً با گره‌هایی که در هیچ پارتیشنی نیستند ارتباط برقرار خواهد کرد.
اختصاص رتبه گره (node rank) یکسان به تمام گره‌های تحت یک بلوک پایه (base block). این گزینه در صورتی که قرارداد نام‌گذاری گره‌ها با توپولوژی شبکه مطابقت نداشته باشد می‌تواند مفید باشد. هنگامی معتبر است که topology/block یک توپولوژی پیش‌فرض کلاستر باشد.
اختصاص رتبه گره یکسان به تمام گره‌های تحت یک سوییچ برگ (leaf switch). این گزینه در صورتی که قرارداد نام‌گذاری گره‌ها با توپولوژی شبکه مطابقت نداشته باشد می‌تواند مفید باشد. هنگامی معتبر است که topology/tree یک توپولوژی پیش‌فرض کلاستر باشد.
استفاده از سلسله‌مراتب سوییچ تعریف‌شده در یک فایل topology.conf برای مسیریابی به جای استفاده صرف برای زمان‌بندی. هنگامی معتبر است که TopologyPlugin=topology/tree باشد. ناسازگار با گره‌های پویا (dynamic nodes).
پیش‌فرض: -1 (گزینه غیرفعال است). هنگامی معتبر است که TopologyPlugin=topology/block باشد.
تنها در صورتی تخصیص را برای توپولوژی شبکه بهینه‌سازی می‌کند که کار شامل یک گزینه switch باشد. از آنجا که بهینه‌سازی تخصیص منابع برای توپولوژی مستلزم سربار سیستمی بسیار بالاتری است، این گزینه می‌تواند برای تحمیل سربار اضافی صرفاً بر کارهایی استفاده شود که می‌توانند از آن بهره‌مند شوند. اگر اکثر تخصیص‌های کاری برای توپولوژی شبکه بهینه‌سازی نشوند، ممکن است منابع را تا حدی تکه‌تکه (fragment) کنند که دستیابی به بهینه‌سازی توپولوژی برای کارهای دیگر دشوار شود. NOTE: با فعال بودن این گزینه، کارها ممکن است در سراسر گره‌های بدون سوییچ والد مشترک گسترش یابند.
پلاگین مورد استفاده برای تعیین توپولوژی شبکه و بهینه‌سازی تخصیص‌های کار را جهت به حداقل رساندن تداخل شبکه (network contention) مشخص می‌کند. برای جزئیات بیشتر به بخش NETWORK TOPOLOGY در ادامه مراجعه کنید. پلاگین‌های بیشتری ممکن است در آینده ارائه شوند که اطلاعات توپولوژی را مستقیماً از شبکه جمع‌آوری کنند. مقادیر قابل قبول عبارتند از:
برای یک توپولوژی شبکه بلوکی استفاده می‌شود، همان‌طور که در صفحه راهنمای topology.conf(5) شرح داده شده است.
منطق بهترین برازش (best-fit) روی توپولوژی یک‌بعدی. این مقدار پیش‌فرض است.
برای یک شبکه سلسله‌مراتبی با پلاگین select/cons_tres استفاده می‌شود، همان‌طور که در صفحه راهنمای topology.conf(5) شرح داده شده است.
NOTE: اگر topology.yaml وجود داشته باشد، این گزینه نادیده گرفته می‌شود.
بولین yes یا no. برای تنظیم نمایش و رهگیری کلید مشخص‌سازی حجم کاری (Workload Characterization Key یا WCKey) استفاده می‌شود. برای رهگیری صحیح استفاده از wckey باید تنظیم شود. NOTE: شما همچنین باید TrackWCKey را در فایل slurmdbd.conf خود تنظیم کنید تا گزارش‌های استفاده تاریخی ایجاد شود.
دیمن‌های Slurmd از یک شبکه درختی مجازی برای ارتباطات استفاده می‌کنند. TreeWidth پهنای درخت (یعنی ضریب انشعاب یا fanout) را مشخص می‌کند. مقدار پیش‌فرض 16 است، به این معنی که هر دیمن slurmd می‌تواند با حداکثر 16 دیمن slurmd دیگر ارتباط برقرار کند. این مقدار، تعادلی بین کاهش بار slurmctld (حداکثر 16 ریسه در حال اجرا)، زمان ارتباط و تحمل خطای گره برقرار می‌کند (4368 گره می‌توانند با سه جهش پیامی [message hops] مورد تماس قرار گیرند). مقدار پیش‌فرض برای اکثر کلاسترها به خوبی کار خواهد کرد؛ با این حال در سیستم‌های بزرگ‌تر این مقدار می‌تواند افزایش یابد تا از مهلت‌های زمانی طولانی و ارسال‌های مجدد در صورت وجود گره‌های پاسخ‌نداده جلوگیری شود. مقدار نباید از 65533 تجاوز کند.
اگر فرآیندهای موجود در یک گام کار برای مدت زمانی که توسط متغیر UnkillableStepTimeout مشخص شده است غیرقابل توقف (unkillable) تشخیص داده شوند، برنامه‌ای که توسط UnkillableStepProgram مشخص شده است اجرا خواهد شد. به‌طور پیش‌فرض هیچ برنامه‌ای اجرا نمی‌شود.

برای اطلاعات بیشتر به بخش UNKILLABLE STEP PROGRAM SCRIPT مراجعه کنید.

مدت زمانی، بر حسب ثانیه، که Slurm قبل از تصمیم‌گیری در مورد اینکه فرآیندهای یک گام کار غیرقابل توقف هستند (پس از اینکه به آن‌ها سیگنال SIGKILL ارسال شد) و اجرای UnkillableStepProgram منتظر خواهد ماند. مقدار پیش‌فرض مهلت زمانی 60 ثانیه یا پنج برابر مقدار MessageTimeout است، هر کدام که بزرگ‌تر باشد. در صورت فراتر رفتن، گره محاسباتی تخلیه (drain) خواهد شد تا از زمان‌بندی کارهای بعدی روی آن گره جلوگیری شود.

NOTE: اطمینان حاصل کنید که UnkillableStepTimeout حداقل 5 برابر بزرگ‌تر از MessageTimeout باشد، در غیر این صورت می‌تواند منجر به تخلیه غیرمنتظره گره‌ها شود.

پیاده‌سازی url_parser مورد استفاده را مشخص می‌کند. پیش‌فرض در صورت یافت شدن url_parser/libhttp_parser است، در غیر این صورت url_parser/internal. مقادیر قابل قبول در حال حاضر عبارتند از:
استفاده از پلاگین مبتنی بر libhttp_parser.
استفاده از پلاگین پارسر URL داخلی Slurm.

Note: هنگامی که HttpParserType=http_parser/llhttp_parser باشد، الزامی است.

اگر روی 1 تنظیم شود، PAM (ماژول‌های احراز هویت قابل اتصال برای لینوکس) فعال خواهد شد. از PAM برای تعیین مرزهای بالایی محدودیت‌های منابع استفاده می‌شود. با فعال بودن پشتیبانی PAM، مدیران سیستم محلی می‌توانند محدودیت‌های منابع سیستم را به‌طور پویا پیکربندی کنند. تغییر حد بالایی یک محدودیت منبع، محدودیت‌های کارهای در حال اجرا را تغییر نخواهد داد و فقط کارهایی که پس از اعمال تغییر شروع شده‌اند، محدودیت‌های جدید را دریافت خواهند کرد. مقدار پیش‌فرض 0 است (عدم فعال‌سازی پشتیبانی PAM). به یاد داشته باشید که PAM همچنین باید برای پشتیبانی از Slurm به عنوان یک سرویس پیکربندی شود. برای سایت‌هایی که از گزینه پیکربندی مبتنی بر دایرکتوری در PAM استفاده می‌کنند، یک فایل پیکربندی با نام slurm باید ایجاد شود. نام‌های module-type، control-flags و module-path که باید در فایل گنجانده شوند عبارتند از:
auth required pam_localuser.so
auth required pam_shells.so
account required pam_unix.so
account required pam_access.so
session required pam_unix.so
برای سایت‌هایی که PAM را با یک فایل پیکربندی عمومی پیکربندی می‌کنند، خطوط مناسب (بالا را ببینید)، که در آن slurm نام سرویس (service-name) است، باید اضافه شوند. برای جزئیات بیشتر به https://slurm.schedmd.com/pam_slurm_adopt.html مراجعه کنید.

NOTE: گزینه UsePAM هیچ ارتباطی با ماژول‌های contribs/pam/pam_slurm و/یا contribs/pam_slurm_adopt ندارد. بنابراین این دو ماژول می‌توانند مستقل از مقدار تنظیم‌شده برای UsePAM کار کنند.

مشخصات حافظه در درخواست‌های کار برای اندازه حافظه واقعی (که به عنوان resident set size نیز شناخته می‌شود) اعمال می‌شود. اعمال محدودیت‌های حافظه مجازی هم برای کارها و هم برای گام‌های کار از طریق محدود کردن حافظه مجازی آن‌ها به درصدی از تخصیص حافظه واقعی آن‌ها امکان‌پذیر است. پارامتر VSizeFactor محدودیت حافظه مجازی کار یا گام کار را به عنوان درصدی از محدودیت حافظه واقعی آن مشخص می‌کند. به عنوان مثال، اگر محدودیت حافظه واقعی یک کار 500MiB باشد و VSizeFactor روی 101 تنظیم شود، در صورتی که حافظه واقعی کار از 500MiB یا حافظه مجازی آن از 505MiB (101 درصد از محدودیت حافظه واقعی) فراتر رود، کار متوقف (kill) خواهد شد. مقدار پیش‌فرض 0 است که اعمال محدودیت‌های حافظه مجازی را غیرفعال می‌کند. مقدار نباید از 65533 درصد تجاوز کند.

NOTE: این پارامتر به پیکربندی OverMemoryKill در JobAcctGatherParams وابسته است. همچنین امکان پیکربندی TaskPlugin برای استفاده از task/cgroup جهت اعمال محدودیت حافظه وجود دارد. VSizeFactor بر اعمال محدودیت حافظه انجام‌شده از طریق cgroups تأثیری نخواهد داشت.

مشخص می‌کند که دستور srun به‌طور پیش‌فرض چند ثانیه پس از پایان یافتن اولین وظیفه، قبل از خاتمه دادن به تمام وظایف باقی‌مانده باید منتظر بماند. گزینه "--wait" در خط فرمان srun این مقدار را لغو (override) می‌کند. مقدار پیش‌فرض 0 است که این ویژگی را غیرفعال می‌کند. نباید از 65533 ثانیه تجاوز کند.
برای استفاده با پیاده‌سازی بازفرواردی توکار (built-in) X11 در Slurm.
در صورت تنظیم، داده‌های xauth در گره محاسباتی به جای یک فایل موقت در زیر TmpFS، در ~/.Xauthority قرار خواهند گرفت.

پیکربندی گره‌ها (یا ماشین‌ها) که قرار است توسط Slurm مدیریت شوند نیز در /etc/slurm.conf مشخص می‌شود. تغییرات در پیکربندی گره (مانند افزودن گره‌ها، تغییر تعداد پردازنده‌های آن‌ها و غیره) نیازمند راه‌اندازی مجدد یا بازپیکربندی تمام دیمن‌های slurmctld و slurmd است. تمام دیمن‌های slurmd باید هر گره در سیستم را بشناسند تا پیام‌ها را در پشتیبانی از ارتباطات سلسله‌مراتبی فوروارد کنند. فقط NodeName باید در فایل پیکربندی ارائه شود. تمام اطلاعات دیگر پیکربندی گره اختیاری هستند. تعیین پیکربندی‌های پایه (baseline node configurations) توصیه می‌شود، به‌ویژه اگر کلاستر ناهمگن (heterogeneous) باشد. گره‌هایی که با منابعی کمتر از منابع پیکربندی‌شده (مثلاً حافظه خیلی کم) در سیستم ثبت‌نام می‌کنند، در وضعیت "DOWN" قرار خواهند گرفت تا از زمان‌بندی کارها روی آن‌ها جلوگیری شود. تعیین پیکربندی‌های پایه همچنین روند زمان‌بندی Slurm را با امکان مقایسه نیازمندی‌های کار در برابر این پارامترهای پیکربندی (نسبتاً اندک) تسریع می‌کند و احتمالاً از نیاز به بررسی نیازمندی‌های کار در برابر پیکربندی هر گره به‌صورت جداگانه جلوگیری می‌نماید. منابعی که در زمان ثبت‌نام گره بررسی می‌شوند عبارتند از: CPUs، RealMemory و TmpDisk.

مقادیر پیش‌فرض را می‌توان با رکوردی مشخص کرد که در آن NodeName برابر با "DEFAULT" باشد. مقادیر ورودی پیش‌فرض فقط برای خطوط بعد از آن در فایل پیکربندی اعمال می‌شوند و مقادیر پیش‌فرض را می‌توان چندین بار در فایل پیکربندی با چندین ورودی که در آن‌ها "NodeName=DEFAULT" است بازنشانی کرد. هر خطی که در آن NodeName برابر با "DEFAULT" باشد، مقادیر پیش‌فرض قبلی را جایگزین کرده یا به آن‌ها اضافه می‌کند و مقادیر پیش‌فرض را مجدداً مقداردهی اولیه نمی‌کند. مشخصه "NodeName=" باید در هر خطی که پیکربندی گره‌ها را شرح می‌دهد قرار گیرد. نام یک گره واحد نمی‌تواند به عنوان مقدار NodeName در بیش از یک خط ظاهر شود (رکوردهای تکراری نام گره نادیده گرفته خواهند شد). در واقع، به‌طور کلی تعریف پیکربندی تمام گره‌ها تنها در چند خط امکان‌پذیر و مطلوب است. این قرارداد امکان بهینه‌سازی قابل توجهی را در زمان‌بندی کلاسترهای بزرگ‌تر فراهم می‌کند. به منظور پشتیبانی از مفهوم کارهایی که در برخی معماری‌ها به گره‌های متوالی نیاز دارند، مشخصات گره‌ها باید به ترتیب متوالی در این فایل قرار گیرند. هیچ نام گره واحدی نباید بیش از یک بار در فایل پیکربندی فهرست شود. از "DownNodes=" برای ثبت وضعیت گره‌هایی که موقتاً در وضعیت DOWN، DRAIN یا FAILING هستند بدون تغییر اطلاعات پیکربندی دائمی استفاده کنید. وظایف یک گام کار به ترتیبی که گره‌ها در فایل پیکربندی ظاهر می‌شوند، به گره‌ها تخصیص می‌یابند. در حال حاضر هیچ قابلیتی در Slurm برای مرتب‌سازی دلخواه وظایف یک گام کار وجود ندارد.

چندین نام گره می‌توانند با ویرگول جدا شوند (مانند "alpha,beta,gamma") و/یا می‌توان از یک عبارت محدوده گره ساده به صورت اختیاری برای تعیین محدوده‌های عددی گره‌ها استفاده کرد تا از ایجاد یک فایل پیکربندی با تعداد زیادی ورودی جلوگیری شود. عبارت محدوده گره می‌تواند شامل یک یا چند جفت براکت باشد که دنباله‌ای از اعداد جداشده با ویرگول و/یا محدوده‌هایی از اعداد جداشده با "-" دارند (مانند "linux[0-64,128]"، "lx[15,18,32-33]" یا "rack[0-63]_blade[0-41]"). توجه داشته باشید که محدوده‌های عددی می‌توانند شامل یک یا چند صفر ابتدایی باشند تا نشان دهند که بخش عددی دارای تعداد ثابتی از ارقام است (مانند "linux[0000-1023]").

پیکربندی گره اطلاعات زیر را مشخص می‌کند:

نامی که Slurm برای اشاره به یک گره استفاده می‌کند. معمولاً این رشته‌ای است که "/bin/hostname -s" برمی‌گرداند. همچنین ممکن است نام دامنه کاملاً واجد شرایط (FQDN) باشد که توسط "/bin/hostname -f" برمی‌گردد (مانند "foo1.bar.com")، یا هر نام دامنه معتبر مرتبط با میزبان از طریق پایگاه داده میزبان (/etc/hosts) یا DNS، بسته به تنظیمات تحلیل‌کننده (resolver). توجه داشته باشید که اگر از فرم کوتاه نام میزبان استفاده نشود، ممکن است از استفاده از عبارات hostlist جلوگیری کند (بخش عددی در براکت‌ها باید در انتهای رشته باشد). همچنین اگر NodeHostname مشخص شده باشد، می‌تواند یک رشته دلخواه باشد. اگر NodeName برابر با "DEFAULT" باشد، مقادیر مشخص‌شده با آن رکورد برای مشخصات گره‌های بعدی اعمال خواهد شد، مگر اینکه صراحتاً روی مقادیر دیگری در آن رکورد گره تنظیم شود یا با مجموعه متفاوتی از مقادیر پیش‌فرض جایگزین گردد. هر خطی که در آن NodeName برابر با "DEFAULT" باشد، مقادیر پیش‌فرض قبلی را جایگزین کرده یا به آن‌ها اضافه می‌کند و مقادیر پیش‌فرض را مجدداً مقداردهی اولیه نمی‌کند. برای معماری‌هایی که ترتیب گره در آن‌ها اهمیت دارد، گره‌ها به ترتیبی که تعریف شده‌اند متوالی در نظر گرفته می‌شوند. به عنوان مثال، اگر پیکربندی "NodeName=charlie" بلافاصله پس از پیکربندی "NodeName=baker" بیاید، آن‌ها در کامپیوتر مجاور یکدیگر در نظر گرفته خواهند شد. NOTE: اگر NodeName برابر با "ALL" باشد، فرآیند تجزیه پیکربندی بلافاصله خارج خواهد شد، زیرا این یک کلمه رزروشده داخلی است.
معمولاً این رشته‌ای است که "/bin/hostname -s" برمی‌گرداند. همچنین ممکن است نام دامنه کاملاً واجد شرایط باشد که توسط "/bin/hostname -f" برمی‌گردد (مانند "foo1.bar.com")، یا هر نام دامنه معتبر مرتبط با میزبان از طریق پایگاه داده میزبان (/etc/hosts) یا DNS، بسته به تنظیمات تحلیل‌کننده. توجه داشته باشید که اگر از فرم کوتاه نام میزبان استفاده نشود، ممکن است از استفاده از عبارات hostlist جلوگیری کند (بخش عددی در براکت‌ها باید در انتهای رشته باشد). یک عبارت محدوده گره می‌تواند برای تعیین مجموعه‌ای از گره‌ها استفاده شود. اگر از یک عبارت استفاده شود، تعداد گره‌های مشخص‌شده توسط NodeHostname در یک خط در فایل پیکربندی باید با تعداد گره‌های مشخص‌شده توسط NodeName یکسان باشد. به‌طور پیش‌فرض، NodeHostname از نظر مقدار با NodeName یکسان خواهد بود.
نامی که باید برای یک گره در برقراری مسیر ارتباطی به آن ارجاع داده شود. این نام به عنوان آرگومانی برای تابع ()getaddrinfo جهت شناسایی استفاده خواهد شد. اگر یک عبارت محدوده گره برای تعیین چندین گره استفاده شود، آن‌ها باید دقیقاً با ورودی‌های موجود در NodeName مطابقت داشته باشند (مانند "NodeName=lx[0-7] NodeAddr=elx[0-7]"). NodeAddr همچنین می‌تواند شامل آدرس‌های IP باشد. به‌طور پیش‌فرض، NodeAddr از نظر مقدار با NodeHostname یکسان خواهد بود.
مسیر شبکه جایگزین برای استفاده در ترافیک شبکه sbcast به یک گره مشخص. این نام به عنوان آرگومانی برای تابع ()getaddrinfo استفاده خواهد شد. اگر یک عبارت محدوده گره برای تعیین چندین گره استفاده شود، آن‌ها باید دقیقاً با ورودی‌های موجود در NodeName مطابقت داشته باشند (مانند "NodeName=lx[0-7] BcastAddr=elx[0-7]"). BcastAddr همچنین می‌تواند شامل آدرس‌های IP باشد. به‌طور پیش‌فرض، BcastAddr تنظیم نشده است و ترافیک sbcast به NodeAddr برای یک گره مشخص هدایت خواهد شد. توجه: نمی‌تواند همراه با CommunicationParameters=NoInAddrAny استفاده شود.
تعداد بردهای پایه (Baseboards) در گره‌های دارای کنترل‌کننده برد پایه. توجه داشته باشید که وقتی Boards مشخص می‌شود، SocketsPerBoard، CoresPerSocket و ThreadsPerCore نیز باید مشخص شوند. مقدار پیش‌فرض 1 است.
تعداد هسته‌های رزروشده برای استفاده سیستم. بسته به گزینه SlurmdOffSpec در TaskPluginParam، دیمن Slurm یعنی slurmd ممکن است به این منابع محدود شود (حالت پیش‌فرض) یا از استفاده از این منابع منع شود. اگر از cgroup/v1 استفاده شود، همین امر در مورد فرآیندهای slurmstepd نیز صدق می‌کند. جداسازی slurmd از کارهای کاربر ممکن است عملکرد برنامه را بهبود بخشد. یک کار می‌تواند از این هسته‌ها استفاده کند اگر AllowSpecResourcesUsage=yes باشد و کاربر صراحتاً مقداری کمتر از CoreSpecCount پیکربندی‌شده را درخواست کند. اگر این گزینه و CpuSpecList هر دو برای یک گره تعیین شده باشند، یک خطا ایجاد می‌شود. برای کسب اطلاعات در مورد الگوریتم استفاده‌شده توسط Slurm برای انتخاب هسته‌ها، به مستندات تخصصی‌سازی هسته در آدرس ( https://slurm.schedmd.com/core_spec.html ) مراجعه کنید.
تعداد هسته‌ها در یک سوکت پردازنده فیزیکی (مثلاً "2"). مقدار CoresPerSocket هسته‌های فیزیکی را توصیف می‌کند، نه تعداد منطقی پردازنده‌ها در هر سوکت را. NOTE: اگر پردازنده‌های چند‌هسته‌ای دارید، احتمالاً برای بهینه‌سازی زمان‌بندی نیاز به تعیین این پارامتر خواهید داشت. مقدار پیش‌فرض 1 است.
اگر درخواست گام کار (job step request) گزینه‌ای را برای کنترل نحوه اتصال وظایف به CPUهای تخصیص‌یافته تعیین نکند (با استفاده از --cpu-bind) و تمام گره‌های تخصیص‌یافته به کار دارای گزینه CpuBind یکسانی باشند، گزینه CpuBind گره کنترل خواهد کرد که وظایف چگونه به منابع تخصیص‌یافته متصل شوند. در صورتی که تعریف(های) گره قابل استفاده نباشد، تعاریف پارتیشن در اولویت بعدی استفاده می‌شوند و به دنبال آن TaskPluginParam به عنوان آخرین راهکار استفاده خواهد شد، که حالت پیش‌فرض آن بدون اتصال (no binding) است. مقادیر پشتیبانی‌شده برای CpuBind عبارتند از none، socket، ldom (NUMA)، core و thread.
تعداد پردازنده‌های منطقی روی گره (مثلاً "2"). این مقدار می‌تواند روی تعداد کل سوکت‌ها (تنها توسط select/linear پشتیبانی می‌شود)، هسته‌ها یا ریسه‌ها تنظیم شود. این گزینه می‌تواند زمانی مفید باشد که می‌خواهید فقط هسته‌های روی یک گره با قابلیت hyper-threaded را زمان‌بندی کنید. اگر CPUs حذف شود، مقدار پیش‌فرض آن برابر با حاصل‌ضرب Boards، Sockets، CoresPerSocket و ThreadsPerCore تنظیم خواهد شد.
فهرستی جداشده با ویرگول از شناسه‌های انتزاعی CPU در Slurm که برای استفاده سیستم رزرو شده‌اند. این فهرست گسترش می‌یابد تا شامل تمام CPUهای دیگر (در صورت وجود) روی همان هسته‌ها شود. بسته به گزینه SlurmdOffSpec در TaskPluginParam، دیمن Slurm به نام slurmd ممکن است به این منابع محدود شود (پیش‌فرض) یا از استفاده از این منابع منع شود. اگر cgroup/v1 استفاده شود، همین موضوع برای فرآیندهای slurmstepd نیز اعمال می‌شود. جداسازی slurmd از کارهای کاربر ممکن است عملکرد برنامه را بهبود بخشد. یک کار در صورتی می‌تواند از این هسته‌ها استفاده کند که AllowSpecResourcesUsage=yes باشد و کاربر صراحتاً کمتر از تعداد CPUهای موجود در این فهرست را درخواست کند. اگر این گزینه و CoreSpecCount هر دو برای یک گره تعیین شوند، یک خطا ایجاد می‌شود. این گزینه هیچ تاثیری ندارد مگر اینکه محدودسازی کار توسط cgroup نیز پیکربندی شده باشد (یعنی پلاگین TaskPlugin از نوع task/cgroup فعال باشد و ConstrainCores=yes در cgroup.conf تنظیم شده باشد).
فهرستی جداشده با ویرگول از رشته‌های دلخواه که نشان‌دهنده برخی ویژگی‌های مرتبط با گره هستند. در حال حاضر هیچ مقدار یا شمارشی برای یک ویژگی وجود ندارد؛ یک گره یا دارای یک ویژگی است یا فاقد آن. یک ویژگی مورد نظر ممکن است حاوی یک بخش عددی باشد که برای مثال نشان‌دهنده سرعت پردازنده است، اما این بخش عددی به عنوان بخشی از رشته ویژگی در نظر گرفته خواهد شد. ویژگی‌ها برای فیلتر کردن گره‌های واجد شرایط جهت اجرای کارها از طریق آرگومان --constraint در نظر گرفته شده‌اند. به‌طور پیش‌فرض یک گره هیچ ویژگی‌ای ندارد. همچنین برای داشتن کنترل بیشتر مانند انواع و تعداد، به Gres مراجعه کنید. استفاده از ویژگی‌ها سریع‌تر از زمان‌بندی مبتنی بر GRES است اما به عملیات دودویی (Boolean) محدود می‌شود.

NOTE: تابع فهرست میزبان feature{myfeature} به تمام گره‌های دارای ویژگی مشخص‌شده گسترش می‌یابد. این تابع ممکن است به جای یا در کنار عبارات معمولی فهرست میزبان در دستورات یا فایل‌های پیکربندی که با slurmctld تعامل دارند استفاده شود. به عنوان مثال: scontrol update node=feature{myfeature} state=resume یا PartitionName=p1 Nodes=feature{myfeature}.

فهرستی جداشده با ویرگول از مشخصات منابع عمومی برای یک گره. قالب به این صورت است: "<name>[:<type>][:no_consume]:<number>[K|M|G]". فیلد اول نام منبع است که با نام پارامتر پیکربندی GresType مطابقت دارد. فیلد اختیاری type ممکن است برای شناسایی مدل آن منبع عمومی استفاده شود. تعیین هم‌زمان یک GRES بدون نوع و یک GRES دارای نوع با <name> یکسان ممنوع است. فیلد اختیاری no_consume به شما امکان می‌دهد مشخص کنید که یک منبع عمومی دارای تعداد محدودی از آن منبع نیست که با درخواست مصرف شود. فیلد no_consume یک تنظیم خاص GRES است و بدون در نظر گرفتن نوع مشخص‌شده برای GRES اعمال می‌شود. این گزینه نباید با GRESهایی که دارای پلاگین اختصاصی هستند استفاده شود؛ اگر به دنبال راهی برای تخصیص بیش از ظرفیت GPUها به چندین فرآیند به‌طور هم‌زمان هستید، ممکن است به جای آن به استفاده از GRES از نوع "shard" علاقه‌مند باشید. فیلد نهایی باید تعداد منابع عمومی را مشخص کند. یک پسوند "K"، "M"، "G"، "T" یا "P" ممکن است به ترتیب برای ضرب عدد در ۱۰۲۴، ۱۰۴۸۵۷۶، ۱۰۷۳۷۴۱۸۲۴ و غیره استفاده شود. (مثلاً "Gres=gpu:tesla:1,gpu:kepler:1,bandwidth:lustre:no_consume:4G"). اگر Gres در یک مدخل گره پیش‌فرض (NodeName=DEFAULT) پیکربندی شده باشد، می‌توانید یک رشته خالی (Gres="") تنظیم کنید تا هیچ Gresای در یک مدخل بعدی پیکربندی نشود. به‌طور پیش‌فرض یک گره هیچ منبع عمومی ندارد و حداکثر تعداد آن برابر با یک عدد صحیح ۶۴ بیتی بدون علامت است. همچنین برای پرچم‌های دودویی (Boolean) جهت فیلتر کردن گره‌ها با استفاده از محدودیت‌های کار، به Features مراجعه کنید.
مقدار RealMemory، بر حسب مبی‌بایت، که برای استفاده سیستم رزرو شده و برای تخصیص‌های کاربر در دسترس نیست. باید کمتر از مقدار تعریف‌شده برای RealMemory باشد. اگر پلاگین task/cgroup پیکربندی شده باشد و آن پلاگین تخصیص‌های حافظه را محدود کند (یعنی TaskPlugin از نوع task/cgroup فعال باشد و ConstrainRAMSpace=yes در cgroup.conf تنظیم شده باشد)، آنگاه به slurmd حد حافظه مشخص‌شده تخصیص داده می‌شود. اگر cgroup/v1 استفاده شود، به slurmstepd نیز حد حافظه مشخص‌شده تخصیص می‌یابد. اگر cgroup/v2 استفاده شود، میزان مصرف slurmstepd کاملاً وابسته به توپولوژی کار است. توجه داشته باشید که برای کارکرد این گزینه، تنظیم Memory در SelectTypeParameters به عنوان هر یک از گزینه‌هایی که آن را به عنوان یک منبع مصرفی در نظر می‌گیرند الزامی است. در صورتی که دیمن‌ها تمام تخصیص حافظه را مصرف کنند از بین برده نخواهند شد (یعنی Out-Of-Memory Killer برای cgroup حافظه دیمن غیرفعال است). اگر پلاگین task/cgroup پیکربندی نشده باشد، حافظه مشخص‌شده تنها برای تخصیص‌های کاربر غیرقابل دسترس خواهد بود.
امکان افزودن موارد مختص گره به پارامترهای سراسری SlurmdParameters را فراهم می‌کند. گزینه‌ها به انتها اضافه می‌شوند و نمی‌توانند گزینه‌های سراسری را بازنویسی کنند.
شماره پورتی که دیمن گره محاسباتی Slurm، یعنی slurmd، برای دریافت کار روی این گره خاص به آن گوش می‌دهد. به‌طور پیش‌فرض یک شماره پورت واحد برای تمام دیمن‌های slurmd روی تمام گره‌های محاسباتی همان‌طور که توسط پارامتر پیکربندی SlurmdPort تعریف شده است وجود دارد. استفاده از این گزینه به‌طور کلی توصیه نمی‌شود مگر برای اهداف توسعه یا آزمایش. اگر چندین دیمن slurmd روی یک گره اجرا شوند، این پارامتر می‌تواند بازه‌ای از پورت‌ها را مشخص کند.

NOTE: در سیستم‌های Cray، سیستم آدرس‌دهی IP مخصوص قلمرو (RSIP) به‌طور خودکار تلاش خواهد کرد با هر چیزی که روی پورت‌های ۸۱۹۲-۶۰۰۰۰ باز شده است تعامل برقرار کند. پارامتر Port را طوری پیکربندی کنید که از پورتی خارج از SrunPortRange پیکربندی‌شده و بازه پورت RSIP استفاده کند.

به CPUs مراجعه کنید.
اندازه حافظه واقعی روی گره بر حسب مبی‌بایت (مثلاً "2048"). مقدار پیش‌فرض 1 است. کاهش RealMemory با هدف کنار گذاشتن مقداری حافظه برای سیستم‌عامل و غیرقابل دسترس کردن آن برای تخصیص‌های کار، در صورتی که Memory به عنوان یک منبع مصرفی در SelectTypeParameters تنظیم نشده باشد، مطابق انتظار عمل نخواهد کرد. بنابراین برای دستیابی به این هدف، یکی از گزینه‌های *_Memory باید فعال شود. همچنین به MemSpecLimit مراجعه کنید.
دلیل قرار گرفتن یک گره در وضعیت "DOWN"، "DRAINED"، "DRAINING"، "FAIL" یا "FAILING" را مشخص می‌کند. برای دلایلی که بیش از یک کلمه دارند از علامت نقل‌قول استفاده کنید.
تعداد هسته‌ها به ازای هر GPU که فقط برای استفاده GPU محدود شده‌اند. اگر یک کار درخواست GPU نکند، به این هسته‌ها دسترسی نخواهد داشت. پردازنده‌های گرافیکی گره باید یا به‌طور خودکار شناسایی شوند یا هسته‌های معتبری در gres.conf(5) برای آن‌ها پیکربندی شده باشد.

NOTE: پیکربندی چندین نوع GPU روی سوکت‌های هم‌پوشان می‌تواند منجر به جفت‌شدن نادرست نوع GPU و هسته‌های محدودشده در تخصیص‌هایی شود که gpuها را بدون تعیین نوع درخواست می‌کنند. NOTE: منابع مشترک gpu gres (shards یا mps) به این هسته‌ها دسترسی خواهند داشت، اما هیچ تضمینی وجود ندارد که هسته‌های رزروشده به نسبت تخصیص gres مشترک استفاده شوند.

تعداد سوکت‌ها/تراشه‌های پردازنده فیزیکی روی گره (مثلاً "2"). اگر Sockets حذف شود، از روی CPUs، CoresPerSocket و ThreadsPerCore استنتاج خواهد شد. اگر پردازنده‌های چند‌هسته‌ای دارید، احتمالاً نیاز به تعیین این پارامترها خواهید داشت. Sockets و SocketsPerBoard مانعة‌الجمع هستند. اگر Sockets در زمانی که Boards نیز استفاده شده است مشخص شود، Sockets به جای کل سوکت‌ها به عنوان SocketsPerBoard تفسیر می‌شود. مقدار پیش‌فرض 1 است.

NOTE: اگر SlurmdParameters=numa_node_as_socket یا SlurmdParameters=l3cache_as_socket پیکربندی شده باشد، مقادیر Sockets، CoresPerSocket و ThreadsPerCore باید با توپولوژی مجازی گزارش‌شده توسط slurmd -C تحت آن پیکربندی مطابقت داشته باشد، نه با چیدمان سخت‌افزار فیزیکی. برای جزئیات به مستندات SlurmdParameters مراجعه کنید.

تعداد سوکت‌ها/تراشه‌های پردازنده فیزیکی روی یک برد اصلی (baseboard). پارامترهای Sockets و SocketsPerBoard مانعة‌الجمع هستند. مقدار پیش‌فرض 1 است.
گره‌هایی که برای این تعداد ثانیه در حالت بی‌کار (idle) یا از کار افتاده (down) باقی بمانند، توسط SuspendProgram در حالت صرفه‌جویی در مصرف انرژی قرار خواهند گرفت. این مقدار بر تنظیمات سطح پارتیشن و سراسری SuspendTime برای گره‌های مشخص‌شده اولویت دارد. برای گره‌هایی که در چندین پارتیشن با SuspendTime پیکربندی‌شده قرار دارند، مقدار سطح گره اولویت دارد. اگر روی گره تنظیم نشده باشد، مقادیر پارتیشن و سپس مقادیر سراسری استفاده می‌شوند. تنظیم SuspendTime روی INFINITE، تعلیق این گره‌ها را غیرفعال می‌کند. تنظیم SuspendTime روی هر مقداری به جز INFINITE (یا -1)، حالت صرفه‌جویی در مصرف انرژی را فعال می‌کند.
وضعیت گره با توجه به شروع کارهای کاربر. مقادیر قابل قبول عبارتند از CLOUD، DOWN، DRAIN، FAIL، FAILING، FUTURE و UNKNOWN. وضعیت‌های گره BUSY و IDLE نباید در پیکربندی گره مشخص شوند، بلکه به جای آن وضعیت گره را روی UNKNOWN تنظیم کنید. تنظیم وضعیت گره روی UNKNOWN منجر به این می‌شود که وضعیت گره بر اساس اطلاعات وضعیت سیستم بازیابی‌شده روی BUSY، IDLE یا وضعیت مناسب دیگر تنظیم شود. مقدار پیش‌فرض UNKNOWN است. همچنین به پارامتر DownNodes در زیر مراجعه کنید.
نشان می‌دهد که گره در ابر (cloud) وجود دارد. وضعیت اولیه آن به عنوان خاموش (powered down) در نظر گرفته خواهد شد. گره پس از بازیابی وضعیت آن از فایل ذخیره وضعیت Slurm یا شروع به کار دیمن slurmd روی گره محاسباتی، برای استفاده در دسترس خواهد بود.
نشان می‌دهد که گره دچار خرابی شده و برای تخصیص کار در دسترس نیست.
نشان می‌دهد که گره برای تخصیص کار در دسترس نیست.
نشان می‌دهد که انتظار می‌رود گره به زودی دچار خرابی شود، هیچ کاری به آن تخصیص نیافته است و به هیچ کار جدیدی نیز تخصیص نخواهد یافت.
نشان می‌دهد که انتظار می‌رود گره به زودی دچار خرابی شود، یک یا چند کار به آن تخصیص یافته است، اما به هیچ کار جدیدی تخصیص نخواهد یافت.
نشان می‌دهد که گره برای استفاده در آینده تعریف شده است و نیازی نیست هنگام شروع به کار دیمن‌های Slurm وجود داشته باشد. این گره‌ها را می‌توان صرفاً با به‌روزرسانی وضعیت گره با استفاده از دستور scontrol به جای راه‌اندازی مجدد دیمن slurmctld برای استفاده در دسترس قرار داد. پس از اینکه این گره‌ها در دسترس قرار گرفتند، State آن‌ها را در فایل slurm.conf تغییر دهید. تا زمانی که این گره‌ها در دسترس قرار نگیرند، با استفاده از هیچ دستور Slurm دیده نخواهند شد و هیچ تلاشی برای برقراری ارتباط با آن‌ها انجام نخواهد شد. گره‌های FUTURE وضعیت غیر-FUTURE را هنگام راه‌اندازی مجدد حفظ می‌کنند. از scontrol برای بازگرداندن گره به وضعیت FUTURE استفاده کنید.
یک slurmd که با -F[<feature>] شروع به کار کرده باشد، با یک گره FUTURE که با همان پیکربندی (سوکت‌ها، هسته‌ها، ریسه‌ها) گزارش‌شده توسط slurmd -C مطابقت دارد، مرتبط خواهد شد. NodeAddr و NodeHostname گره به‌طور خودکار از slurmd بازیابی می‌شوند و هنگام بازگشت به وضعیت FUTURE پاک خواهند شد.
نشان می‌دهد که وضعیت گره تعریف‌نشده است اما هنگامی که دیمن slurmd روی آن گره ثبت‌نام کند، برقرار خواهد شد (روی BUSY یا IDLE تنظیم می‌شود). UNKNOWN وضعیت پیش‌فرض است.
تعداد ریسه‌های منطقی در یک هسته فیزیکی (مثلاً "2"). توجه داشته باشید که Slurm می‌تواند منابع را تا سطح تفکیک‌پذیری یک هسته به کارها تخصیص دهد. اگر سیستم شما با بیش از یک ریسه در هر هسته پیکربندی شده باشد، اجرای یک کار متفاوت روی هر ریسه پشتیبانی نمی‌شود مگر اینکه SelectTypeParameters=CR_CPU به همراه CPUs را پیکربندی کنید؛ در این حالت Sockets، CoresPerSocket یا ThreadsPerCore را پیکربندی نکنید. یک کار می‌تواند یک وظیفه در هر ریسه را از داخل یک گام کار اجرا کند یا یک گام کار متمایز را روی هر یک از ریسه‌ها اجرا نماید. همچنین توجه داشته باشید که اگر با بیش از ۱ ریسه در هر هسته کار می‌کنید و در حال اجرای پلاگین select/cons_tres هستید، برای جلوگیری از نتایج غیرمنتظره باید متغیر SelectTypeParameters را روی مقداری غیر از CR_CPU تنظیم کنید. مقدار پیش‌فرض 1 است.
اندازه کل فضای ذخیره‌سازی دیسک موقت در TmpFS بر حسب مبی‌بایت (مثلاً "16384"). TmpFS (مخفف "Temporary File System") مکانی را مشخص می‌کند که کارها باید برای ذخیره‌سازی موقت استفاده کنند. توجه داشته باشید که این مقدار نشان‌دهنده مقدار فضای خالی در دسترس کاربر روی گره نیست، بلکه فقط اندازه کل فایل‌سیستم است. مدیر سیستم باید اطمینان حاصل کند که این فایل‌سیستم در صورت نیاز پاک‌سازی می‌شود تا کارهای کاربر به بیشتر این فضا دسترسی داشته باشند. برنامه‌های Prolog و/یا Epilog (مشخص‌شده در فایل پیکربندی) ممکن است برای اطمینان از تمیز نگه داشتن فایل‌سیستم استفاده شوند. مقدار پیش‌فرض 0 است.
فهرستی جداشده با ویرگول از جفت‌ها با قالب <topology_name>:<topology_unit>. که در آن <topology_unit> نام بلوک یا نام یک سوئیچ برگ است. نام‌های سوئیچ واسط -- جداشده با ':' -- می‌توانند ارائه شوند و در صورت نیاز ایجاد خواهند شد (مثلاً Topology=topo-tree:sw_root:s1:s2). این تنظیم، پیکربندی وابستگی توپولوژی گره مشخص‌شده در topology.conf(5) و topology.yaml(5) را بازنویسی می‌کند.
اولویت گره برای اهداف زمان‌بندی. در شرایط برابر، به کارها گره‌هایی با کمترین وزن که نیازهای آن‌ها را برآورده می‌کنند، تخصیص داده می‌شود. برای مثال، مجموعه‌ای ناهمگن از گره‌ها ممکن است برای بهره‌وری، پاسخ‌گویی و توانمندی بالاتر سیستم در یک پارتیشن واحد قرار داده شوند. در صورتی که هر دو نیازهای یک کار را برآورده کنند، تخصیص گره‌های با حافظه کمتر به جای گره‌های با حافظه بیشتر ترجیح داده می‌شود. واحدهای وزن اختیاری هستند، اما وزن‌های بزرگ‌تر باید به گره‌هایی با پردازنده‌ها، حافظه، فضای دیسک بیشتر، سرعت پردازنده بالاتر و غیره اختصاص داده شوند. توجه داشته باشید که اگر درخواست تخصیص کار با استفاده از گره‌های با کمترین وزن برآورده نشود، مجموعه گره‌های با وزن کم بعدی به مجموعه گره‌های تحت بررسی برای استفاده اضافه می‌شود (این کار در صورت نیاز برای مقادیر وزن بالاتر تکرار می‌شود). اگر کاملاً می‌خواهید تعداد گره‌های با وزن بالاتر تخصیص‌یافته به یک کار را به حداقل برسانید (به قیمت سربار زمان‌بندی بالاتر)، به هر گره یک مقدار Weight متمایز بدهید و آن‌ها به‌طور جداگانه به استخر گره‌های تحت بررسی برای زمان‌بندی اضافه خواهند شد.

مقدار پیش‌فرض 1 است.

NOTE: وزن‌های گره ابتدا در میان گره‌های در دسترس فعلی بررسی می‌شوند. برای مثال، گره‌های POWERED_DOWN و POWERING_UP با وزن‌های کمتر، قبل از یک گره IDLE روشن‌شده ارزیابی نخواهند شد.

پارامتر DownNodes= به شما اجازه می‌دهد تا گره‌های خاصی را بدون تغییر در اطلاعات پیکربندی دائمی فهرست‌شده تحت یک مشخصه NodeName=، در وضعیت DOWN، DRAIN، FAIL، FAILING یا FUTURE علامت‌گذاری کنید.

هر نام گره، یا فهرستی از نام‌های گره، برگرفته از مشخصات NodeName=.
دلیل قرار گرفتن یک گره در وضعیت DOWN، DRAIN، FAIL، FAILING یا FUTURE را مشخص می‌کند. برای دلایلی که بیش از یک کلمه دارند از علامت نقل‌قول استفاده کنید.
وضعیت گره با توجه به شروع کارهای کاربر. مقادیر قابل قبول عبارتند از DOWN، DRAIN، FAIL، FAILING و FUTURE. برای اطلاعات بیشتر در مورد این وضعیت‌ها به توضیحات تحت State در بخش NodeName= در بالا مراجعه کنید. مقدار پیش‌فرض DOWN است.

پیکربندی مجموعه گره (nodeset) به شما اجازه می‌دهد نامی برای یک مجموعه خاص از گره‌ها تعریف کنید که می‌تواند برای ساده‌سازی بخش پیکربندی پارتیشن، به‌ویژه برای سیستم‌های ناهمگن یا به سبک کاندو (condo-style)، استفاده شود. هر مجموعه گره ممکن است با یک فهرست صریح از گره‌ها و/یا با فیلتر کردن گره‌ها بر اساس یک ویژگی پیکربندی‌شده خاص تعریف شود. اگر هر دو Feature= و Nodes= استفاده شوند، مجموعه گره اجتماع این دو زیرمجموعه خواهد بود. توجه داشته باشید که مجموعه‌های گره در حال حاضر فقط برای ساده‌سازی تعاریف پارتیشن استفاده می‌شوند و خارج از پیکربندی پارتیشن قابل استفاده نیستند.

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

پیکربندی پارتیشن به شما امکان می‌دهد محدودیت‌های کار یا کنترل‌های دسترسی مختلفی را برای گروه‌ها (یا پارتیشن‌های) مختلف از گره‌ها برقرار کنید. گره‌ها ممکن است در بیش از یک پارتیشن قرار داشته باشند، که باعث می‌شود پارتیشن‌ها به عنوان صف‌های چندمنظوره عمل کنند. برای مثال می‌توان همان مجموعه از گره‌ها را در دو پارتیشن مختلف قرار داد که هر کدام دارای محدودیت‌های متفاوتی هستند (محدودیت زمانی، اندازه‌های کار، گروه‌های مجاز به استفاده از پارتیشن و غیره). منابع در داخل یک پارتیشن واحد به کارها تخصیص داده می‌شوند. مقادیر پیش‌فرض را می‌توان با رکوردی که در آن PartitionName برابر با "DEFAULT" است مشخص کرد. مقادیر مدخل پیش‌فرض تنها برای خطوط بعد از آن در فایل پیکربندی اعمال می‌شوند و مقادیر پیش‌فرض را می‌توان چندین بار در فایل پیکربندی با چندین مدخل که در آن‌ها "PartitionName=DEFAULT" است بازنشانی کرد. مشخصه "PartitionName=" باید در هر خطی که پیکربندی پارتیشن‌ها را توصیف می‌کند قرار داده شود. هر خطی که در آن PartitionName برابر با "DEFAULT" است، مقادیر پیش‌فرض قبلی را جایگزین می‌کند یا به آن‌ها می‌افزاید و مقادیر پیش‌فرض را مجدداً مقداردهی اولیه نمی‌کند. یک نام پارتیشن واحد نمی‌تواند به عنوان مقدار PartitionName در بیش از یک خط ظاهر شود (رکوردهای تکراری نام پارتیشن نادیده گرفته خواهند شد). اگر پارتیشنی که در حال استفاده است از پیکربندی حذف شود و slurm راه‌اندازی مجدد یا بازپیکربندی شود (scontrol reconfigure)، کارهایی که از آن پارتیشن استفاده می‌کنند لغو می‌شوند. NOTE: تمام پارامترهای مربوط به هر پارتیشن را در یک خط واحد قرار دهید. هر خط از اطلاعات پیکربندی پارتیشن باید نشان‌دهنده یک پارتیشن متفاوت باشد. فایل پیکربندی پارتیشن شامل اطلاعات زیر است:

فهرستی جداشده با ویرگول از گره‌هایی که کاربران می‌توانند از آن‌ها کارها را در پارتیشن ارسال کنند. نام‌های گره ممکن است با استفاده از نحو عبارت بازه گره توصیف‌شده در بالا مشخص شوند. مقدار پیش‌فرض "ALL" است.
فهرستی جداشده با ویرگول از حساب‌هایی که ممکن است کارها را در پارتیشن اجرا کنند. مقدار پیش‌فرض "ALL" است. این فهرست سلسله‌مراتبی است، به این معنی که حساب‌های فرعی به‌طور خودکار گنجانده می‌شوند. NOTE: اگر AllowAccounts استفاده شود، DenyAccounts اعمال نخواهد شد. همچنین به DenyAccounts مراجعه کنید.
فهرستی جداشده با ویرگول از نام‌های گروه که ممکن است کارها را در این پارتیشن اجرا کنند. اگر AllowGroups حداقل یک گروه مرتبط با کاربر داشته باشد، به کاربر اجازه ارسال کار به این پارتیشن داده خواهد شد. کارهای اجراشده به عنوان کاربر root یا کاربر SlurmUser مجاز به استفاده از هر پارتیشنی، صرف‌نظر از مقدار AllowGroups خواهند بود. علاوه بر این، یک مدیر یا اپراتور Slurm قادر به مشاهده هر پارتیشنی، صرف‌نظر از مقدار AllowGroups خواهد بود. اگر کاربر root تلاش کند کاری را به عنوان کاربری دیگر اجرا کند (مثلاً با استفاده از گزینه --uid در srun)، آنگاه کار مشمول AllowGroups خواهد بود گویی که توسط آن کاربر ارسال شده است. به‌طور پیش‌فرض، AllowGroups تنظیم نشده است، به این معنی که تمام گروه‌ها مجاز به استفاده از این پارتیشن هستند. مقدار ویژه 'ALL' معادل این حالت است. کاربرانی که عضو گروه مشخص‌شده نیستند به‌طور پیش‌فرض اطلاعات مربوط به این پارتیشن را نخواهند دید. با این حال، این مورد نباید به عنوان یک مکانیزم امنیتی در نظر گرفته شود، زیرا اگر کاربری جزئیات مربوط به پارتیشن یا یک کار خاص را درخواست کند، اطلاعات کار برگردانده خواهد شد. برای محدود کردن دسترسی به اطلاعات کار به پارامتر PrivateData مراجعه کنید. NOTE: به دلایل کارایی، Slurm فهرستی از شناسه‌های کاربری مجاز به استفاده از هر پارتیشن را نگهداری می‌کند و این مورد در زمان ارسال کار بررسی می‌شود. این فهرست از شناسه‌های کاربری زمانی به‌روزرسانی می‌شود که دیمن slurmctld راه‌اندازی مجدد شود، بازپیکربندی شود (مثلاً "scontrol reconfig") یا مقدار AllowGroups پارتیشن بازنشانی شود، حتی اگر مقدار آن بدون تغییر باشد (مثلاً "scontrol update PartitionName=name AllowGroups=group"). برای اینکه دسترسی کاربر به یک پارتیشن تغییر کند، هم عضویت گروهی او باید تغییر کند و هم فهرست شناسه کاربری داخلی Slurm با استفاده از یکی از روش‌های توصیف‌شده در بالا تغییر یابد.
فهرستی جداشده با ویرگول از QOSهایی که ممکن است کارها را در پارتیشن اجرا کنند. کارهای اجراشده به عنوان کاربر root می‌توانند از هر پارتیشنی بدون توجه به مقدار AllowQos استفاده کنند. مقدار پیش‌فرض "ALL" است. NOTE: اگر AllowQos استفاده شود، DenyQos اعمال نخواهد شد. همچنین به DenyQos مراجعه کنید.
نام پارتیشن جایگزین برای استفاده در صورتی که وضعیت این پارتیشن "DRAIN" یا "INACTIVE" باشد.
اگر یک درخواست گام کار گزینه‌ای را برای کنترل نحوه اتصال وظایف به CPUهای تخصیص‌یافته تعیین نکند (با استفاده از --cpu-bind) و تمام گره‌های تخصیص‌یافته به کار گزینه CpuBind یکسانی برای گره نداشته باشند، آنگاه گزینه CpuBind پارتیشن کنترل خواهد کرد که وظایف چگونه به منابع تخصیص‌یافته متصل شوند. TaskPluginParam به عنوان آخرین راهکار استفاده خواهد شد، که حالت پیش‌فرض آن بدون اتصال است. مقادیر پشتیبانی‌شده برای CpuBind عبارتند از none، socket، ldom (NUMA)، core و thread.
اگر این کلمه کلیدی تنظیم شود، کارهای ارسال‌شده بدون تعیین پارتیشن از این پارتیشن استفاده خواهند کرد. مقادیر ممکن "YES" و "NO" هستند. مقدار پیش‌فرض "NO" است.
محدودیت زمان اجرا برای کارهایی که مقداری تعیین نمی‌کنند استفاده می‌شود. اگر تنظیم نشود، مقدار پیش‌فرض روی یک محدودیت زمانی قابل اعمال تنظیم می‌شود که ممکن است از پارتیشن (MaxTime) یا از یک QOS یا انتساب (MaxWall یا GrpWall) باشد. در هر صورت، MaxTime همچنان اعمال خواهد شد. قالب آن همانند MaxTime است.
تعداد پیش‌فرض CPUهای تخصیص‌یافته به ازای هر GPU تخصیص‌یافته. این مقدار تنها در صورتی استفاده می‌شود که کار --cpus-per-task و --cpus-per-gpu را مشخص نکرده باشد.
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر CPU تخصیص‌یافته بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. DefMemPerCPU به‌طور کلی در صورتی استفاده می‌شود که پردازنده‌های منفرد به کارها تخصیص داده شوند (SelectType=select/cons_tres). اگر تنظیم نشود، مقدار DefMemPerCPU برای کل کلاستر استفاده خواهد شد. همچنین به DefMemPerGPU، DefMemPerNode و MaxMemPerCPU مراجعه کنید. پارامترهای DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر GPU تخصیص‌یافته بر حسب مبی‌بایت. لطفاً توجه داشته باشید که حداکثر تلاش برای پیش‌بینی اینکه کدام GPUها در سیستم استفاده خواهند شد انجام می‌شود، اما این مورد ممکن است بین زمان ارسال کار و شروع به کار تغییر کند، و باعث شود MaxMemPerNode احتمالاً طبق انتظار برای کارهای ناهمگن عمل نکند. همچنین به DefMemPerCPU، DefMemPerNode و MaxMemPerCPU مراجعه کنید. پارامترهای DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.
اندازه پیش‌فرض حافظه واقعی در دسترس به ازای هر گره تخصیص‌یافته بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. DefMemPerNode به‌طور کلی در صورتی استفاده می‌شود که کل گره‌ها به کارها تخصیص داده شوند (SelectType=select/linear) و منابع بیش از ظرفیت تخصیص داده شوند (OverSubscribe=yes یا OverSubscribe=force). اگر تنظیم نشود، مقدار DefMemPerNode برای کل کلاستر استفاده خواهد شد. همچنین به DefMemPerCPU، DefMemPerGPU و MaxMemPerCPU مراجعه کنید. پارامترهای DefMemPerCPU، DefMemPerGPU و DefMemPerNode مانعة‌الجمع هستند.
فهرستی جداشده با ویرگول از حساب‌هایی که ممکن است کارها را در پارتیشن اجرا نکنند. به‌طور پیش‌فرض، دسترسی هیچ حسابی رد نمی‌شود. این فهرست سلسله‌مراتبی است، به این معنی که حساب‌های فرعی به‌طور خودکار گنجانده می‌شوند. NOTE: اگر AllowAccounts استفاده شود، DenyAccounts اعمال نخواهد شد. همچنین به AllowAccounts مراجعه کنید.
فهرستی جداشده با ویرگول از QOSهایی که ممکن است کارها را در پارتیشن اجرا نکنند. به‌طور پیش‌فرض، دسترسی هیچ QOSای رد نمی‌شود. NOTE: اگر AllowQos استفاده شود، DenyQos اعمال نخواهد شد. همچنین به AllowQos مراجعه کنید.
اگر روی "YES" تنظیم شود، از اجرای هرگونه کار توسط کاربر root روی این پارتیشن جلوگیری خواهد شد. مقدار پیش‌فرض، مقدار DisableRootJobs تنظیم‌شده در خارج از مشخصات پارتیشن خواهد بود (که "NO" است و به کاربر root اجازه اجرای کارها را می‌دهد).
انحصاری بودن در سطح پارتیشن را همراه با OverSubscribe کنترل می‌کند. یکی از مقادیر "NO"، "NODE"، "USER" یا "TOPO" را مشخص کنید. مقدار NODE کل گره‌ها را تخصیص می‌دهد و متضمن OverSubscribe=NO است. مقدار USER به تنها یک کاربر اجازه می‌دهد تا در هر زمان کارهایی روی یک گره داشته باشد (مشابه --exclusive=user). مقدار TOPO تنها یک کار را در هر بخش توپولوژی مجاز می‌داند (مشابه --exclusive=topo) و متضمن OverSubscribe=NO است. برای پارتیشن‌های با گره انحصاری، کارها تمام CPUها و منابع عمومی روی گره‌های تخصیص‌یافته را دریافت می‌کنند، اما حافظه را فقط به میزان درخواست‌شده دریافت می‌کنند؛ از --mem=0 در زمان ارسال برای درخواست تمام حافظه روی گره استفاده کنید (به‌ویژه هنگام استفاده از زمان‌بندی گروهی که در آن کارهای معلق هنوز حافظه را اشغال می‌کنند). اگر تنظیم نشود، هیچ انحصار سطح پارتیشنی فراتر از OverSubscribe اضافه نمی‌شود.

این پارامتر جایگزین گزینه‌های منسوخ‌شده OverSubscribe=EXCLUSIVE، ExclusiveUser و ExclusiveTopo می‌شود. پارامترهای ExclusiveUser=YES و ExclusiveTopo=YES مانعة‌الجمع هستند. اگر هر دو گزینه منسوخ‌شده برای یک پارتیشن تنظیم شوند، ExclusiveUser نادیده گرفته خواهد شد.

مهلت پیش‌دستانه را بر حسب ثانیه مشخص می‌کند که به کاری که برای پیش‌دستی انتخاب شده است اعطا می‌شود. این پارامتر تنها زمانی اعمال می‌شود که PreemptType=partition_prio باشد. مقدار پیش‌فرض صفر است و هیچ مهلت پیش‌دستانه‌ای در این پارتیشن مجاز نیست. هنگامی که یک کار برای پیش‌دستی انتخاب می‌شود، زمان پایان آن روی زمان فعلی به‌علاوه GraceTime تنظیم می‌شود. به وظایف کار فوراً سیگنال‌های SIGCONT و SIGTERM ارسال می‌شود تا اخطار پایان قریب‌الوقوع آن ارائه شود. به دنبال آن توالی سیگنال‌های SIGCONT، SIGTERM و SIGKILL پس از رسیدن به زمان پایان جدید آن ارسال می‌شود. این مجموعه دوم از سیگنال‌ها هم به وظایف و هم به اسکریپت دسته‌ای شامل آن (در صورت وجود) ارسال می‌شود. همچنین به پارامتر پیکربندی سراسری KillWait مراجعه کنید.

NOTE: این پارامتر برای PreemptMode=SUSPEND اعمال نمی‌شود. برای تنظیم مهلت پیش‌دستانه هنگام استفاده از PreemptMode=SUSPEND، به PreemptParameters=suspend_grace_time مراجعه کنید.

NOTE: کاری که برای پیش‌دستی انتخاب شده و قبل از انقضای GraceTime خارج می‌شود، صرف‌نظر از دلیل خروج آن بر اساس PreemptMode مدیریت خواهد شد (بیشتر در صورتی که PreemptMode=REQUEUE باشد مشهود است). Slurm نمی‌تواند بین خروج ناشی از سیگنال پیش‌دستی و خروج نامرتبطی که در طول GraceTime رخ می‌دهد تمایز قائل شود.

مشخص می‌کند که آیا پارتیشن و کارهای آن به‌طور پیش‌فرض پنهان شوند یا خیر. پارتیشن‌های پنهان به‌طور پیش‌فرض توسط APIها یا دستورات Slurm گزارش نخواهند شد. مقادیر ممکن "YES" و "NO" هستند. مقدار پیش‌فرض "NO" است. توجه داشته باشید که پارتیشن‌هایی که کاربر به واسطه پارامتر AllowGroups به آن‌ها دسترسی ندارد نیز به‌طور پیش‌فرض پنهان خواهند بود.
منابع را بر روی گره‌های با کمترین بار (بر اساس تعداد CPUهای بی‌کار) به کارها زمان‌بندی می‌کند. این مورد به‌طور کلی فقط برای محیطی با کارهای سریالی توصیه می‌شود زیرا منابع بی‌کار تمایل زیادی به قطعه‌قطعه شدن دارند که منجر به توزیع کارهای موازی در چندین گره می‌شود. توجه داشته باشید که Weight گره بر میزان منابع بی‌کار روی هر گره اولویت دارد. همچنین برای استفاده از گره‌های با کمترین بار در هر پارتیشن، به پارامتر پیکربندی CR_LLN در SelectTypeParameters مراجعه کنید.
حداکثر تعداد CPUها در هر گره که در دسترس تمام کارهای این پارتیشن قرار دارد. این می‌تواند به‌ویژه برای زمان‌بندی GPUها مفید باشد. به عنوان مثال یک گره می‌تواند با دو پارتیشن Slurm (مثلاً "cpu" و "gpu") مرتبط باشد و پارتیشن/صف "cpu" می‌تواند فقط به زیرمجموعه‌ای از CPUهای گره محدود شود، و اطمینان حاصل شود که یک یا چند CPU در دسترس کارهای موجود در پارتیشن/صف "gpu" خواهد بود. همچنین به MaxCPUsPerSocket مراجعه کنید.
حداکثر تعداد CPUها در هر گره که در تمام کارهای این پارتیشن در دسترس است. این می‌تواند به‌ویژه برای زمان‌بندی GPUها مفید باشد. همچنین به MaxCPUsPerNode مراجعه کنید.
حداکثر اندازه حافظه واقعی در دسترس به ازای هر CPU تخصیص‌یافته بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. MaxMemPerCPU به‌طور کلی در صورتی استفاده می‌شود که پردازنده‌های منفرد به کارها تخصیص داده شوند (SelectType=select/cons_tres). اگر تنظیم نشود، مقدار MaxMemPerCPU برای کل کلاستر استفاده خواهد شد. همچنین به DefMemPerCPU و MaxMemPerNode مراجعه کنید. پارامترهای MaxMemPerCPU و MaxMemPerNode مانعة‌الجمع هستند.
حداکثر اندازه حافظه واقعی در دسترس به ازای هر گره تخصیص‌یافته در یک تخصیص کار بر حسب مبی‌بایت. برای جلوگیری از تخصیص بیش از حد حافظه و ایجاد صفحه‌بندی استفاده می‌شود. MaxMemPerNode به‌طور کلی در صورتی استفاده می‌شود که کل گره‌ها به کارها تخصیص داده شوند (SelectType=select/linear) و منابع بیش از ظرفیت تخصیص داده شوند (OverSubscribe=yes یا OverSubscribe=force). اگر تنظیم نشود، مقدار MaxMemPerNode برای کل کلاستر استفاده خواهد شد. همچنین به DefMemPerNode و MaxMemPerCPU مراجعه کنید. پارامترهای MaxMemPerCPU و MaxMemPerNode مانعة‌الجمع هستند.
حداکثر تعداد گره‌هایی که ممکن است به هر کار منفرد تخصیص داده شود. مقدار پیش‌فرض "UNLIMITED" است که در داخل به صورت -1 نمایش داده می‌شود.
حداکثر محدودیت زمان اجرا برای کارها. قالب آن به صورت دقیقه‌ها، دقیقه‌ها:ثانیه‌ها، ساعت‌ها:دقیقه‌ها:ثانیه‌ها، روزها-ساعت‌ها، روزها-ساعت‌ها:دقیقه‌ها، روزها-ساعت‌ها:دقیقه‌ها:ثانیه‌ها یا "UNLIMITED" است. تفکیک‌پذیری زمانی یک دقیقه است و مقادیر ثانیه به دقیقه بعدی گرد می‌شوند. مقدار TimeLimit کار ممکن است پس از ارسال کار توسط root، SlurmUser یا یک اپراتور به مقداری بالاتر از MaxTime پیکربندی‌شده به‌روزرسانی شود.
حداقل تعداد گره‌هایی که ممکن است به هر کار منفرد تخصیص داده شود. مقدار پیش‌فرض 0 است.
فهرستی جداشده با کاما از گره‌ها یا مجموعه‌گره‌ها (nodesets) که با این پارتیشن مرتبط هستند. نام‌های گره را می‌توان با استفاده از نحو عبارت محدوده گره که در بالا شرح داده شد مشخص کرد. اگر بخواهید یک پارتیشن وجود داشته باشد اما هیچ منبعی نداشته باشد (احتمالاً به‌صورت موقت)، می‌توان از یک فهرست خالی از گره‌ها (یعنی Nodes="") استفاده کرد. مقدار "ALL" به همه گره‌های پیکربندی‌شده در خوشه نگاشت می‌شود.
توانایی پارتیشن برای اجرای بیش از یک کار در یک زمان روی هر منبع (گره، سوکت یا هسته بسته به مقدار SelectTypeParameters) را کنترل می‌کند. اگر قرار است منابع بیش از حد تخصیص داده شوند (over-subscribed)، اجتناب از تخصیص بیش از حد حافظه بسیار مهم است. SelectTypeParameters باید طوری پیکربندی شود که حافظه را به عنوان یک منبع مصرفی در نظر بگیرد و از گزینه --mem برای تخصیص‌های کار استفاده شود. به اشتراک‌گذاری منابع معمولاً فقط هنگام استفاده از زمان‌بندی گروهی (gang scheduling) (PreemptMode=suspend,gang) مفید است. مقادیر ممکن برای OverSubscribe عبارتند از "FORCE"، "YES" و "NO". پارتیشن‌های اختصاصی تمام‌گره را می‌توان با Exclusive=node پیکربندی کرد (به بالا مراجعه کنید). توجه داشته باشید که مقدار "YES" یا "FORCE" می‌تواند تأثیر منفی بر عملکرد سیستم‌هایی با چندین هزار کار در حال اجرا بگذارد. مقدار پیش‌فرض "NO" است. برای اطلاعات بیشتر به صفحات وب زیر مراجعه کنید:
https://slurm.schedmd.com/cons_tres.html
https://slurm.schedmd.com/cons_tres_share.html
https://slurm.schedmd.com/gang_scheduling.html
https://slurm.schedmd.com/preempt.html
تمام منابع (به جز GRES) در پارتیشن را بدون هیچ راهی برای کاربران جهت غیرفعال کردن آن، برای بیش‌تخصیصی در دسترس قرار می‌دهد. می‌تواند با یک دونقطه و حداکثر تعداد کارها در وضعیت در حال اجرا یا تعلیق‌شده همراه باشد. به عنوان مثال OverSubscribe=FORCE:4 به هر گره، سوکت یا هسته امکان می‌دهد تا هر منبع را به ۴ کار بیش‌تخصیص دهد. تنها برای سامانه‌هایی که از PreemptMode=suspend,gang استفاده می‌کنند توصیه می‌شود.

NOTE: گزینه OverSubscribe=FORCE:1 یک حالت خاص است که دقیقاً معادل OverSubscribe=NO نیست. OverSubscribe=FORCE:1 بیش‌تخصیصی عادی منابع در همان پارتیشن را غیرفعال می‌کند، اما همچنان امکان بیش‌تخصیصی ناشی از پیش‌دستی (preemption) یا در پارتیشن‌های هم‌پوشان با همان PriorityTier را فراهم می‌سازد. تنظیم OverSubscribe=NO از بیش‌تخصیصی در همه موارد جلوگیری می‌کند.

NOTE: در صورت استفاده از PreemptType=preempt/qos می‌توانید مقداری بزرگتر از 1 را برای FORCE مشخص کنید. به عنوان مثال، OverSubscribe=FORCE:2 به طور معمول به ازای هر منبع به دو کار اجازه اجرا می‌دهد، اما کار سوم تنها در صورتی می‌تواند شروع شود که از طریق پیش‌دستی بر اساس QOS انجام گیرد.

NOTE: اگر OverSubscribe در slurm.conf شما روی FORCE یا YES تنظیم شده باشد و سامانه برای استفاده از پیش‌دستی پیکربندی نشده باشد (PreemptMode=OFF)، حسابداری (accounting) به راحتی می‌تواند به مقادیری بیشتر از میزان استفاده واقعی رشد کند. ممکن است در چنین سامانه‌هایی دریافت پیام‌های خطا در لاگ slurmdbd با این مضمون معمول باشد: "We have more allocated time than is possible."

تمام منابع (به جز GRES) را در پارتیشن در صورت درخواست توسط کار، برای اشتراک‌گذاری در دسترس قرار می‌دهد. منابع تنها زمانی بیش‌تخصیص داده می‌شوند که کاربر هنگام ارسال کار صراحتاً با استفاده از گزینه "--oversubscribe" درخواست داده باشد. می‌تواند با یک دونقطه و حداکثر تعداد کارها در وضعیت در حال اجرا یا تعلیق‌شده همراه باشد. به عنوان مثال "OverSubscribe=YES:4" به هر گره، سوکت یا هسته امکان می‌دهد تا حداکثر ۴ کار را به‌طور هم‌زمان اجرا کند. تنها برای سامانه‌هایی که با زمان‌بندی گروهی (PreemptMode=suspend,gang) اجرا می‌شوند توصیه می‌شود.
منابع انتخاب‌شده به یک کار اختصاص می‌یابند. هیچ منبعی به بیش از یک کار تخصیص داده نخواهد شد.

NOTE: حتی اگر از PreemptMode=suspend,gang استفاده می‌کنید، تنظیم OverSubscribe=NO پیش‌دستی را در آن پارتیشن غیرفعال می‌کند. اگر می‌خواهید بیش‌تخصیصی عادی را غیرفعال کنید اما همچنان امکان تعلیق به دلیل پیش‌دستی فراهم باشد، از OverSubscribe=FORCE:1 استفاده کنید.

تعداد دقایقی که یک کار می‌تواند از محدودیت زمانی خود فراتر رود پیش از آنکه لغو شود. به طور معمول محدودیت زمانی کار به عنوان یک حد سخت (hard) در نظر گرفته می‌شود و کار با رسیدن به آن حد متوقف (killed) خواهد شد. پیکربندی OverTimeLimit باعث می‌شود محدودیت زمانی کار مانند یک حد نرم (soft) رفتار کند. افزودن مقدار OverTimeLimit به محدودیت زمانی نرم یک محدودیت زمانی سخت ایجاد می‌کند که در آن نقطه کار لغو می‌شود. این امر به‌ویژه برای زمان‌بندی backfill که بر اساس محدودیت زمانی نرم هر کار عمل می‌کند، مفید است. اگر تنظیم نشود، مقدار OverTimeLimit کل خوشه استفاده خواهد شد. نباید از 65533 دقیقه تجاوز کند. مقدار "UNLIMITED" نیز پشتیبانی می‌شود.
نامی که پارتیشن می‌تواند با آن ارجاع داده شود (مانند "Interactive"). این نام می‌تواند توسط کاربران هنگام ارسال کار مشخص شود. اگر PartitionName برابر با "DEFAULT" باشد، مقادیر مشخص‌شده با آن رکورد برای مشخصات پارتیشن‌های بعدی اعمال خواهد شد، مگر اینکه صراحتاً در آن رکورد پارتیشن روی مقادیر دیگری تنظیم شده باشد یا با مجموعه دیگری از مقادیر پیش‌فرض جایگزین شود. هر خطی که در آن PartitionName برابر با "DEFAULT" باشد، مقادیر پیش‌فرض قبلی را جایگزین کرده یا به آنها اضافه می‌کند و مقادیر پیش‌فرض را مجدداً مقداردهی اولیه نمی‌کند.
اگر روی "YES" تنظیم شود و ذخیره انرژی (power saving) برای پارتیشن فعال باشد، پس از تخصیص حداقل یک کار به گره‌های تخصیص‌یافته از این پارتیشن، درخواست خاموش شدن (power down) آنها ارسال خواهد شد. این گره‌ها تا زمانی که از وضعیت COMPLETING به IDLE تغییر وضعیت ندهند، خاموش نخواهند شد. اگر روی "NO" تنظیم شود، ذخیره انرژی طبق آنچه برای پارتیشن پیکربندی شده است عمل خواهد کرد. مقدار پیش‌فرض "NO" است. برای جزئیات بیشتر به https://slurm.schedmd.com/power_save.html و https://slurm.schedmd.com/elastic_computing.html مراجعه کنید.

NOTE: موارد زیر باعث انتقال از وضعیت COMPLETING به IDLE می‌شوند:
تکمیل تمام کارهای در حال اجرا بدون تخصیص کارهای اضافی.
Exclusive=USER و پس از تکمیل تمام کارهای در حال اجرا اما پیش از تخصیص کار یک کاربر دیگر.
Exclusive=NODE و پس از تکمیل کار در حال اجرا اما پیش از تخصیص کاری دیگر.

NOTE: گره‌ها در صورت بیکار (IDLE) بودن به مدت SuspendTime، حتی زمانی که PowerDownOnIdle روی NO تنظیم شده باشد، همچنان مشمول خاموش شدن هستند.

همچنین به SuspendTime مراجعه کنید.

سازوکار مورد استفاده برای پیش‌دستی کارهای در حال اجرا در این پارتیشن هنگامی که PreemptType=preempt/partition_prio پیکربندی شده است. این پارامتر پیکربندی PreemptMode مختص پارتیشن، مقدار PreemptMode سراسری خوشه را برای کارهای این پارتیشن لغو (override) می‌کند. می‌توان آن را روی OFF تنظیم کرد تا از پیش‌دستی کارهای این پارتیشن جلوگیری شود. همچنین برای جزئیات بیشتر به PriorityTier و توضیحات فوق در مورد پارامتر سراسری PreemptMode مراجعه کنید.
برای جزئیات بیشتر به https://slurm.schedmd.com/preempt.html مراجعه کنید.

NOTE: به دلایل کارایی، زمان‌بند backfill کل گره‌ها را برای کارها رزرو می‌کند، نه بخش‌هایی از گره‌ها را. اگر در طول زمان‌بندی backfill یک کار بر یک یا چند کار دیگر پیش‌دستی کند، کل گره‌های مربوط به آن کارهای پیش‌دستی‌شده برای کار پیش‌دستی‌کننده (preemptor) رزرو می‌شوند، حتی اگر کار پیش‌دستی‌کننده منابع کمتری از آن درخواست کرده باشد. این گره‌های رزروشده در طول آن چرخه backfill در دسترس کارهای دیگر نخواهند بود، حتی اگر کارهای دیگر بتوانند روی آن گره‌ها جا شوند. بنابراین، کارها ممکن است در طول یک تکرار واحد backfill منابع بیشتری نسبت به آنچه درخواست کرده‌اند را پیش‌دستی کنند.
NOTE: برای اینکه یک کار ناهمگن (heterogeneous job) برای پیش‌دستی در نظر گرفته شود، تمام مولفه‌های آن باید واجد شرایط پیش‌دستی باشند. هنگامی که قرار است بر یک کار ناهمگن پیش‌دستی شود، اولین مولفه شناسایی‌شده از کار با بالاترین مرتبه PreemptMode (SUSPEND (بالاترین)، REQUEUE، CANCEL (پایین‌ترین)) برای تنظیم PreemptMode تمام مولفه‌ها استفاده خواهد شد. مقدار GraceTime و سیگنال هشدار کاربر برای هر مولفه از کار ناهمگن منحصر‌به‌فرد باقی می‌ماند. کارهای ناهمگن از عملیات زمان‌بندی GANG مستثنی هستند.

پیش‌دستی کار را غیرفعال می‌کند.
کار پیش‌دستی‌شده لغو خواهد شد.
با بازگرداندن کارها به صف (در صورت امکان) یا لغو آنها، پیش‌دستی را انجام می‌دهد. برای بازگرداندن کارها به صف، باید گزینه sbatch با نام --requeue تنظیم شده باشد یا پارامتر سراسری JobRequeue در slurm.conf روی 1 تنظیم شده باشد.
کارهای پیش‌دستی‌شده تعلیق خواهند شد و بعداً زمان‌بند Gang آنها را از سر خواهد گرفت. بنابراین حالت پیش‌دستی SUSPEND همیشه نیازمند این است که گزینه GANG در سطح خوشه مشخص شده باشد. همچنین، از آنجا که کارهای تعلیق‌شده همچنان از حافظه روی گره‌های تخصیص‌یافته استفاده می‌کنند، Slurm باید بتواند منابع حافظه را ردیابی کند تا بتواند کارها را تعلیق نماید.

اگر کارهای پیش‌دستی‌شونده و پیش‌دستی‌کننده روی پارتیشن‌های متفاوتی باشند، کارهای پیش‌دستی‌شده تا زمان پایان کار پیش‌دستی‌کننده در حالت تعلیق باقی خواهند ماند.
NOTE: از آنجا که زمان‌بندی گروهی (gang scheduling) به‌طور مستقل برای هر پارتیشن انجام می‌شود، در صورت استفاده از PreemptType=preempt/partition_prio، کارهای موجود در پارتیشن‌های با PriorityTier بالاتر، کارهای موجود در پارتیشن‌های با PriorityTier پایین‌تر را به حالت تعلیق درمی‌آورند تا روی منابع آزادشده اجرا شوند. تنها زمانی که کار پیش‌دستی‌کننده به پایان برسد، کارهای تعلیق‌شده توسط زمان‌بند Gang از سر گرفته خواهند شد.
NOTE: کارهای تعلیق‌شده GRES را آزاد نمی‌کنند. کارهای با اولویت بالاتر نمی‌توانند برای دسترسی به GRES پیش‌دستی کنند.

پیش‌دستی را تنها در صورتی مجاز می‌داند که اولویت کار پیش‌دستی‌کننده بالاتر از اولویت کار پیش‌دستی‌شونده باشد.
ضریب پارتیشن که توسط پلاگین priority/multifactor در محاسبه اولویت کار استفاده می‌شود. پیش‌فرض 1 است. مقدار 0 از افزودن این پارتیشن به اولویت کار جلوگیری می‌کند. مقدار نباید از 65533 تجاوز کند. همچنین به PriorityTier مراجعه کنید.
کارهای ارسال‌شده به پارتیشنی با مقدار PriorityTier بالاتر، پیش از کارهای معلق در پارتیشنی با مقدار PriorityTier پایین‌تر توسط زمان‌بند ارزیابی خواهند شد. آنها همچنین در صورت تنظیم PreemptType=preempt/partition_prio برای پیش‌دستی بر کارهای در حال اجرا در پارتیشن(های) با مقادیر PriorityTier پایین‌تر در نظر گرفته می‌شوند. مقدار نباید از 65533 تجاوز کند. همچنین به PriorityJobFactor مراجعه کنید.
برای گسترش محدودیت‌های موجود برای یک QOS در یک پارتیشن استفاده می‌شود. کارها فراتر از وابستگی به پارتیشن، به این QOS منتسب نخواهند شد. آنها همچنان به QOS درخواستی خود منتسب خواهند بود. به‌طور پیش‌فرض، از هیچ QOS استفاده نمی‌شود. جزئیات بیشتر در مستندات QOS در https://slurm.schedmd.com/qos.html موجود است، از جمله شرایط خاص زمانی که از یک QOS نسبی برای این پارامتر استفاده می‌شود. NOTE: اگر محدودیتی هم در QOS پارتیشن و هم در QOS کار تنظیم شده باشد، محدودیت QOS پارتیشن رعایت خواهد شد مگر اینکه QOS کار دارای پرچم OverPartQOS باشد، که در این صورت محدودیت QOS کار اولویت خواهد داشت.
مشخص می‌کند که آیا کاربران این پارتیشن هنگام ارسال کار موظف به تعیین یک رزرو (reservation) هستند یا خیر. این گزینه می‌تواند در محدود کردن استفاده از پارتیشنی که ممکن است اولویت بالاتری داشته باشد یا منابع اضافی داشته باشد، به طوری که فقط در قالب یک رزرو مجاز باشد، مفید باشد. مقادیر ممکن "YES" و "NO" هستند. مقدار پیش‌فرض "NO" است.
حداکثر زمان مجاز (به ثانیه) بین زمانی که درخواست ازسرگیری (resume) گره صادر می‌شود و زمانی که گره واقعاً برای استفاده در دسترس قرار می‌گیرد. گره‌هایی که نتوانند در این بازه زمانی پاسخ دهند به عنوان DOWN علامت‌گذاری می‌شوند و کارهای زمان‌بندی‌شده روی آن گره در صورت امکان دوباره به صف بازگردانده می‌شوند (requeued). گره‌هایی که پس از این بازه زمانی راه‌اندازی مجدد (reboot) شوند، به عنوان DOWN با دلیل "Node unexpectedly rebooted." علامت‌گذاری می‌شوند. برای گره‌هایی که در چندین پارتیشن با این گزینه تنظیم‌شده قرار دارند، بیشترین زمان اعمال خواهد شد. اگر روی هیچ پارتیشنی تنظیم نشده باشد، گره از مقدار ResumeTimeout تنظیم‌شده برای کل خوشه استفاده خواهد کرد. حداکثر مقدار 65533 یا INFINITE است.
مشخص می‌کند که آیا فقط شناسه کاربری صفر (یعنی کاربر root) یا SlurmUser مجاز به تخصیص منابع در این پارتیشن هستند یا خیر. مقادیر ممکن "YES" و "NO" هستند. مقدار پیش‌فرض "NO" است.
نوع تخصیص منبع مختص پارتیشن. این گزینه جایگزین مقدار سراسری SelectTypeParameters می‌شود. مقادیر پشتیبانی‌شده عبارتند از CR_Core، CR_Core_Memory، CR_Socket و CR_Socket_Memory. استفاده از این گزینه نیازمند آن است که مقدار سراسری سامانه برای SelectTypeParameters روی هر یک از چهار مقدار پشتیبانی‌شده که پیش‌تر ذکر شد تنظیم شده باشد؛ در غیر این صورت، مقدار مختص پارتیشن نادیده گرفته خواهد شد.
وضعیت پارتیشن یا در دسترس بودن برای استفاده. مقادیر ممکن عبارتند از "UP"، "DOWN"، "DRAIN" و "INACTIVE". مقدار پیش‌فرض "UP" است. همچنین کلمه کلیدی مرتبط "Alternate" را ببینید.
مشخص می‌کند که کارهای جدید می‌توانند در پارتیشن در صف قرار گیرند و کارها می‌توانند گره تخصیص داده شده و از پارتیشن اجرا شوند.
مشخص می‌کند که کارهای جدید می‌توانند در پارتیشن در صف قرار گیرند، اما کارهای در صف نمی‌توانند گره تخصیص داده شوند و از پارتیشن اجرا شوند. کارهایی که از قبل در پارتیشن در حال اجرا هستند به اجرای خود ادامه می‌دهند. کارها باید صراحتاً لغو شوند تا به پایان برسند.
مشخص می‌کند که هیچ کار جدیدی نمی‌تواند در پارتیشن در صف قرار گیرد (درخواست‌های ارسال کار با یک پیام خطا رد خواهند شد)، اما کارهایی که از قبل در صف پارتیشن هستند می‌توانند گره تخصیص داده شوند و اجرا شوند. همچنین مشخصات پارتیشن "Alternate" را ببینید.
مشخص می‌کند که هیچ کار جدیدی نمی‌تواند در پارتیشن در صف قرار گیرد و کارهایی که از قبل در صف هستند نیز نمی‌توانند گره تخصیص داده شوند و اجرا شوند. همچنین مشخصات پارتیشن "Alternate" را ببینید.
گره‌هایی که به مدت این تعداد ثانیه در وضعیت بیکار (idle) یا غیرفعال (down) باقی بمانند، توسط SuspendProgram در حالت ذخیره انرژی (power save) قرار می‌گیرند. برای گره‌هایی که در چندین پارتیشن با این گزینه تنظیم‌شده قرار دارند، بیشترین زمان اعمال خواهد شد. اگر روی هیچ پارتیشنی تنظیم نشده باشد، گره از مقدار SuspendTime تنظیم‌شده برای کل خوشه استفاده خواهد کرد. مقدار SuspendTime تنظیم‌شده در خط NodeName بر این مقدار در سطح پارتیشن تقدم دارد. تنظیم SuspendTime روی INFINITE، تعلیق گره‌ها در این پارتیشن را غیرفعال می‌کند. تنظیم SuspendTime روی هر مقداری به جز INFINITE (یا -1)، حالت ذخیره انرژی را فعال می‌کند.
حداکثر زمان مجاز (به ثانیه) بین زمانی که درخواست تعلیق گره صادر می‌شود و زمانی که گره خاموش می‌شود. در آن زمان، گره باید آماده باشد تا در صورت نیاز برای کار جدید، درخواست ازسرگیری (resume) برای آن صادر شود. برای گره‌هایی که در چندین پارتیشن با این گزینه تنظیم‌شده قرار دارند، بیشترین زمان اعمال خواهد شد. اگر روی هیچ پارتیشنی تنظیم نشده باشد، گره از مقدار SuspendTimeout تنظیم‌شده برای کل خوشه استفاده خواهد کرد.
نام توپولوژی تعریف‌شده در topology.yaml که توسط کارهای این پارتیشن استفاده می‌شود.
فهرستی جداشده با کاما از جفت‌های <TRES Type>=<Numeric Weight> که وزن‌های صورت‌حساب (billing weights) یک یا چند نوع TRES ردیابی‌شده (به AccountingStorageTRES مراجعه کنید) را تعریف می‌کند که در محاسبه میزان استفاده کار در این پارتیشن استفاده خواهد شد. مقدار استفاده حاصله هنگام محاسبه سهم منصفانه (fairshare) و هنگام اعمال محدودیت صورت‌حساب TRES روی کارها استفاده می‌شود. همچنین برای تنظیم مستقیم اولویت کار بر اساس استفاده از TRES به PriorityWeightTRES مراجعه کنید.

به‌طور پیش‌فرض، صورت‌حساب کارها بر اساس تعداد کل CPUهای تخصیص‌یافته محاسبه می‌شود (TRESBillingWeights="CPU=1").

برای جزئیات بیشتر به صفحه TRES مراجعه کنید: https://slurm.schedmd.com/tres.html

پیکربندی PowerAction یک برنامه نام‌گذاری‌شده برای اجرای راه‌اندازی مجدد گره (reboot)، روشن کردن (Resume) یا خاموش کردن (Suspend) ایجاد می‌کند. نام PowerAction را می‌توان به جای مسیر برنامه برای ResumeProgram، ResumeFailProgram، SuspendProgram یا RebootProgram استفاده کرد، و می‌توان آن را برای درخواست‌های فردی با گزینه "action" در "scontrol power" و "scontrol reboot" انتخاب کرد.

PowerAction=<name> Location=<slurmctld|slurmd> Program="<path> [arguments...]"

این پیکربندی شامل پارامترهای زیر است:

نام یکتا برای اقدام. این نامی است که توسط ResumeProgram، ResumeFailProgram، SuspendProgram، RebootProgram یا گزینه "action" در scontrol به آن ارجاع داده می‌شود.
محل اجرای برنامه را مشخص می‌کند و از مقادیر "slurmd" و "slurmctld" پشتیبانی می‌کند. مقدار "slurmctld" برنامه را روی کنترل‌کننده با عنوان SlurmUser اجرا می‌کند. مقدار "slurmd" برنامه را روی هر گره محاسباتی متاثر با عنوان SlurmdUser اجرا می‌کند.

NOTE: اقدامات روشن کردن (Power up) باید از "slurmctld" استفاده کنند، زیرا گره‌های خاموش‌شده نمی‌توانند اقدام "slurmd" را اجرا نمایند.

برنامه‌ای برای انجام وظیفه روشن کردن، خاموش کردن یا راه‌اندازی مجدد. آرگومان‌هایی که باید به برنامه ارسال شوند را می‌توان در این فیلد گنجاند. Slurm نام(های) گره‌های متاثر را به عنوان آرگومان پس از هر آرگومان مشخص‌شده توسط کاربر ارسال می‌کند. با Location=slurmd، متغیر SLURM_NODE_NAME نیز در محیط تنظیم می‌شود.

انواع مختلفی از گزینه‌های برنامه‌های prolog و epilog وجود دارند که با مجوزهای گوناگون و در زمان‌های مختلف اجرا می‌شوند. چهار گزینه‌ای که بیش از همه محتمل است مورد استفاده قرار گیرند عبارتند از: Prolog و Epilog (یک بار روی هر گره محاسباتی برای هر کار اجرا می‌شوند) به همراه PrologSlurmctld و EpilogSlurmctld (یک بار روی SlurmctldHost برای هر کار اجرا می‌شوند).

NOTE: خروجی استاندارد و پیام‌های خطا به طور معمول ذخیره نمی‌شوند. اگر می‌خواهید این اطلاعات حفظ شوند، خروجی و پیام‌های خطا را صراحتاً در یک مکان مناسب بنویسید.

NOTE: به‌طور پیش‌فرض اسکریپت Prolog تنها زمانی روی هر گره منفرد اجرا می‌شود که برای اولین بار یک گام کاری (job step) از یک تخصیص جدید را ببیند. این اسکریپت بلافاصله پس از اعطای تخصیص اجرا نمی‌شود. اگر هیچ گام کاری از یک تخصیص روی گره‌ای اجرا نشود، Prolog هرگز برای آن تخصیص اجرا نخواهد شد. این رفتار Prolog را می‌توان با پارامتر PrologFlags تغییر داد. از سوی دیگر، Epilog همیشه هنگام آزادسازی تخصیص، روی هر گره از آن تخصیص اجرا می‌شود.

اگر Epilog با شکست مواجه شود (یک کد خروج غیرصفر برگرداند)، این امر منجر به قرار گرفتن گره در وضعیت DRAIN خواهد شد. اگر EpilogSlurmctld با شکست مواجه شود (یک کد خروج غیرصفر برگرداند)، این مورد تنها در لاگ ثبت خواهد شد. اگر Prolog با شکست مواجه شود (یک کد خروج غیرصفر برگرداند)، این امر منجر به قرار گرفتن گره در وضعیت DRAIN و بازگرداندن کار به صف (requeued) خواهد شد. کار در وضعیت نگه‌داشته‌شده (held) قرار خواهد گرفت مگر اینکه nohold_on_prolog_fail در SchedulerParameters پیکربندی شده باشد. اگر PrologSlurmctld با شکست مواجه شود (یک کد خروج غیرصفر برگرداند)، این امر منجر به بازگرداندن کار به صف می‌شود تا در صورت امکان روی گره دیگری اجرا شود. تنها کارهای دسته‌ای (batch jobs) می‌توانند دوباره به صف بازگردانده شوند. کارهای تعاملی (salloc و srun) در صورت شکست PrologSlurmctld لغو خواهند شد. اگر slurmctld در حالی که PrologSlurmctld یا EpilogSlurmctld در حال اجرا هستند متوقف شود، اسکریپت با SIGKILL متوقف خواهد شد. هنگامی که slurmctld مجدداً راه‌اندازی شود، اسکریپت نیز دوباره راه‌اندازی خواهد شد.

اطلاعات مربوط به کار با استفاده از متغیرهای محیطی به اسکریپت ارسال می‌شود. برای مشاهده فهرست کاملی از متغیرهای محیطی، لطفاً راهنمای Prolog و Epilog را در https://slurm.schedmd.com/prolog_epilog.html ببینید.

از این برنامه می‌توان برای انجام اقدامات ویژه جهت پاکسازی فرایندهای غیرقابل توقف (unkillable) و/یا اطلاع‌رسانی به مدیران سیستم استفاده کرد. برنامه با عنوان SlurmdUser (معمولاً "root") روی گره محاسباتی که UnkillableStepTimeout در آن فعال شده است، اجرا خواهد شد.

اطلاعات مربوط به گام کاری غیرقابل توقف با استفاده از متغیرهای محیطی به اسکریپت ارسال می‌شود.

شناسه کار (Job ID).
شناسه SLUID کار.
شناسه گام کاری (Job Step ID). توجه داشته باشید که گام‌های ویژه "batch"، "interactive" و "extern" نه با نام بلکه با شناسه‌های گام عدد صحیح به ترتیب 4294967291، 4294967290 و 4294967292 گزارش می‌شوند.

اسلورم (Slurm) قادر است تخصیص‌های کار را برای به حداقل رساندن تداخل و رقابت در شبکه (network contention) بهینه‌سازی کند. منطق ویژه‌ای در Slurm برای بهینه‌سازی تخصیص‌ها روی سامانه‌های دارای اتصال متقابل سه‌بعدی (three-dimensional interconnect) استفاده می‌شود و اطلاعات مربوط به پیکربندی این سامانه‌ها در صفحات وب موجود در اینجا در دسترس است: https://slurm.schedmd.com/. برای یک شبکه سلسله‌مراتبی، Slurm نیاز به اطلاعات دقیق در مورد نحوه پیکربندی گره‌ها روی سوئیچ‌های شبکه دارد.

پارامتر TopologyPlugin کنترل می‌کند که از کدام پلاگین برای جمع‌آوری اطلاعات توپولوژی شبکه استفاده شود. تنها مقادیری که در حال حاضر پشتیبانی می‌شوند عبارتند از "topology/flat" (منطق بهترین برازش روی توپولوژی یک‌بعدی)، "topology/tree" و "topology/block" (هر دو توپولوژی شبکه را بر اساس اطلاعات موجود در یک فایل topology.conf یا topology.yaml تعیین می‌کنند، برای اطلاعات بیشتر به "man topology.conf" و "man topology.yaml" مراجعه کنید). پلاگین‌های آینده ممکن است اطلاعات توپولوژی را مستقیماً از شبکه جمع‌آوری کنند. اطلاعات توپولوژی اختیاری است. در صورت عدم ارائه، Slurm یک الگوریتم بهترین برازش (best-fit) را با این فرض انجام می‌دهد که گره‌ها همان‌طور که پیکربندی شده‌اند در یک آرایه یک‌بعدی قرار دارند و هزینه ارتباطات به فاصله گره‌ها در این آرایه مرتبط است.

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

1. دیمن‌های Slurm را روی کنترل‌کننده قدیمی و گره‌ها متوقف کنید.
2. فایل slurm.conf را به طور مناسب اصلاح کنید.
3. فایل‌ها را از StateSaveLocation به کنترل‌کننده جدید کپی کنید یا اطمینان حاصل کنید که از طریق یک درایو مشترک برای کنترل‌کننده جدید قابل دسترسی هستند.
4. فایل slurm.conf به‌روزشده را بین تمام گره‌ها توزیع کنید.
5. دیمن‌های Slurm را روی کنترل‌کننده جدید و گره‌ها مجدداً راه‌اندازی کنید.

نباید هیچ‌یک از کارهای در صف انتظار از بین بروند. هر کار در حال اجرا اطلاعات به‌روزشده میزبان را دریافت کرده و به طور عادی به پایان خواهد رسید. اطمینان حاصل کنید که هر گره‌ای که به خوشه اضافه می‌شود، فایل slurm.conf فعلی را نصب داشته باشد.

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

#
# نمونه /etc/slurm.conf برای dev[0-25].llnl.gov
# Author: John Doe
# Date: 11/06/2001
#
SlurmctldHost=dev0(12.34.56.78)  # Primary server
SlurmctldHost=dev1(12.34.56.79)  # Backup server
#
AuthType=auth/munge
Epilog=/usr/local/slurm/epilog
Prolog=/usr/local/slurm/prolog
FirstJobId=65536
InactiveLimit=120
JobCompType=jobcomp/filetxt
JobCompLoc=/var/log/slurm/jobcomp
KillWait=30
MaxJobCount=10000
MinJobAge=300
PluginDir=/usr/local/lib:/usr/local/slurm/lib
ReturnToService=0
SchedulerType=sched/backfill
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdLogFile=/var/log/slurm/slurmd.log
SlurmctldPort=7002
SlurmdPort=7003
SlurmdSpoolDir=/var/spool/slurmd.spool
StateSaveLocation=/var/spool/slurm.state
TmpFS=/tmp
WaitTime=30
#
# Node Configurations
#
NodeName=DEFAULT CPUs=2 RealMemory=2000 TmpDisk=64000
NodeName=DEFAULT State=UNKNOWN
NodeName=dev[0-25] NodeAddr=edev[0-25] Weight=16
# Update records for specific DOWN nodes
DownNodes=dev20 State=DOWN Reason="power,ETA=Dec25"
#
# Partition Configurations
#
PartitionName=DEFAULT MaxTime=30 MaxNodes=10 State=UP
PartitionName=debug Nodes=dev[0-8,18-25] Default=YES
PartitionName=batch Nodes=dev[9-17]  MinNodes=4
PartitionName=long Nodes=dev[9-17] MaxTime=120 AllowGroups=admin

کلمه کلیدی "include" می‌تواند با اصلاح‌کننده‌ها (modifiers) در مسیر مشخص‌شده استفاده شود. این اصلاح‌کننده‌ها بسته به اینکه کدام اصلاح‌کننده مشخص شده است با نام خوشه یا سایر اطلاعات جایگزین می‌شوند. اگر فایل گنجانده‌شده یک مسیر مطلق نباشد (یعنی با یک اسلش شروع نشود)، باید نسبت به دایرکتوری حاوی فایل slurm.conf باشد.

%c
نام خوشه مشخص‌شده در slurm.conf استفاده خواهد شد.

EXAMPLE

ClusterName=linux
include /home/slurm/etc/%c_config
# خط فوق به صورت زیر تفسیر می‌شود:
# "include /home/slurm/etc/linux_config"

سه دسته از فایل‌ها وجود دارند: فایل‌های مورد استفاده توسط slurmctld باید توسط کاربر SlurmUser قابل دسترسی باشند و توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشند. فایل‌های مورد استفاده توسط slurmd باید توسط کاربر root قابل دسترسی باشند و از هر گره محاسباتی قابل دسترسی باشند. تعداد کمی از فایل‌ها باید توسط کاربران عادی در تمام گره‌های ورود (login) و محاسباتی قابل دسترسی باشند. در حالی که فایل‌ها و دایرکتوری‌های متعددی در زیر فهرست شده‌اند، بیشتر آنها در بیشتر پیکربندی‌ها استفاده نخواهند شد.

باید توسط کاربر root قابل اجرا باشد. توصیه می‌شود که فایل توسط همه کاربران قابل خواندن باشد. فایل باید روی هر گره محاسباتی وجود داشته باشد.
باید توسط کاربر SlurmUser قابل اجرا باشد. توصیه می‌شود که فایل توسط همه کاربران قابل خواندن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر root قابل اجرا باشد. توصیه می‌شود که فایل توسط همه کاربران قابل خواندن باشد. فایل باید روی هر گره محاسباتی وجود داشته باشد.
اگر این پارامتر یک فایل را مشخص کند، باید توسط کاربر SlurmUser قابل نوشتن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر SlurmUser قابل اجرا باشد. نباید توسط کاربران عادی قابل نوشتن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
اگر Location=slurmd باشد، Program باید توسط کاربر SlurmdUser قابل اجرا باشد و روی تمام گره‌های محاسباتی قابل دسترسی باشد.

اگر Location=slurmctld باشد، Program باید توسط کاربر SlurmUser قابل اجرا باشد و توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.

باید توسط کاربر root قابل اجرا باشد. توصیه می‌شود که فایل توسط همه کاربران قابل خواندن باشد. فایل باید روی هر گره محاسباتی وجود داشته باشد.
باید توسط کاربر SlurmUser قابل اجرا باشد. توصیه می‌شود که فایل توسط همه کاربران قابل خواندن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر SlurmUser قابل اجرا باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
برای همه کاربران در همه گره‌ها قابل خواندن است. نباید توسط کاربران عادی قابل نوشتن باشد.
باید توسط کاربر SlurmUser قابل نوشتن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر root قابل نوشتن باشد. ترجیحاً توسط SlurmUser قابل نوشتن و حذف باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر root قابل نوشتن باشد. یک فایل متمایز باید روی هر گره محاسباتی وجود داشته باشد.
باید توسط کاربر root قابل نوشتن باشد. یک فایل متمایز باید روی هر گره محاسباتی وجود داشته باشد.
باید توسط کاربر root قابل نوشتن باشد. دسترسی‌ها باید روی 755 تنظیم شوند تا اسکریپت‌های کار بتوانند از این دایرکتوری اجرا شوند. یک فایل متمایز باید روی هر گره محاسباتی وجود داشته باشد.
باید توسط همه کاربران قابل اجرا باشد. فایل باید روی هر گره ورود و محاسباتی وجود داشته باشد.
باید توسط همه کاربران قابل اجرا باشد. فایل باید روی هر گره ورود و محاسباتی وجود داشته باشد.
باید توسط کاربر SlurmUser قابل نوشتن باشد. فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط کاربر SlurmUser قابل اجرا باشد. این فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.
باید توسط همه کاربران قابل اجرا باشد. این فایل باید در تمام گره‌های محاسباتی وجود داشته باشد.
باید توسط همه کاربران قابل اجرا باشد. این فایل باید در تمام گره‌های محاسباتی وجود داشته باشد.
باید توسط کاربر SlurmdUser قابل اجرا باشد. این فایل باید توسط ماشین‌های کنترل اصلی و پشتیبان قابل دسترسی باشد.

توجه داشته باشید اگرچه دیمن‌های Slurm فایل‌های گزارش و سایر فایل‌ها را بر حسب نیاز ایجاد می‌کنند، اما عدم وجود دایرکتوری‌های والد را به عنوان یک خطای مهلک در نظر می‌گیرند. این کار از اجرای دیمن‌ها در صورتی که سیستم‌های فایل حیاتی سوار (mount) نشده باشند جلوگیری کرده و خطر راه‌اندازی سرد (cold-starting - شروع به کار بدون حفظ کارها) را به حداقل می‌رساند.

فایل‌های گزارش و فایل‌های حسابداری کارها ممکن است برای دسترسی موفقیت‌آمیز، نیاز به ایجاد شدن/مالکیت توسط شناسه کاربری (uid) «SlurmUser» داشته باشند. از دستورات «chown» و «chmod» برای تنظیم مناسب مالکیت و مجوزها استفاده کنید. برای اطلاعات درباره فایل‌ها و دایرکتوری‌های مختلف مورد استفاده توسط Slurm به بخش FILE AND DIRECTORY PERMISSIONS مراجعه کنید.

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

در اینجا یک نمونه پیکربندی logrotate آورده شده است. تغییرات متناسب با سیستم خود را اعمال کرده و آن را در تمام گره‌ها به عنوان /etc/logrotate.d/slurm ذخیره کنید. برای جزئیات بیشتر به صفحه راهنمای logrotate مراجعه کنید.

##
# Slurm Logrotate Configuration
##
/var/log/slurm/*.log {
	compress
	missingok
	nocopytruncate
	nodelaycompress
	nomail
	notifempty
	noolddir
	rotate 5
	sharedscripts
	size=5M
	create 640 slurm root
	postrotate
		pkill -x --signal SIGUSR2 slurmctld
		pkill -x --signal SIGUSR2 slurmd
		pkill -x --signal SIGUSR2 slurmdbd
		exit 0
	endscript
}

Copyright (C) 2002-2007 The Regents of the University of California. Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER).
Copyright (C) 2008-2010 Lawrence Livermore National Security.
Copyright (C) 2010-2022 SchedMD LLC.

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

نرم‌افزار Slurm یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط مجوز عمومی همگانی گنو (GNU General Public License) همان‌گونه که توسط بنیاد نرم‌افزارهای آزاد (Free Software Foundation) منتشر شده است؛ چه نسخه ۲ مجوز یا (به انتخاب خودتان) هر نسخه بعدی، بازتوزیع کرده و/یا تغییر دهید.

نرم‌افزار Slurm با این امید که مفید واقع شود توزیع شده است، اما بدون هرگونه ضمانت؛ حتی بدون ضمانت ضمنی قابل فروش بودن (MERCHANTABILITY) یا تناسب برای یک هدف خاص (FITNESS FOR A PARTICULAR PURPOSE). برای جزئیات بیشتر به GNU General Public License مراجعه کنید.

/etc/slurm.conf

cgroup.conf(5), getaddrinfo(3), getrlimit(2), gres.conf(5), group(5), hostname(1), scontrol(1), slurmctld(8), slurmd(8), slurmdbd(8), slurmdbd.conf(5), srun(1), spank(8), syslog(3), topology.conf(5)

پرونده پیکربندی اسلورم Slurm 26.05