lubuntu-qa team mailing list archive

[Jonathan Marsden <jmarsden@xxxxxxxxxxx>]

On 04/07/2013 04:16 PM, Aere Greenway wrote:

> By process, I don't mean something internal with a process-ID.  I
> mean the sequence of steps a person (and the software) goes through
> to apply updates.

OK, thanks for clarifying.

> Also, I don't think the problem is memory-related, because I have a 
> Lubuntu 12.10 system on a 933 megahertz (single-processor) machine 
> (which also has only 512 megabytes RAM), and it doesn't exhibit the
> same symptoms.  It only happens on my slowest (450 megahertz 
> single-processor) machine.

Interesting.  Can you swap disk drives easily between PCs?  If so, it
might be worthwhile to confirm that the issue stays with the slower CPU
if you swap the two drives between the two machines.  If the slowness
moves with the hard drive, then it is probably some sort of difference
in how the machines are configured, or which packages are installed.
I'm not sure how comfortable you would be doing that experiment (making
and verifying backups first is recommended, just as a precaution)... but
if you are OK with doing it, go for it :)

> Also, I'm fairly certain it isn't related to disk caching.  It stays
> in that busy state for a /really/ long time.  I gave up on it after
> about 45 minutes.

Ah.  OK.  Now I see why this is a real problem -- 3 or 4 seconds is one
thing, 45 minutes is rather different :)

But it seems odd that a CPU-related issue would need 45 minutes on a
450MHz CPU, and *not* need 20+ minutes on a 933MHz CPU -- logically the
933MHz system should be at most about 2x as quick as the 450MHz system,
not 10x or 100x quicker!  In general in Linux on a normal desktop or
laptop PC, running normal (not gaming, not HD video editing, etc.)
programs, CPU is not the biggest performance bottleneck at all -- disk
I/O almost always is.  Which is why having lots of RAM often helps -- it
gets used as disk cache.

So, to me, from far away, this issue doesn't sound like a purely "slow
CPU" issue... it sounds more like something else is happening that is
making the system very very slow indeed.

> When I use the software-updater (whose window goes away), I watch what
> is going on in the system using the task manager, showing both my own,
> and root processes. 

Can you do

  sudo ps afux |tee psafux-$(date +%F-%T).txt

a few times during that 45 minutes, and post the resulting psafux-*.txt
files somewhere?  They will contain a tree of all user processes on your
machine, which might help find the culprit.

If you want, you could also do

  sudo iostat -p ALL 2 30 |tee iostat-$(date +%F-%T).txt

which will take one minute and get you/us 30 sets of info on io usage
(each 2 seconds apart) a few times.  (You probably need to do

  sudo apt-get install sysstat

first, to install it!).

> Having watched the updating details window a lot, there are certain 
> processes running that I recognize to be part of updating the system.
>  Examples of these are mkinitramfs, mandb, grub (and mounting
> partitions as part of the grub update process).  There are also other
> things I recognize that don't come to mind just now.

Interesting... all that should happen in the foreground, as far as I
know, not in the background after apt-get has completed.

> I will do more testing with it, and give more information.  The "top"
> command looks like a really good tool, and I will use it next time,
> rather that the task manager.  Perhaps it will show me more. 
> 
> I will try it again (soon) when there are more updates to be applied. 

If this is a test PC, you can just reinstall from an Lubuntu 12.10
alternate installer ISO, without asking to download updates during
install... then you will have quite a pile of updates ready for testing
after the initial install!  But if this is a real use machine, so you
can't just randomly reinstall like that, I understand this approach may
not be practical :)

I'm not sure I have the time to go digging around in my garage for
ancient 450MHz-ish machines to test this out on... I suspect I have one
or two in there somewhere... :)  It is easier for me if I can test in a
virtual machine, so I can work in my home office (aka pigsty??!) and
multitask between test installs and other things, rather than having to
find and set up old physical hardware for testing.  Maybe I'll try
setting the max CPU of a VM down to just 10% of one core, i.e. 2.5% of
the real CPU power of this 3 year old desktop PC (!), and see if that
causes multi-minute CPU or disk load after an apt-get upgrade.  My guess
is that it won't -- I think that there is something "special" happening
on your PC which we need to understand before we can solve this issue.

Jonathan