John Thank you! and your explanation is very much what I use to explain it to my folks. Whether they internalize it or require repetition is another matter, as I'm sure you know.
What I have is a small group of users, each with the same fair share allocated. I have one user with a lot of small jobs, cycling roughly every 5 minutes, into the queue. What we encountered was, his small jobs, with lower wall-clock specs (more reasonable than other users' requests) would slide in, regardless of a rather large backlog of other users with a fairshare value set in sacctmgr identical to the problem child. Worse, a user with a higher fairshare value (higher priority; a real operational code) was waiting while the problem-user had jobs slide into place. I suspect there's a bit of minutia I've missed in the config. I have to localize that and fix it. gerry On Sun, Aug 30, 2015 at 9:46 AM, John Hanks <[email protected]> wrote: > Gerry, > > I'm going to throw an answer out, but it's mostly opinion and conjecture. > However, it's how I have explained fairshare to my users and boss, so if > it's wrong, don't tell them. > > The goal of fairshare is to have high overall utilization and prevent a > single user/group from using more resources than are "fair" over time. Note > the very important "over time" in there. If a user is the only person > submitting jobs, we want them to have 100% of the machine. As soon as a > second user comes along, their fairshare should be higher than the first > user and as the first users jobs complete then the second users jobs will > start. If they both continue to submit jobs then over time we would expect > both users utilization to be about 50% of the available resources. In > short, fairshare isn't about what the machine is doing Right Now(tm) but > more about what it has been doing over the previous period of time equal to > the fairshare calculation window. > > The ways in which we mitigate the effects on Right Now(tm) are: > > - Reservations for specific projects to guarantee a minimum set of > resources available. > - A small interactive partition with limits on how much 1 person can use > and short max walltime (relative to other resources.) > - Repeating the explanation verbatim to the users who ask about this > every time they are in a hurry to get a job running. > > I'd love to hear how other people address this in different environments. > We are slowly migrating away from dividing things with partitions and > toward using QoS and fairshare to control access. Examples of different > approaches would be appreciated. > > Regards, > > jbh > > > -- Gerry Creager NSSL/CIMMS 405.325.6371 ++++++++++++++++++++++ “Big whorls have little whorls, That feed on their velocity; And little whorls have lesser whorls, And so on to viscosity.” Lewis Fry Richardson (1881-1953)
