Is the problem caused by newsyslog or by the periodic scripts?
Newsyslog normally runs from cron directly, not through periodic. In
any case, here are a few suggestions:
1) Turn on cron jitter, as you suggested. Even if 60s isn't enough,
it can't hurt.
2) Try gz compression instead of xz compression to see if it's faster
3) Manually edit the jails' /etc/crontab files to hardcode some
variability into their newsyslog and/or periodic run times
4) If the problem is actually being caused by periodic instead of
newsyslog, tell me which script it is and how much jitter you want. I
am coincidentally changing how periodic manages jitter right now.
-Alan
On Thu, Feb 16, 2017 at 2:47 PM, Dustin Wenz <dustinwenz at ebureau.com>
wrote:> I have a number of servers with roughly 60 jails running on each of them.
On these hosts, I've had to disable the periodic security scans due to
overly high disk load when they run (which is redundant in jails anyway).
However, I still have an issue at 3:01am where the CPU is consumed by dozens of
'xz -c' processes. This is apparently daily log rolling, which I
can't exactly disable.
>
> The effect is that our processing applications experience a major slowdown
for about 15 seconds every morning, which is just enough that it's starting
to get people's attention.
>
> What is the best way to mitigate this? I'm aware of the cron jitter
feature, but I'm not sure of the 60-second jitter maximum would be enough
(especially if I wanted to start utilizing more jails).
>
> - .Dustin
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"