4 ms·
I try to avoid crons at the top of the hour, partly because of this... but also because (in shared / serverless infrastructure) I assume a lot more people are s
by ldoughty 11mo ago
I try to avoid crons at the top of the hour, partly because of this... but also because (in shared / serverless infrastructure) I assume a lot more people are setting their crons for 'on the hour' so there's more resource contention... I also aim for 'after 4am' where I can as well, or 'before midnight', to avoid this whole range.
- sgc 11mo agoTo incrementally improve that tactic, systemd has RandomizedDelaySec, which is a convenient way to reduce the possibility of scheduling conflicts.
- tetha 11mo agoI prefer to combine this with FixedRandomDelay=true. FixedRandomDelay ensures that the randomized delay is an arbitrary number up to RandomizedDelaySec, but it is deterministic per server and timer. I find this useful because this means the timer will always run at XX:12:45 on server01, always run on XX:06:23 on server02 and so on. This combines very simple configuration, while being predictable and spreading out timers well.
- layer8 11mo agoOne trick for cron is to prepend the actual command in the crontab with something like sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ; which will delay it by 0 to 59 minutes at random.