Fri, 18 Jan 2013 08:41:09 +0000 > -----Ursprüngliche Nachricht----- > Von: Corey Wright [mailto:undefined@pobox.com] > On Thu, 17 Jan 2013 08:43:21 +0000 > Fiedler Roman <Roman.Fiedler@ait.ac.at> wrote: > > > Hello List, > > > > What would be the most suitable solution to avoid high load/overlong cron > job execution for hourly/daily/... jobs? When using similar vservers, all of > them would start those jobs at the same time. > > depends (imho): > > providing/using a hosting service and want guarantees? cgroup blkio > controller. > cooperative administration of vservers? nice and/or ionice. > "poor man's" approach? ${RANDOM}. So many ways to do it .... Perhaps we should add a link to this discussion in the FAQs page. > i haven't tested/used the cgroup's blkio controller, but in theory that's > what it's suppose to do (cgroup's other controllers work for me). OK, I will look on this one too. > > Currently I'm using a script on the host to run no more than N guest > hourly/daily/... jobs in parallel. > > i presume you are administering them on your own and/or somebody else's > behalf and can schedule them cooperatively. Right > i wouldn't expect this level of > cooperation from/among users of a hosting service (ie system administration > by committee). I was thinking about that problem also to see if there could be a more "generic" solution. The basic reasoning for un-cooperative usecase was: * Since no "nice" cooperation, provider and consumer are linked via contract and SLAs only * Contract guarantees number of CPU-cycles/IO-ops per timeslice, e.g. >0.1 CPU-core-equivalent * Consumer can run jobs at any time, no cooperation but he can rely to get at least guaranteed execution speed * Provider must at least provide n(guests) * minGuarantee resources or do optimization gambling to go with less Hence in this case, all that the host implementation could do is to ensure that host-resources are available and per-guest quotas are not exceeded. I would expect, that on such a setup much of the resources would be idle due to large resource reserve, that has to be kept. > i do cooperative scheduling of some jobs and do it sequentially on each > vserver from the host, but that's because i'm the only administrator/user of > my vservers and host them myself (and it's simple/stupid). > > if i was using a vserver provided by someone else (eg hosting service), then > i would either expect them to provide guaranteed io throughput (just like for > cpu and memory) or i'd randomize it myself (based on how much i was paying; > poor man's solution). Also my opinion, except that it might be hard to handle "randomization" in SLAs accordingly. > i've already seen randomizing as a solution to not overloading resources > among controlled but uncoordinated systems: system/virus updates are > randomly > staggered on corporate desktops so as to not overload the server and/or > congest the network. Seems the best way for jobs with quite some resource consumption but run seldomly and where exact execution time is not so much an issue.