recover from broken yum transaction

Martin Langhoff martin.langhoff at gmail.com
Mon Sep 22 05:56:17 UTC 2008


2008/9/22 James Antill <james.antill at redhat.com>:
>  What arch? How many repos. did you have enabled?

i386 - and the very minimum repos

$ yum repolist
Loaded plugins: refresh-packagekit
repo id              repo name                                status
fedora               Fedora 9 - i386                          enabled :   9,897
updates              Fedora 9 - i386 - Updates                enabled :      10
updates-newkey       Fedora 9 - i386 - Updates Newkey         enabled :   3,951
repolist: 13,858

>  In my tests the latest yum does a "large" update in about 40MB RSS, a
> few packages is much more likely to be in the 25-30MB range (VSZ is
> higher, but is just unpaged stuff, not actual swap).

I'm looking at the output of ps_mem.py which uses the kernel smap data
-- which I understand is regarded as much more reliable than what top
reports these days - see
http://www.pixelbeat.org/scripts/ps_mem.py

>  We drop all the cached data from within yum when the depsolving is
> finished, however we have little control of how much of that is then

There was no observable drop in memory footprint from depsolving to
rpm stages, even if we were just updating 9 packages.

If my rough test is reasonably accurate then it's easy to see why
people would get OOM with yum on the XO -- just reading the release
repo, yum is sitting on a good chunk of our available memory, and we
have _no_ swap available.

One workaround would be to say --disablerepo=release but that means
any install that requires packages from the main repo will fail.

>  We also have plans to split transactions, but I'm not sure you should
> rely on that to significantly drop the memory usage requirements
> (although it will make the failure case much nicer).

I'm *all* for making the failure case better as the XS installations
will fail... plenty :-)

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff




More information about the devel mailing list