[Rpm-maint] [PATCH] RPMDB Performance

Panu Matilainen pmatilai at redhat.com
Wed Aug 12 13:41:29 UTC 2009

On Tue, 11 Aug 2009, Florian Festi wrote:

> Hi!
> I've done a couple of performance measurements around the rpmdb. It turns out 
> that the huge number of f(data)sync calls is significantly slowing down RPM 
> on todays ext[234] file systems.
> Setting no_fsync in the rpmdb config drops the F10 Everything install 
> --justdb from 2:51:00 to 4:50. The install without --justdb drops from 5:38h 
> to 1:20h (All with hot FS caches on my new desktop).
> As my first two attempts (setting other config parameter as cache_size etc 
> and using db4 transactions) have failed the attached patch does now switch 
> off fsync for building the rpmdb indexes only. I don't have access to my 
> desktop computer right now, but --justdb now takes 26:29 instead of 11:21 
> with no_fsync on my (much slower) laptop. Nevertheless building the rpmdb 
> with fsync enabled also takes 2:54h which indicates that it is primarily 
> limited by the turning speed of the hard disk which seems to be the same on 
> my laptop and desktop.
> The patch still needs better integration into the rpmdb configuration system 
> and dummy code for the sqlite backend.
> Any thoughts or safety concerns?

Hmm. The same thing can actually be accomplished by just adding "nodbsync" 
to everything but Packages, without any code modifications (strace shows 
identical number of fdatasync() calls).

As long as Packages is intact the rest can be rebuilt so in that sense 
it's "safe", but... do we actually know, reliably, if the db would need a 
rebuild due to indexes being "out of sync"? As it is, I dont think so.

 	- Panu -

More information about the Rpm-maint mailing list