FS#41688 - [mlocate] updatedb.timer induced HDD thrashing on bootup
Attached to Project:
Arch Linux
Opened by Hermann Zahnweh (eigengrau) - Monday, 25 August 2014, 08:02 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 14 December 2014, 17:56 GMT
Opened by Hermann Zahnweh (eigengrau) - Monday, 25 August 2014, 08:02 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 14 December 2014, 17:56 GMT
|
Details
Description:
updatedb.timer currently causes severe thrashing and bootup delays due to it triggering immediately after boot, in parallel with all other timer units. For the time being, until systemd.timers gain (proper) support for a random delay or spread, we should look for work-arounds, such as using a non-persistent trigger or an OnBootSec= trigger. On the mailing list, Thomas reported that timer activation would be randomized due to TimerSlackNSec=. I thought so too and suspected a bug first, but studying the man page reveals that TimerSlackNSec= is actually not designed in that way. Rather, TimerSlackNSec= is meant to bunch all timers together, if possible, in order to minimize interrupts, and it does not claim that the trigger time will be truly random. So the current behavior (updatedb/mandb timers triggering immediately after boot in parallel), is due to design, and #systemd confirmed that indeed TimerSlackNSec= is not meant for randomization. I have filed an enhancement request on the systemd bug tracker. Possibly some folks could chime in there if they would find that feature useful, to give it some more traction. https://bugs.freedesktop.org/show_bug.cgi?id=82084 There might not be a good workaround available (personally, for me OnBootSec= works, but for others the one-time daily thrashing might be preferable). In case no good ideas come up, this task can be kept as a todo until systemd has a timer delay feature. Additional info: * mlocate 0.26-3 |
This task depends upon
Closed by Gaetan Bisson (vesath)
Sunday, 14 December 2014, 17:56 GMT
Reason for closing: Fixed
Additional comments about closing: mlocate-0.26-5 in [testing]
Sunday, 14 December 2014, 17:56 GMT
Reason for closing: Fixed
Additional comments about closing: mlocate-0.26-5 in [testing]
Thomas, you know much more about systemd than me; could you have a look at what I commited to SVN and revert it if that does not make sense to you? (Note that I also changed the IO scheduling settings.)
The suggested (and implemented) solution makes no sense at all. It runs the updatedb.service on every boot, even if I boot 100 times a day. This is NOT desired behaviour. For systems that are not "always-on", the OnUnitActiveSec setting does not work as expected either.
The initial problems does not exist any longer anyway. IIRC, timers are now delayed until bootup has finished, solving the bootup delays. As for running all timers at the same time, I don't see your "solution" doing anything about that. And I don't see a problem with that. Setting proper IO scheduling options is the right way to handle this, the kernel is able to ensure that there are no problems.