Re: Exchange 2003 Transaction Log Performance
- From: "John Fullbright [MVP]" <fjohn@donotspamnetappdotcom>
- Date: Fri, 1 Dec 2006 12:12:41 -0800
Instead of one thread writing, you'll be writing three. The IO pattern will
change from onle that is purely sequential writes to one that is mostly
sequential writes. In this case you're basicly writing extents.
A log write can be from 512 bytes to the number of log buffers/2 KB. If you
have the default number of buffers, there are 80 512 byte log buffers per
SG. You can increase that value up to 9000 per SG. In practical terms, the
size of the log write depends on the size of the transaction, which in turn
depends on message size. These days, a message and it's associated metadata
avarages around 8K. This is one of the reasons for the 8K page size choice
in Exchange 2007.
Assuming 8K log writes and a volume holding the transaction logs with an
allocation unit size of 4K, you end up with an effective minimum extent of 2
writes. Now if thread one writes, then thread two writes then thread one
writes, then thread three writes, etc., and we follow the writes of say the
first thread, we find that we have 2 writes, a gap of twi writes, then 2
writes again.
Modern disks have anywhere from 128 to 250ish sectors per track. a sector
is 512 bytes, and they are grouped into clusters. At an allocation unit
size of 4K, there are 8 sectors per cluster. Going back to the previous
write pattern, and assuming that the writing starts at the begininng of a
track, we see that all the writes still occur on the same track. If we
continue the pattern, we not that when compared to a purely sequential write
pattern, or writes in extents pattern with three threads will fill atrack
three time as fast as one thread.
Going back to disk basics, response time is seek time plus rotational
latency. Rotational latency is minimal (for a 10K RPM disk it's 100
microseconds, while average seek times are on the order of 5 or 6
milliseconds. The seek time is the major component of disk access time.
Seek times are usually expressed as an average, however when dealing with
sequential workloads the track to track seek time or step time is more
important. This is typically around a millisecond.
So, following the example to its conclusion, for a purely sequential
workload 16 writes takes 2.6 milliseconds or .16 ms/write while for the
sequential whith extents workload the same 16 writes for thread one takes
3.6 milliseconds or .225 ms/write. Of course all of these examples assume
write aggregation at the controller, and ignore the reality of metadata
writes for the filesystem and controller virtualization layers, but it makes
the point; The writes will be slower by about 50% when compared to a purely
seqential workload.
In practical terms, due to the factors we ignored in the example, the truth
is we never really achieve a purely sequential workload anyway given a
tradional virtualization layer. Given this, the impact would be minimal. In
order to achieve a purely sequential workload, you'd need to be able to
write both data and metadata in a single stream, out of order, anywhere on
the disk. I can only think of one disk controller with a virtualiation
layer that does this.
"BM" <BM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:25BB144D-BB82-4DF7-BB37-A99CC1C1A6A1@xxxxxxxxxxxxxxxx
Currently We have on Storage Group with 1 mailbox store containing around
1000 Mailboxes. I would like to Break this up into Multiple Mailbox
stores
across 3 Storage Groups. My Question Is Will i see a performance hit
putting
the Transaction Logs for all 3 Storage Groups on the Same Disk, since
really
they are already on the same disk now only in the new setup the
Transactions
will be written against the 3 different Logs as apposed to 1.
I am not expecting to see a performance gain, i just dont want to see a
big
loss.
Thanks
.
- Follow-Ups:
- Re: Exchange 2003 Transaction Log Performance
- From: Bharat Suneja [MVP]
- Re: Exchange 2003 Transaction Log Performance
- Prev by Date: Re: Design - Exchange Organization
- Next by Date: Re: Exchange 2003 Transaction Log Performance
- Previous by thread: Re: Exchange 2003 Transaction Log Performance
- Next by thread: Re: Exchange 2003 Transaction Log Performance
- Index(es):
Relevant Pages
|
