On 7/29/05, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Fri, Jul 29, 2005 at 02:04:33PM -0400, Tony Nelson wrote:
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 5202 root 39 19 11724 9280 536 R 89.9 1.9 0:23.59 prelink
>
> I don't think this is a a swap problem. If it were, the process would be
> out of memory, but instead it's using little memory but lots of CPU.
> Prelink is supposed to be disk intensive, not CPU intensive, so maybe it's
> a bug in prelink or something it uses.
That's not true, prelink is actually fairly CPU intensive if it has
a lot of work to do. Say if you upgrade glibc or some other library
everything or really many programs link against, then the next prelink cron
job will have a lot of work and what you show above is certainly not
unexpected in that case. But that will happen only once after the upgrade,
if you don't upgrade anything the next day, it should take just a few
seconds (typically just stat 3-5 thousand files). If you upgrade just some
rarely used library or just a package with binaries, not libraries, it
should be pretty quick as well.
Jakub
The thing is, on this machine, with FC4, it is _always_ sluggish, and
often slows to a crawl. It didn't do that in FC3 or -that other- OS.
I'll add that swap partition tomorrow and see how much it helps.
Thanks, all.
Jakub, as I see you write from a redhat address, would you be
interested in what tops 'top' when it gets so sluggish? I would do it
in bugzilla, but the last time I tried to navigate bugzilla I got
tangled up (histabahti lemi shmevin) and vowed not to go back.
Dotan
http://song-lirics.com/sl/artist/109/carlisle-belinda-lirics.php