On 7/29/05, Jakub Jelinek <jakub@xxxxxxxxxx> 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
