Sam Varshavchik wrote:
Jeff Pitman writes:
On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote:
Yes, these are large packages that are being removed. No, even with all that, taking six minutes, a dual Opteron box, with SCSI RAID, is unreasonable.
Check strace, %preun, %post, %postun, and other related trigger operations and post your results where the bottlenecks are. Could be rpm, could be db, could be scriptlets .. who knows.
It's neither of these. According to top, all the CPU was being charged to the rpm process alone. The kernel package's %preun consists of:
/sbin/modprobe loop 2> /dev/null > /dev/null || :
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 2.6.10-1.12_FC2
Which is nothing.
rpm was eating CPU like there's no tomorrow. strace was showing lots of read/writes, likely its database.
Yep.
There's a busted algorithm in rpm that goes badly when there are numerous duplicate basenames that is triggered
by installing lots and lots of kernels (with 18K+ duplicate basenames each) onto client machines.
Keep fewer kernels installed is the only answer I have at the moment.
A real fix is non-trivial and has been blocked (because not prioritized) for many years now. There has been
little need to "fix" the problem because behavior has been acceptable except for certain problem areas like
LC_MESSAGES in glibc-common.
Now there are often 10+ kernels are present on each and every client. There is certainly
no "need" for 10+ kernels on most client machines that I'm aware of.
I'd also suggest better install policies for kernels would help.
Note that multilib installs are forcing multiple duplicate file basenames onto lots of machines as well.
The same slow behavior will be seen, just not as bad as kernel packages because fewer files involved.
73 de Jeff
