> Am 30.05.2017 um 15:44 schrieb [email protected]: > > Hi, > > It seems there was a problem with fshare values for user3 and user1. It was > set to 0, while user2 had a value of 10. > Once we reset the values, the problem has been resolved.
If the user existed already beforehand (by `qconf -auser …`) as you intend to use the share-tree policy which honors the past usage (this "user" object will store the past usage to implement the share-tree policy and must hence exist), then the fshare value therein will stay as it was entered. In this case also the "delete_time" must be zero, so that no past usage history is ever lost. If the user entries (which you can check with `qconf -suserl`) are created automatically by "auto_user_fshare 100" for the functional-policy, then this value will be used if and only if there was no former record for this user. Whether the "delete_time" is zero or not doesn't matter, as the record would automatically be recreated if becomes necessary. As a side effect: if a user is created automatically with an fshare value of e.g. 5000 and you change the setting to "auto_user_fshare 100" because you want to test another set up: this will not change the value of the already created record for this user. Only if the user has a gap in his submissions and reached the "delete_time" of his record, then the next time the record is recreated it will get the new value from your setting of course. For now you could just delete all individual entries with `qconf -duser <USER>` after each change of the "auto_user_fshare". All newly created records should get the new value then. -- Reuti > But I have a doubt, is there any way to automatically reset the fshare value > of a user based on the global configuration rather than manually resetting it > ? > > Thanks and regards, > Srinivas. > > -----Original Message----- > From: Srinivas Nallani Chakravathi (Product Engineering Service) > Sent: Tuesday, May 30, 2017 6:13 PM > To: 'Reuti' <[email protected]> > Cc: [email protected] > Subject: RE: [gridengine users] Help with fair share scheduling > > Hi, > > I have tried the settings. But there seems to be a few anomalies. It would > be better if we can assign job priorities based on the number of jobs that > belong to a user, i.e, jobs from user with fewer number of jobs can have > higher priority compared to jobs from users with large number of jobs. > > As an example, we have submitted a 25 test jobs from user1 account, 25 test > jobs from user2 account and 1 job from user3 account. > > Ideally, we would want user3 to get some higher priority for his job, but we > have observed that jobs from user2 seems to be scheduled first, followed by > user1 jobs and user3 has his job scheduled last. > > Thanks and regards, > Srinivas. > > -----Original Message----- > From: Reuti [mailto:[email protected]] > Sent: Tuesday, May 30, 2017 5:27 PM > To: Srinivas Nallani Chakravathi (Product Engineering Service) > <[email protected]> > Cc: [email protected] > Subject: Re: [gridengine users] Help with fair share scheduling > > ** This mail has been sent from an external source. Treat hyperlinks and > attachments in this email with caution** > > Hi, > > you can try to use these adjustments: > >> Am 30.05.2017 um 12:42 schrieb [email protected]: >> >> Hi, >> >> We are using the below scheduler configuration . >> >> algorithm default >> schedule_interval 0:0:15 >> maxujobs 0 >> queue_sort_method load >> job_load_adjustments np_load_avg=0.50 >> load_adjustment_decay_time 0:7:30 >> load_formula np_load_avg >> schedd_job_info true >> flush_submit_sec 0 >> flush_finish_sec 0 >> params MONITOR=1 >> reprioritize_interval 0:0:0 >> halftime 4 >> usage_weight_list cpu=1.000000,mem=0.000000,io=0.000000 >> compensation_factor 5.000000 >> weight_user 0.250000 >> weight_project 0.250000 >> weight_department 0.250000 >> weight_job 0.250000 >> weight_tickets_functional 10000 >> weight_tickets_share 10000000 > > weight_user 0.900000 > weight_project 0.000000 > weight_department 0.000000 > weight_job 0.100000 > weight_tickets_functional 100000 > weight_tickets_share 0 > > >> share_override_tickets TRUE >> share_functional_shares TRUE >> max_functional_jobs_to_schedule 200 >> report_pjob_tickets TRUE >> max_pending_tasks_per_job 50 >> halflife_decay_list none >> policy_hierarchy OFS > > policy_hierarchy F > > >> weight_ticket 1.000000 >> weight_waiting_time 0.010000 >> weight_deadline 0.000000 >> weight_urgency 0.100000 >> weight_priority 0.000000 >> max_reservation 0 >> default_duration INFINITY > > -- Reuti > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. WARNING: Computer viruses can be transmitted via > email. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email. www.wipro.com > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
