I don't think it's a disk performance issue. It's the sheer volume of disk activity that occurs.
Without the mp_size change, I'm seeing vast amounts of disk IO from rpm even from simple queries like "yum list available ...". It sustains writes (yes, writes!) of between 3MB and 15MB per second for 90 seconds... that's an insane amount of write IO for a readonly query of the bdb, and I think it's a red herring to be looking for kernel reasons why that amount of IO is slow. rpm/bdb really shouldn't be generating that much write traffic in the first place.
btw, "iostat" is a good way to watch the traffic resulting here. I usually use "iostat 2" to get it updated every couple of seconds.
With mp_size=1MB as in comment #12, the problem disappears completely. With the default /usr/lib/macros, rpm is almost unusable, on every system I've got which has been updated from older versions of Fedora.
I don't think it's a disk performance issue. It's the sheer volume of disk activity that occurs.
Without the mp_size change, I'm seeing vast amounts of disk IO from rpm even from simple queries like "yum list available ...". It sustains writes (yes, writes!) of between 3MB and 15MB per second for 90 seconds... that's an insane amount of write IO for a readonly query of the bdb, and I think it's a red herring to be looking for kernel reasons why that amount of IO is slow. rpm/bdb really shouldn't be generating that much write traffic in the first place.
btw, "iostat" is a good way to watch the traffic resulting here. I usually use "iostat 2" to get it updated every couple of seconds.
With mp_size=1MB as in comment #12, the problem disappears completely. With the default /usr/lib/macros, rpm is almost unusable, on every system I've got which has been updated from older versions of Fedora.