On Mon, 2008-03-24 at 11:17 -0700, Tom Mitchell wrote: > > > > There is some library functionality and interaction with > malloc() and friends that causes yum to be a pig. s/yum/something yum uses/ okay just so we're clear yum isn't do anything fancy with memory at all. 3GB is way beyond the norm and if it is during the transaction points to SOMETHING in the rpm transaction exploding in memory. > 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. Outside of the actual rpm transaction I've never seen yum use more 600MB of ram, and then only on x86_64 systems. In the actual rpm transaction yum doesn't have any control over how much memory is being used. rpm and rpm-python do. > 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. nothing obscure about it. I talked about it on my blog last week. Python objects on 64bit systems use 2-3x the memory of the same object on 32bit systems. -sv -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
