Comment 12 for bug 635834

Cat(1) measurements help, but as I tried to point out, this is a database,
and databases have different needs and different I/O patterns than
cat(1) does. And any solution (once the problem is characterized) will likely
be rather different too.

You are hardly a typical user, most of whom have no idea
what callgrind is or does, or what an I/O stall issue is. Please
stop pretending that you are "just a user" with a stop watch. ;-)

(aside)
Note that there has been a historical issue with Berkeley DB db-4.1.x
(iirc, been years) with I/O stalls and waits. The issue was tied to
select vs poll behavior. There's a bugzilla report and a perl script
reproducer generating 5000 records in Berkeley DB on (iirc) approx a RHEL4 time frame.

Which is why I ask for details like
   Can you document I/O stalls & waits as part of a performance problem?

Not also that I have never heard or seen an issue with rpmdb performance
degradation over time until now. Which means that something (other than
RPM and Berkeley DB which haven't changed much at all) is likely
relevant to what you are seeing.