Bugzilla – Bug 114761
Slow machine because of cron.daily and updatedb
Last modified: 2006-08-03 13:37:07 UTC
I investigated why my machine is so slow and found that the system is busy with the command find started by /etc/cron.daily/suse.de-updatedb. I am not sure if it is a common problem. Maybe, I see this problem as more important because I build OpenOffice_org. There is used the disk a lot as well, so the slowness might be more visible than for normal user. It seems that the scripts in cron.daily are started immediatelly after the system is installed. And they are started each day at the same time then. I think that it would be better to postpone the first or the second start to the midnight. It would be enough to touch /var/spool/cron/lastrun/cron.daily to a reasonable value in a post install script. I think that it looks curious when a fresh system is so slow after it is installed. And it is so slow every day at the same ugly time.
Guess: Old IDE based system with slow IDE chip and disks.
Created attachment 48490 [details] Output from hwinfo on my machine It is quite a new machine with SATA disk. Maybe the problem is that I build OOo. The machine is under high load. The disk is big and full of small source files...
This is a kernel problem.
The kernel has no way improving the performance of the hardware. If the cron jobs need to be set up differentely, it's not a kernel problem.
andreas was probably talking about the io-scheduler and that one is a kernel problem about the cronjobs: cron is not my package, but anyway, I'll gladly take patches ...
What about reverting the patch from bug [#71017]? I just found out, that the daily script runs at the random time (of day), when I finished installation. Maybe there was a chance, that cron.daily run twice a day, but to my mind only once (the first time), provided the clock does not jump. With the rm lines in crontab for removing the lastrun-files there was at least a chance to have control over the time the cron file run.
you still have the chance to influence these by touching these files with a set reference time
The best solution I found is to do not touch the files /var/spool/cron/lastrun/cron.* with the exact time when the scripts are started. They could be touched with a time of the same day but early after midnight. It means that the next start is sheduled the next day/week/month after midnight. If the machine is not runnig over night, the scripts will be started the requsted day after the machine is started. The prefered exact time could be set in /etc/sysconfig, so the users could change it easily. The question is what to do if the user prefers starting the script, for example at 6p.m. and the latest time stamp says that it should be started, for example at 4p.m. In this case, I would differ between two situations: 1. The latest time stamp says that it should be started this day at 4p.pm. In this case I would pospone start to the preferred time at 6p.m. 2. The latest time stamp says that it should have been started some days before. In this case we cannot risk and must start the script immediatelly. And touch the time stamp with the actual date, so the script is not started later the same day. The only problem with the postponed start is when the user preferes the time, for example 6p.m. andshe/he stops the machine each day at 5p.m. Then the script cron.daily is started just every second day. But it should not happen often if we define the default prefered day close after midnight.
forward to 10.1 and assigning to cron maintainer
*** Bug 93563 has been marked as a duplicate of this bug. ***
I think that it would have been better to mark this bug as duplicate of this 93563, as the latter comes at least closer to the solution suse has most likely in mind. Anyway the description in 93563 refers to: http://susewiki.org/index.php?title=Schedule_cron_daily that tells how to have cron.daily scheduled.
updatedb should consequently be run with `ionice`, so it does not interfere at all. Even nice 20 is "not enough", not even with normal workloads a lot less than building OOO.
Did you look at 10.0? eval nice -n 19 ionice -c 3 /usr/bin/updatedb $PARAMS 2> /dev/null
updatedb was running with ionice on my system for quite a while now. While it is an improvement, the system is still too sluggish to make normal working possible. E.g. starting a new shell (in screen) repeatedly takes from 3 to 10 seconds (or even more). Opening a short file in vim is similarly slow.
... and package compile times are up by 60%.
*** Bug 138551 has been marked as a duplicate of this bug. ***
Using ionice is one approach, but still I would very much prefer to run those cron jobs when nobody is working with the machine. Petr's suggestion from comment #8 makes very much sense to me.
Fixed in STABLE. There's now sysconfig variables to control this. Thanks to Martin Lasarsch for doing this.
*** Bug 196746 has been marked as a duplicate of this bug. ***