Re: Finding the Bottleneck
It is strange that we each get such different results.
I haven't run these in totally sanitized environments (haven't had the
luxury or time to do so) so I can't say mine were really scientific, but i
just looked at the real results of each command.
I switch back to using 4Kb readahead as you suggested.
I couldn't set the -m setting any higher:
/dev/hdc:
Model=IBM-DTLA-307015, FwRev=TX2OA50C, SerialNo=YF0YFT68281
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30003120
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
The maxMultSect is 16 :-/
We haven't run nor tested 2.4 kernels yet... but sooner or later we'll get
there. We run a business and need things to be near 100% stable (or at
least try). Do you see any other way to tweak these disks?
----- Original Message -----
From: "Russell Coker" <russell@coker.com.au>
To: "Jason Lim" <maillist@jasonlim.com>; <debian-isp@lists.debian.org>
Sent: Friday, June 08, 2001 10:49 PM
Subject: Re: Finding the Bottleneck
On Friday 08 June 2001 16:14, Jason Lim wrote:
> Today I played around with hdparm to see if I could tweak some
>
> Specifically, I set /sbin/hdparm -a4 -c3 -d1 -m16 -u1 /dev/hdc:
>
> -a Get/set sector count for filesystem read-ahead.
> This is used to improve performance in sequential
> reads of large files, by prefetching additional
> blocks in anticipation of them being needed by the
> running task. In the current kernel version
> (2.0.10) this has a default setting of 8 sectors
> (4KB). This value seems good for most purposes,
> but in a system where most file accesses are random
> seeks, a smaller setting might provide better per
> formance. Also, many IDE drives also have a sepa
> rate built-in read-ahead function, which alleviates
> the need for a filesystem read-ahead in many situa
> tions.
> (Since most the emails are small and randomly placed around, I thought
> maybe 2KB read-ahead might make more sense. Tell me if I'm wrong...
> because the performance jump may not be due to this setting)
What is the block size on the file system? What file system are you
using?
If you use Ext2 then I suggest using a 4K block size. It will make FSCK
much faster, and it will reduce fragmentation and file system overhead
and generally make things faster.
If you use a file system with a 4K block size then it probably makes
sense to have a 4K read-ahead (but I have never tested this option).
> -c Query/enable (E)IDE 32-bit I/O support. A numeric
>
> (Couldn't hurt to have it going 32 bit rather than 16 bit)
If you have DMA on then the 32bit IO flag is ignored...
> -d Disable/enable the "using_dma" flag for this drive.
> (this is a dma100 7200 drive so setting this couldn't hurt either.
> Didn't see much performance increase with this though)
This is where you expect to see some performance increase, particularly
when combined with the "-m" option.
> -m Get/set sector count for multiple sector I/O on the
> (I set it to 16... do you think 32 would make more sense?)
I suggest setting it to the maximum. Also why not use kernel 2.4.4 and
compile your kernel to enable DMA and multi-mode by default? The 2.4
series of kernels should increase performance for disk IO even if you use
the same settings, and it has better tuning options.
> -u Get/set interrupt-unmask flag for the drive. A
> (this seem to have the largest performance boost)
That's strange. Last time I played with that one I couldn't find any
benefit to it. I'll have to test again.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: