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:
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
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"
Makes sense. Using RAM for the db env is always going to be faster than
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