Thanks James for you time and effort... The typical application mix that I run includes Firefox browser (2-3 windows no tabs), yahoo messenger, evolution, GNUCash, 1-2 Terminals, occasionally openoffice programs and gqview The hard disk is quiet old say @3-4 years. Motherboard doesn't support latest and graetest hard disks. So will have to bear with it. Is Hard disk the culprit? Date: Fri, 10 Dec 2004 17:56:22 +0000 From: James Wilkinson <james@xxxxxxxxxxxxxxxxxxx> Subject: Re: FC2 GUI on Intel Celeron 500MHz very slow To: fedora-list@xxxxxxxxxx Message-ID: <20041210175622.GB13366@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=us-ascii 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.
