Hi, Am 15.03.2013 um 16:32 schrieb Gowtham:
> I'm trying to experiment with the share tree policy on our test clusters > running Rocks 6.1 (CentOS 6.3) and Grid Engine 2011.11p1. I'd like this > policy to treat users as if they were all *not* created equally. To that > effect, I have done the following so far: > > > #1. SGE configuration (via qconf -mconf) > > http://sgowtham.net/downloads/rocks61_ge201111p1_qconf_sconf.txt > > > #2. Scheduler configuration (via qconf -msconf) > > http://sgowtham.net/downloads/rocks61_ge201111p1_qconf_ssconf.txt > > > #3. The cluster has 4 users: amy, bob, john, karen. > For each one of these users, I have added a user object > via the command > > qconf -Auser USERNAME.txt > > and the contents of USERNAME.txt look like > > name USERNAME > oticket 0 > fshare 0 > delete_time 0 > default_project NONE > > > #4. Suppose that the 'share' of each one of these users is > as follows: > > amy 4000 40% > bob 1000 10% > john 1000 10% > karen 4000 40% > TOTAL 10000 > > and is included in a file > > http://sgowtham.net/downloads/rocks61_ge201111p1_share_tree_policy.txt > > Then, I ran > > qconf -Mstree rocks61_ge201111p1_share_tree_policy.txt > > to implement the Share Tree Policy. > > > I hope my work flow in Steps #1 - #4 are correct. > > > With that, I do have the following questions: > > #1. Does the above set up *guarantee* that 'amy' will have > access to 40% of the cluster's resources, 'bob' will > have access to 10% of the cluster's resources, over a > period of time ('halftime'?) It can't guarantee this. Suppose only 'amy' is using the cluster during these 28 days. She got 100% then. Even if the other users step in on the very last day of the 28 days period: they can't catch up to get these distribution of resources which was intended (controlled by the "compensation_factor" in the scheduler configuration to catch up with the targeted resource distribution). There would be a machanism necessary to block 'amy' if her 40% were used up. > #2. Suppose that this policy has been in place 28 days > (equal to the 'halftime' parameter in scheduler configuration). > > > #3. For some inexplicable reason (e.g., bad behavior, not > paying the $$, etc.), suppose that bob's new share is 0. > That is, > > amy 4500 45% > bob 0 0% > john 1000 10% > karen 4500 45% > TOTAL 10000 > > So, I update the rocks61_ge201111p1_share_tree_policy.txt > with these new shares and run > > qconf -Mstree rocks61_ge201111p1_share_tree_policy.txt > > to implement the new Share Tree Policy. > > > #4. If #1 is true, will the new 'share' layout mean that any newer > jobs submitted by 'bob' will just wait in 'qw' mode forever? > > If yes, awesome. The priority is a result of many settings (`man sge_priority`). If you setup the overall priority to honor only the share tree (by adjusting the several "weight_*" entries), it will work as long as there are jobs in the cluster. But as soon as only jobs of the bad user are left, they will start. > If not, how do I make sure that it happens - without really > removing bob's account from the cluster OR making him part of > a 'bad dudes' users list that is not allowed to run anything > in any queue/host via RQS? a) xuser_lists in SGE's configuration. b) a JSV to block these user's jobs -- Reuti > Thanks for your time and help. > > > Best regards, > g > > -- > Gowtham, PhD > Information Technology Services > Adj. Assistant Professor, Physics > Michigan Technological University > > (906) 487/3593 > http://it.mtu.edu/ > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
