Re: Exchange 2003 Transaction Log Performance

<gasp> thanks for the detailed explanation John...

BM, the storage guru has spoken. :)
--
Bharat Suneja
MVP - Exchange
www.zenprise.com
NEW blog location:
www.exchangepedia.com/blog
----------------------------------------------



"John Fullbright [MVP]" <fjohn@donotspamnetappdotcom> wrote in message
news:%23uU3ZVYFHHA.4588@xxxxxxxxxxxxxxxxxxxxxxx
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






.

Relevant Pages

  • Re: Exchange 2003 Transaction Log Performance
    ... Instead of one thread writing, ... The IO pattern will ... The seek time is the major component of disk access time. ... order to achieve a purely sequential workload, you'd need to be able to ...
    (microsoft.public.exchange.design)
  • Re: Why does MAIL DIR go slow during mail receive?
    ... Do you have more than one storage disk? ... > I have a question about an observed slowness in VMS MAIL. ... > directory while a different user sat in MAIL doing the DIR command. ...
    (comp.os.vms)
  • Re: [semi-OT] USB floppy?
    ... I've not had any trouble myself, but I've only used four card readers ... storage model now, supported by everyone and their electronic dog. ... then schedule all your backups to it; ... backups of the whole thing to a plain disk or three somewhere else, ...
    (uk.comp.sys.mac)
  • SUMMARY: Disk to Tape Virtualization devices
    ... autoarchiving special filesystems to tape. ... HP STORAGEWORKS offers some good storage virtualization tools. ... You can supply your own disk for cheap. ... looking at upgrading to Veritas Netbackup 5.0 later this year. ...
    (SunManagers)
  • Re: LimpM, why the umbilical and the storage arrangement with the PDP10?
    ... The same reason that people use network storage appliances now. ... been prohibitively expensive to put much disk space on each machine. ... command shell and it would prompt for filenames and give you filename ...
    (comp.lang.lisp)
Loading