RPM needs to go on a diet.

[Jeff Johnson]

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