On Tue, Aug 06, 2019 at 05:19:14PM +0200, Philipp Kern wrote: > On 2019-08-06 13:43, Bill Allombert wrote: > > On Mon, Aug 05, 2019 at 10:29:41PM +0200, Philipp Kern wrote: > > > And finally, the load spikes: Upthread it was mentioned that > > > RandomizedDelaySec exists. Generally this should be sufficient to > > > even out > > > such effects. I understand that there is a case where you run a lot of > > > unrelated VMs that you cannot control. In other cases, like laptops > > > and > > > desktops, it is very likely much more efficient to generate the load > > > spike > > > and complete the task as fast as possible in order to return to the > > > low-power state of (effectively) waiting for input. > > > > This assumes the system has enough RAM and other ressources to complete > > all the jobs in parallel. > > We are talking about cron.*. I feel like that's more of a scheduling > problem. If you run a constrained machine, I'm sure you are already doing > customization to accommodate to the shortage and you would not want the > background cron jobs to kill your production workload?
One background cron job at once might be OK, all at once less so, even on a full server. Some of the cron jobs are IO intensive, some other RAM intensive (think updatedb, Web indexing software like xapian-omega etc). Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
