RPM Community Forums

Mailing List Message of <rpm-devel>

Re: RPM DB, Berkley DB and journal files

From: Tim Mooney <Tim.Mooney@ndsu.edu>
Date: Wed 29 Jun 2011 - 15:59:29 CEST
Message-ID: <alpine.SOC.2.01.1106290838280.15977@dogbert.cc.ndsu.NoDak.edu>
In regard to: Re: RPM DB, Berkley DB and journal files, Jeff Johnson said...:

> Meanwhile: Do you agree that increasing mmap size is the most important
> performance related tunable?

First, although I have indeed learned a lot about BDB from OpenLDAP, that
still doesn't mean I know much.  ;-)  I went from knowing nothing about
it to knowing just a little, and most of that specific to how OpenLDAP
uses BDB.  You're still the expert, not me.

That said, if you're going to use mmap at all, then I trust you're correct
about mmap size being the most important tunable.

However, there has been considerable discussion on the OpenLDAP mailing
list about how on certain platforms, using mmap for the BDB env is much,
much slower than using System V IPC shared memory.  For example, on
Solaris using shared memory is an order of magnitude faster than using
mmap for the env:

 	http://www.openldap.org/lists/openldap-technical/201103/msg00069.html

Howard Chu has also stated that IPC shared memory is also beginning to
be a performance win (at least for OpenLDAP) on recent Linux kernels too,
though I don't believe it's the order of magnitude difference you see
elsewhere:

http://www.openldap.org/lists/openldap-technical/201104/msg00150.html

I can find more references to the issue with some more digging, but
basically, for at least how OpenLDAP uses BDB, System V IPC can be
a big win.

That doesn't necessarily mean it's a good idea for RPM in general,
or RPM on an embedded platform in particular.  It would get rid of
most of the __db* files that the original bug report mention, though.  ;-)
Possibly at the expense of making RPM not work at all on that platform.

> I've diddled most of the tunables at some
> point or another using rpm --stats as a measurement, and mmap'd I?O
> is/was the most important tunable (disabling sync cannot be done in "production"
> imho).

Makes sense.  Using RAM for the db env is always going to be faster than
using disk.

Tim
-- 
Tim Mooney                                             Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Received on Wed Jun 29 16:01:46 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.