[Rpm-maint] [PATCH] RPMDB Performance

devzero2000 pinto.elia at gmail.com
Tue Aug 11 10:47:45 UTC 2009


On Tue, Aug 11, 2009 at 12:19 PM, Florian Festi<ffesti at redhat.com> 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?
Beware of data loss with ext4 dropping down fsync
http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892
The problem with ext4, XFS, or another extent-based filesystem is inherent
in their design, afaik.

But XFS arises for server environments that have different characteristics
of redundancy and the problem is minor. On the desktop the corruption
problem may be much higher.

Regards
>
> Florian
>
>
>
>
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20090811/867e67c4/attachment.htm>


More information about the Rpm-maint mailing list