Dave,
I have done testing on 5-6 year old hardware with 100,000 users randomly
distributed in 10,000 accounts with semi-random depths with most being
between 1-4 levels from root but some much deeper than that, plus
100,000 jobs pending. slurmctld startup time was really long but, after
getting started, fairshare and decay iterations in all fairshare
algorithms took 50-150 milliseconds depending on how you measure it.
Those calculations run no more frequently than once per minute and can
be configured to run less frequently.
You shouldn't have any problems.
Ryan
On 11/18/2014 12:30 PM, David Lipowitz wrote:
How many accounts can SLURM support?
Does anyone have a sense of how far SLURM scales regarding accounts
and sub-accounts?
In our batch environment, all jobs need to run under the same service
account for a number of reasons (which I won't go into here). Since
our scheduler knows which end user is actually submitting the job,
we'd like to handle prioritization by creating sub-accounts for each
user under each of the leaf accounts depicted below:
root
|
+- query
| |
| +- type_a
| |
| +- type_b
| |
| +- type_c
| |
| +- type_d
|
+- process
So I'd have five accounts, one for each type of query and another for
the process account:
query_type_a_dlipowitz
query_type_b_dlipowitz
query_type_c_dlipowitz
query_type_d_dlipowitz
process_dlipowitz
And each other user would have five analogous accounts.
Given that we have 600 users, can SLURM handle 3000 sub-accounts like
this? If we doubled in size, could SLURM handle 6000?
Thanks for any insight you might be able to offer.
Cheers,
Dave
