Hi, Am 15.05.2013 um 18:10 schrieb Nicolás Serrano Martínez Santos:
> I have not tried it, but I think you can define a queue per user and the make > this user the owner of the queue. This way they could modify their queues, > and thus > the number of processes. However it seems insecure, they can change a lot of > stuff, > and you have to control the number of jobs per host in another way (maybe a > consumable). To elaborate: it grants the ability to disable resp. suspend a queue(-instance). Besides getting many queues in the system, I don't think that it's a security problem. -- Reuti > NiCo > > Excerpts from Txema Heredia Genestar's message of mié may 15 17:23:53 +0200 > 2013: >> El 15/05/13 14:58, William Hay escribió: >>> >>> On 15 May 2013 13:32, Txema Heredia Genestar <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi all, >>> >>> I was wondering if there is any way to allow a user to choose how many >>> jobs they want to have running concurrently in the cluster. I am aware >>> that I, as an administrator, can specify limits in the slot usage for >>> each user whith resource quota sets. >>> What I am asking is a method to allow a user to submit, for instance, >>> 2000 jobs, but having only 50 running simultaneously, and, two days >>> later, be able to run 400 jobs at once. >>> Currently I am using a consumable attribute set to the total number of >>> cores of our cluster (400), so users can request some number (400 >>> / 50 = >>> 8) in order to have their desired simultaneous job, but this leads to >>> some confusion and applies to all users at once (the consumable >>> attribute pool is shared among all users). >>> >>> Is there a fast-and-easy way a user can set his own limit? >>> >>> Per user resource quota on the consumable? Use some wrapper >>> scripts/jsv to do the maths. >>> >> What do you mean by "per-user resource quota on the consumable"? >> >> Do you mean creating a resource quota for the global consumable >> attribute so a user can only request a given number? That would only >> make all users compete for the same, with further restrictions. >> >> The more I think about it, the more I realize of the problems that what >> I request imply: The "number of simultaneous jobs" cannot be requested >> by job, as it depends of the system as a whole, and any workaround I >> think about, implies granting users managing privileges. >> >> Maybe a solution would be out-SGE: I could create a script in crontab >> that reads one file where I store all RQS, and also reads, say, >> ~/.sge_rqs for each user, granting to each user a slots limit of the >> minimum of the 2 files... > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
