At 05:29 AM 9/5/2006, Joseph Haig wrote:
----- Original Message ---- From: Daniel Senie dts@senie.com To: centos@centos.org Sent: Tuesday, 5 September, 2006 10:00:49 AM Subject: [CentOS] yum consumes machine (load average soars to 47)
I was using yum to update packages a few nights ago on one of my servers. The update of rpm packages appeared to die. Since then, commands like 'yum check-update' will consume the system. This is a dual-core Pentium-D, with X64 (and I'm running 64 bit). One CPU pegs at 100% running yum, but whatever it's doing on disk really is the bigger issue. It so consumes the disk subsystem as everything else grinds to a halt and the system becomes unusable (likely swapping itself silly).
I'd really like to get this resovled and apply errata. What I need to know is where to start looking. I've tried a 'yum clean all' but that doesn't help.
Dan
There is a known issue with sqlite and python-sqlite. If
$ rpm -qa |grep sqlite
shows that you have sqlite 3.3.3 then you must also have python-sqlite 1.1.7 or yum will freeze, which is obviously a problem as you cannot then use yum to solve it. I managed to fix this with:
$ rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-sqlite-1.1.7-1....
OK, updated that (had to update sqlite-devel too). But this didn't seem to help.
Even killing off everything else I could find that chews up memory on the machine, consumes all swap space, and the load average soars.
The threads pointed to in another email suggest there may be duplicate package installs causing issues. That's not the case on this system. The only packages showing duplicates are the kernel, which should be correct.
strace shows it doing brk() calls, nothing else. Just in a tight loop allocating every ounce of memory I've got until the machine is swapping itself to death.
Aha! Found it: there were two copies of python-sqlite installed, one being the old one and one I added. System didn't clean up the old one when the new was installed. That's ugly.
I've now completed at full "yum update" though reading the rest of the messages on the list, I'm not 100% sure I want to reboot onto the new kernel...
Thanks to those who pointed me in the right direction to find and solve the insatiable memory eater issue.