Jose Gonzalez Gomez wrote:

>packet root # hdparm -tT /dev/hda
>
>/dev/hda:
> Timing cached reads:   2216 MB in  2.00 seconds = 1107.06 MB/sec
> Timing buffered disk reads:   76 MB in  3.03 seconds =  25.06 MB/sec
>  
>

Unfortunately, disk throughput is an almost useless measure of
performance for your situation.  This is because it is really the
average seek time that is killing you, not throughput.  And that toshiba
drive is running at 4200rpm, with an average seek time of ~19ms.  Or put
in other words, that means your performance when needing to access
different areas of the disk simultaneously (for example, the kernel
swapping memory while an app is trying to read or write files) is about
50 IOs/sec.

My suggestions (in order of least to most expensive):

1. Play with the 'swappiness' parameter (google it).

2. Reduce the amount of swap, and make sure it is located adjacent to
your root partition (or, if you use a /usr partition, put it next to /usr).

3. Partition your disk, if you don't already.  Making partitions helps
to keep related files close together, reducing the time it takes to seek
from one to the other, and reduces the effect of fragmentation in
Linux.  If you don't need all 80GB, you could even leave the last 20-30%
unallocated, which is typically the worst performing section of the disk
(for throughput).

4. Purchase a new disk.  The 60GB 7200rpm Hitachi disks are the fastest
disks available for a laptop today, with an average seek time of ~14ms.

5. Upgrade memory (1G recommended).

A word on partitioning: I have 2 of those Hitachi disks in my laptop, in
a raid0 configuration.  After a small boot partition, swap (2G) is the
next thing on the disks, followed by 20G of root, followed by 5G of var,
2G of tmp, and 50G of home.  The last 32G of the array is not allocated
to anything in particular.  With 2 processes accessing root & swap, I
run over 120 IOs/sec.  If those same two processes have to randomly
access the entire array, the performance drops to 94 IOs/sec.

Hope this helps.

-Richard

--
gentoo-user@gentoo.org mailing list

Reply via email to