FC2 GUI on Intel Celeron 500MHz very slow

[James Wilkinson]

Kshitij Velhal has been having performance problems.
> For **hdparm**
> [root at localhost root]# hdparm /dev/hda
> 
> /dev/hda:
>  multcount    = 16 (on)
>  IO_support   =  0 (default 16-bit)
>  unmaskirq    =  0 (off)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  readonly     =  0 (off)
>  readahead    = 256 (on)
>  geometry     = 29777/16/63, sectors = 30015216, start = 0

Looks good.
> For **vmstat**

I'm slightly hampered here by not knowing what's going on, but...

The swap columns are (as expected) 0. That's good. 

(I'm snipping some lines of vmstat output, by the way... And you'll find
this a lot easier to follow in a fixed-width font!)

> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
>  5  0    912   3016  35732 247928    0    0    70     0 1276  1255 31 12 51  6
>  3  1    912   3064  35484 245932    0    0  1018     0 1246  2056 35 16  0 50
>  1  0    912   2864  35404 243756    0    0   846   320 1221   785 52  8  0 40
>  1  0    912   2648  35176 241764    0    0   474     0 1188   750 74  7  0 19
>  3  0    912   3108  34812 240480    0    0   174   147 1163   929 83  7  0  9
>  2  0    912   3488  34300 236852    0    0    42     0 1134   761 87 10  0  4

A quick peak of activity here. Notice how the wa(it) column is high as a
lot's being read in from the disk (the CPU figures are percentages). At
that point, you're dependent on a lot of reads from the disk. But the
processor's being stretched too.

Watch the way the cache goes down in size: as Linux loads blocks from
the disk, it reclaims pages from cache so it has somewhere to put them.
This is normal usage, and shows how the cache can be used as a supply of
free memory.

How old is that disk you've got in there?

The next few lines (snipped) show a system that's busy, but not too
busy: there's a lot going on, but you're not using all the CPU, nor yet
are you limited on disk speed.

Then you get to this lot...

>  0  1    912   8624  34220 235584    0    0  1132     0 1180   901 48 14  0 38
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
>  0  2    912   3256  34212 239956    0    0  2564   236 1189   796 29  6  0 66
>  1  0    912   4612  32516 240164    0    0  4234     0 1299  1323 14  9  0 78
>  0  2    912   6968  30752 239180    0    0  2954   668 1282   860 17  8  0 75

This is the start of a lot of similar lines. Your system is waiting on
the disk a *lot*.

And then you get periods like:

> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
>  1  0    912   8576  24428 240644    0    0    84     0 1164  2313 55 22 22  2
>  1  0    912   4864  24444 240664    0    0     2   376 1144   738 86  9  0  5
>  3  0    912   3172  24444 240708    0    0     0     2 1127   781 95  5  0  0
>  3  0    912   3216  24284 236908    0    0     2   513 1105  1050 89 12  0  0

Finally you're seeing the CPU becoming the limitation. The us ( = user =
stuff like Evolution and Gnome) column is in the eighties and nineties.
But it doesn't last much longer than the eight seconds I've shown.

On this showing, you're using a lot of the CPU power you've got, but
you're pushing the disk.

I think we need to know more about an average application mix that
you're trying to run.

Sorry I can't help more,

James.

-- 
E-mail address: james | This week's prize will give instant peace of mind to
@westexe.demon.co.uk  | any lover of unusual animals who's worried that their
                      | pet might go astray. It's this self-addressed antelope.
                      |     -- "I'm Sorry, I Haven't A Clue", BBC Radio 4