@@ -13,18 +13,17 @@ Scenario
13
13
14
14
There are two user profiles:
15
15
16
- * Users that submit jobs on behalf of themselves. For instance normal analysis
17
- users.
18
- * Users that submit jobs on behalf of the group. For instance production users.
16
+ 1. Users that submit jobs on behalf of themselves. For instance normal analysis users.
17
+ 2. Users that submit jobs on behalf of a group. For instance production users.
19
18
20
- In the first case, users are competing for resources, and on the second case users
21
- share them. But this two profiles also compete against each other. DIRAC has to
19
+ In the first case, users are competing for resources, and in the second case users
20
+ share them. But these two profiles also compete against each other. DIRAC has to
22
21
provide a way to share the resources available. On top of that users want to specify
23
22
a "UserPriority" to their jobs. They want to tell DIRAC which of their own jobs
24
- should run first and which should ran last.
23
+ should run first and which should run last.
25
24
26
- DIRAC implements a priority schema to decide which user gets to run in each moment
27
- so a fair share of CPU is kept between the users.
25
+ DIRAC implements a priority schema to decide which user gets to run in each moment
26
+ so a fair share is maintained between the users.
28
27
29
28
-------------------------
30
29
Priority implementation
@@ -37,7 +36,8 @@ DIRAC only has to prioritize *TaskQueues*.
37
36
To handle the users competing for resources, DIRAC implements a group priority.
38
37
Each DIRAC group has a priority defined. This priority can be shared or divided
39
38
amongst the users in the group depending on the group properties. If the group has
40
- the *JOB_SHARING * property the priority will be shared, if it doesn't have it the
39
+ the *JOB_SHARING * property (see :py:mod: `~DIRAC.Core.Security.Properties ` module)
40
+ the priority will be shared, and if it doesn't the
41
41
group priority will be divided amongst them. Each *TaskQueue * will get a priority
42
42
based on the group and user it belongs to:
43
43
@@ -46,8 +46,40 @@ based on the group and user it belongs to:
46
46
* If it does *NOT *, it will get 1/(N*U) being U the number of users in the group
47
47
with waiting jobs and N the number of *TaskQueues * of that user/group combination.
48
48
49
- On top of that users can specify a "UserPriority" to their jobs. To reflect that,
50
- DIRAC modifies the *TaskQueues * priorities depending on the "UserPriority" of the
49
+ Administrators can set different job shares depending on the user's group that runs the jobs,
50
+ by setting the *JobShare * option in the Configuration, in the groups definitions. For example::
51
+
52
+ lhcb_user # All LHCb users
53
+ {
54
+ Users = aaa
55
+ ...
56
+ Users += zzz
57
+ Properties = NormalUser
58
+ Properties += PrivateLimitedDelegation
59
+ JobShare = 10000
60
+
61
+ }
62
+ ....
63
+ lhcb_mc # this is for MonteCarlo simulations
64
+ {
65
+ Users = ...
66
+ Properties = NormalUser
67
+ Properties += JobSharing
68
+ Properties += ProductionManagement
69
+ JobShare = 300
70
+ }
71
+ ....
72
+ lhcb_data # this is for real data productions
73
+ {
74
+ Users = ...
75
+ Properties = NormalUser
76
+ Properties += JobSharing
77
+ Properties += ...
78
+ JobShare = 40000
79
+ }
80
+
81
+ On top of that production administrators can specify a different "priority" to different productions.
82
+ To reflect that, DIRAC modifies the *TaskQueues * priorities depending on the "priority" of the
51
83
jobs in each *TaskQueue *. Each *TaskQueue * priority will be P*J being P the
52
84
*TaskQueue * priority. J is the sum of all the "UserPriorities" of the jobs inside
53
85
the *TaskQueue * divided by the sum of sums of all the "UserPiorities" in the jobs
0 commit comments