--- seth vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote: > On Mon, 2008-03-24 at 22:07 +0900, John Summerfield wrote: > > seth vidal wrote: > > > > > > > > 4. When was the last time you've run: rm -f > /var/lib/rpm/__db*; rpm > > > --rebuilddb > > > > Why would one do that? > > On rpmdb's that have been updated from past versions it is > something > that can happen to make your rpmdb take longer and longer to > access. > > Seen it happen quite a number of times, in fact. > > I don't know what causes it, though. > -sv > There is some library functionality and interaction with malloc() and friends that causes yum to be a pig. There is a solution, set the virtual memory user limit (see limit, ulimit -a) to be a sane value. When malloc() returns an error garbage collection will be called to release memory back to the pool that malloc(or-something) uses and then yum continues. The interaction is bad enough on largish memory systems that I have added ulimits to launchers, kickstart %post scripts etc. Since I have only seen this on 64 bit systems myself, what I suspect is that there is some obscure use of a 32 bit signed something that is mishandled and causes yum to do something badly. Since yum does fine on systems with 1 or 2 GB of RAM I would just set a soft virtual memory limit to 1.5GB. It might even be worthwhile for yum to test this limit, the size of DRAM and just do this itself. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
