Yum is a memory pig to the tune of 3GB

[Tom Mitchell]

--- seth vidal <skvidal at fedoraproject.org> 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.