Re: Block Size
- From: "John Fullbright [MVP]" <fullbrij@xxxxxxxxxxx>
- Date: Mon, 15 May 2006 11:18:06 -0700
The referenced paper is targeted toward disk subsystems in general, not
Exchange. You can however, glean some usefull information from the Stripe
Unit Size section. Take into consieration the nature of IO on the the
Exchange 32 bit platform:
Logs - Writes from 512 bytes to 90% of eseparamlogbuffers * 512 bytes with
significant sequentiality and a fair degree of burdstiness. This is tempered
by the fact that the allocation unit size of the NTFS partition on which the
logs reside is likely 4K (the default) so writes for 512 bytes to 4K bytes.
EDB files - 4K random workload with a fair degree of burstiness
STM files - up to 32K writes with a fair degree of sequentiality and
burstiness.
You'll have to weight the frequency of each type of IO in your environment
and then make some tradeoffs in situations where multiple Io patterns are
hitting the same spindles.
For the logs, I would go with 64K. To quote from the referenced paper
"Smaller stripe unit sizes become more tolerable when the workload has
significant sequentiality. This is because the overhead of positioning
multiple spindles' heads is amortized over multiple requests to each
spindle, aided by automatic prefetching. But if the sequential requests
occur in small bursts or occur in conjunction with other request streams, a
larger stripe unit size might be more appropriate, so that each burst can
take advantage of the prefetching heuristics of a single spindle rather than
be spread across multiple spindles, prompting wasted prefetching."
Do be aware that if you do not have write cache enabled:
"For a write workload without write caching, there is no write combining and
sequentiality gains no benefit from staying on a single spindle. In fact, it
would be better if each sequential write goes to a different spindle to
reduce rotational latency-that is, set the stripe unit size to equal the
typical write request size. But storage subsystem caching for a workload
with locality represents perhaps the most important performance
consideration."
For the stores (assumes edb and stm files in the same location), again the
default allocation unit size is likely 4K so you have de facto 4K requests.
For a random workload with a 4K IO size, 16K to 32K would be appropriate.
Even 64K, at 16 times the IO size would be at the upper limit. As the block
size, in terms of multiple of the IO size, increases, the effectiveness of
read cache decreases. This is offset by a degree of sequentiality for the
STM file, so we're making a tradeoff by choosing a low multiple of the IO
size.
Consider the context, it pays to read the fine print.
John
"Teo Heras" <teo at inventrix dot net> wrote in message
news:3EC115F5-D978-4C14-8B63-3EB00A44A57C@xxxxxxxxxxxxxxxx
The document below, under the section Rules of Thumb, recommends that the
Stripe Unit Size be no less than 256 KB
http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/subsys_perf.doc
--
Teo Heras
"Andrea" wrote:
Hello,
i will install my exchange 2003 on the microsoft cluster. I have created
two
shared disks array: raid 1 for logs and raid 0+1 for the store.
Which is the better block size (for the best perforfance) for the logical
unit of the logs and tore partition? 16K, 32K or 64K?
Thanks
Andrea
.
- Follow-Ups:
- Re: Block Size
- From: Andrea
- Re: Block Size
- Prev by Date: Re: Block Size
- Next by Date: RE: Exchange 2003 Restore Problem
- Previous by thread: Re: Block Size
- Next by thread: Re: Block Size
- Index(es):
Relevant Pages
|
