> On Jan 12, 2016, at 11:25 AM, Jate Sujjavanich <email@example.com> wrote:
> I am using rpm 5.4.9 as my package manager on an embedded system, and I am running into some bottlenecks with the Berkeley database. I am using an SD Card as my root file system.
> The rpm transactions from a kernel upgrade take an hour or so. Using the --stats option, I found that rpm was spending 15 or so seconds total per package in dbadd, dbget, etc. An strace revealed that many fsyncdata calls were happening. It appears this is due to ACID-ity of transactions.
Yes: fsync is especially costly on an SD card, and is measurably slower
on other media as well. ACID doesn’t come for free.
A performance fix is usually to stub out sync (and all its variants) in the
vectors used by Berkeley DB to make OS calls when opening the
> I found some posts saying that sqlite could be used as the database backend, so I tried this. I tried using configure to activate sqlite without success.
Those posts were from years ago: transactional support was added in ~2010.
> I can compile with sqlite support, but so far, I can't get RPM to create any sqlite files. I've tried database conversion, initializing an empty RPM database, and setting _dbapi to 4 in /usr/lib/rpm/macros.
There are significant changes for transactional support that have not been implemented
in the rpm sqlite3 code.
> I discovered that within configure.ac <http://configure.ac/>, DBAPI is hard coded to 3 (Berkeley DB).
> I would like to know if sqlite3 as a backend is supported by RPM these days in 5.4.9 or any other versions. I want to find out if some of the patches within yocto/poky are breaking sqlite support.
The sqlite3 code (and support) in rpm5 was abandoned in favor of
Berkeley DB ACID transactional support quite some years ago
I don’t know what patches are in poky/yocto specifically, but it should not
be too hard to find patches related to database functionality.
Try filing a bug report with poky/yocto, which will likely trigger a support request to me.
The performance on an SD card rather than the choice of backend database is
the issue in need of fixing.
73 de Jeff
Received on Tue Jan 12 19:47:05 2016