slocate daily anacron job makes system feel slow

It has run daily since before Warty was released.

Hm.. ok, maybe I only noticed now.

But it's really annoying, I assure you. Unfortunately the linux kernel doesn't
have a way to lower the priority of disk access requests, so extra care should
be taken when scheduling IO intensive tasks in background.

This subject was just (once again :) discussed (header: updatedb-question) in
ubuntu-users and I asked if updatedb could default to interrupt updating when
the user starts to work with the machine. Alexander Botero replied with the
following. I don't know if it's usefull or not, but thought to send it here just
in case:

..........

"I was today informed of a (new) "rlocate" command for Kernel 2.6distributions.
--> http://www.linux.com/article.pl?sid=05/08/31/1441206

rlocate daemon can monitor filesystem changes online, so there's no need to
run updatedb so often.

And rlocate daemon could also monitor kbd and mouse events.

Events:
$ cat /proc/bus/input/devices
$ sudo cat /dev/input/event0 # event1, event2 etc... , move your mouse"
...........

I agree with Gustavo that updatedb as it is now often makes Ubuntu look
unresponsive and slow - especially in the eyes of a new user. What the new user
does is not to think "Ah, there's propably some usefull internal process taking
place and everything OK", but rather "Oh no, now it started to malfunction.
Apparently this Ubuntu gets corrupted just like Windows did. You just can't
trust any of these systems". I mean really, the user doesn't know. From his
point of view there's just something wrong - and if something goes wrong, it can
get worse anytime.

Thanks for listening :-)

Ari Torhamo

As a kludgy but less intrusive measure, perhaps we could just have slocate sleep
some of the time, to reduce the IO pressure.

If the schedutils package - which includes ionice(1) - is installed (and cfq is the active io scheduler on the relevant devices), we can run updatedb with a very low IO priority. This might improve response times for other applications while updatedb is running, as the cfq IO scheduler will permit their requests to barge ahead of those from updatedb in the IO queue. In theory.

The enclosed patch is a modification for /etc/cron.daily/slocate which will run updatedb with minimum IO priority if ionice(1) is installed. The effect of this is kind of hard to measure objectively, but someone who feels like scratching this itch might be interested in testing it.

I tried to measure the impact of ionice on updatedb when running in parallel with a full Eclipse workspace rebuild, a CPU- and disk-intensive process. Results below, there are two measurements per item (this is Gutsy on a Pentium M 2GHz notebook, 7200RPM disk):
Build alone: 50s, 52s
Build with updatedb: 3min20s, 5min17s
Build with ionice -c3 updatedb: 4min30s, 2min44s

So there appears to be only a minimal improvement with ionice, if there is an improvement at all (given the variability of the result, I would have to perform more measurements per item).
The man page of ionice states that it works with the CFQ IO scheduler. How do I know which scheduler I am running, and how do I change it?

I think it would be really nice to solve this updatedb issue, as it really does give users a negative sensation. I use to completely disable updatedb when I install Ubuntu for non-geeks. Anyway, I think most non-geeks will never use locate...

Well I could have searched a bit myself: it seems I am using the CFQ scheduler:
$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

(I guess the brackets show the selected scheduler).

So it seems that ionice is not doing its job properly. Any idea about why? This is the command I used to launch updatedb:
$ sudo /usr/bin/ionice -c3 updatedb

My /etc/updatedb.conf specifies a niceness of 10.

Hi,

I looked into ionice && CFQ some time ago. The use of ionice didn't much help with the updatedb-run-and-system-gets-really-slow-to-interact-with problem.

To be really sure, if the 'ionice' command is the problem, I wrote a kprobe-module to check if the ionice value is present in the scheduler after a command is called by 'ionice' - and it was.

Btw, if you start a command via 'nice', then the ionice-value of the called process is changed as well. Thus, calling a process with a very nice nice-value has the same effect as calling it with ionice.

Using 'nice' for an already running command doesn't change the ionice-value in the scheduler.

And btw, CFQ considers only file-reads.

To sum it up: it looks like ionice is doing its job well - but the scheduler/kernel doesn't

Best regards
Georg