mirror of
https://git.proxmox.com/git/pve-manager
synced 2025-04-28 16:36:30 +00:00
6385fb8183
The whole thing is already prepared for this, the systemd timer was just a fixed periodic timer with a frequency of one minute. And we just introduced it as the assumption was made that less memory usage would be generated with this approach, AFAIK. But logging 4+ lines just about that the timer was started, even if it does nothing, and that 24/7 is not to cheap and a bit annoying. So in a first step add a simple daemon, which forks of a child for running jobs once a minute. This could be made still a bit more intelligent, i.e., look if we have jobs tor run before forking - as forking is not the cheapest syscall. Further, we could adapt the sleep interval to the next time we actually need to run a job (and sending a SIGUSR to the daemon if a job interval changes such, that this interval got narrower) We try to sync running on minute-change boundaries at start, this emulates systemd.timer behaviour, we had until now. Also user can configure jobs on minute precision, so they probably expect that those also start really close to a minute change event. Could be adapted to resync during running, to factor in time drift. But, as long as enough cpu cycles are available we run in correct monotonic intervalls, so this isn't a must, IMO. Another improvement could be locking a bit more fine grained, i.e. not on a per-all-local-job-runs basis, but per-job (per-guest?) basis, which would improve temporary starvement of small high-periodic jobs through big, less peridoci jobs. We argued that it's the user fault if such situations arise, but they can evolve over time without noticing, especially in compolexer setups. Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> |
||
|---|---|---|
| .. | ||
| changelog | ||
| compat | ||
| control | ||
| copyright | ||
| docs | ||
| lintian-overrides | ||
| postinst | ||
| postrm | ||
| prerm | ||
| rules | ||
| triggers | ||