[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


 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

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: