Hide Forgot
The problem I've had on 5 different boxes was slow filesystem I/O. stracing rsync showed lstat64 system calls issued by rsync processes would take forever to complete (quite often 5-10 seconds); then a burst of progress was made and then it came to a halt again. Hard disk leds confirmed this access pattern, except for one of the boxes that had two disks in RAID 1 resyncing, whose disk access was constant. Very odd. It might have to do with the system running out of real memory, still with plenty of mostly-unused swap. In all cases, there was competition for disk access between rsync (sometimes more than one) and either prelink or updatedb. In at least one case, after updatedb completed rsync became very fast. Version-Release number of selected component (if applicable): kernel-2.6.5-1.332
I noticed this, too, today. updatedb ran in bursts, stopping in a lstat64() call for several seconds. vmstat showed almost the entire processor time spent in iowait. iostat showed no IO access to the disks (apart from some smallish writes/reads now and then). The system was very sluggish during that time, programs requiring disk access (even small ones like "sudo kill <foo>") required several seconds. After killing updatedb, everything went back to normal. kernel is kernel-2.6.5-1.339.i686 on an AMD Duron
This should be fixed in the 349 kernel on http://people.redhat.com/arjanv/2.6/
Confirmed, thanks.