Kshitij Velhal has been having performance problems.
> For **hdparm**
> [root@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
