Re: Finding the Bottleneck
- To: "Jason Lim" <email@example.com>, <firstname.lastname@example.org>
- Subject: Re: Finding the Bottleneck
- From: Russell Coker <email@example.com>
- Date: Fri, 8 Jun 2001 16:49:42 +0200
- Message-id: <0106081649420A.30836@lyta>
- Reply-to: Russell Coker <firstname.lastname@example.org>
- In-reply-to: <014d01c0f025$6318cdc0$0300a8c0@jcl1>
- References: <00e001c0ee3c$5ac9d8c0$0300a8c0@jcl1> <01060813170804.30836@lyta> <014d01c0f025$6318cdc0$0300a8c0@jcl1>
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
> (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