Re: Splitting our Exchange 2003 Ent Database
- From: "John Fullbright" <fullbrij@xxxxxxxxxxx>
- Date: Tue, 14 Feb 2006 14:24:14 -0800
Database - Log record stalls/dec
Database - Page Fault stalls/sec
Physical disk - sec/write
Physical disk transaction/sec
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E6BDAB48-A149-4671-91C8-FB047797664D@xxxxxxxxxxxxxxxx
I am moitoring log stalls/sec on the infomation store and they average in
permon at 0.01, what other counters would you recommend. We get the
Avd.Disk
sec/write remains below 20ms but does stick to 50-60ms for a second every
now
and then, what I mean is 3-4mins for a second or two.
"John Fullbright" wrote:
An exchange database is a B+tree. The difference between a Btree and a
B+tree is that in a B+tree you can have more than one index. Exchange
does
it's own memory management of buffers. A certain number of buffers are
allocated for database pages, and when a page is not present a database
page
fault occurs and the page is retrieved from disk. Of course, buffers in
RAM
are limited. Exchange uses an LRU-K algorithm to determine which pages
to
drop. One cause of lateny is the time it takes to load a page from disk
into the database buffers. If a page is locked, it cannot be dropped and
if
no pages can be dropped, no new pages can be loaded. This is called a
database page fault stall. This is another source of latency.
Transactions that are to be written are first assembled in the database
buffers. When ready the transaction is transferred to the log buffers.
When log buffers reach the high water mark, a forced commit is used to
persist the log buffers to the current log file. During a forced commit,
all client IO is quiesced. This is called a log stall, and is the most
visible source of latency from a user perspective. The duration of the
log
stall depends on how fast the buffers are flushed to disk, or the speed
of
your log drive. This is probably the most common cause of perceived
latency. If you have a serious log bottleneck, you will not only see log
stalls, but the number of locked pages in the database buffer will
prevent
reading new pages into the buffers, and you will also have a database
page
fault stall.
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:AF1C0DA5-9A7B-41B9-B946-7C075B91E0DE@xxxxxxxxxxxxxxxx
Thanks. Our F drive (Databases) does go over 20ms for the Physical
Disk -
sec/write, quite often it hits 50-60ms (0.050).
For my understanding how does the transaction logs on the E drive
(separate
RAID and RAID card) affect the speed of the Physical Disk - sec/write
on
the
F drive. In my eyes they are working on different spindles. On the C
and
E
drive the perfmon stats are hardly even registering anything over the
day.
"John Fullbright" wrote:
At a minimum, you need to get your transaction logs on a seperate set
of
spindles.
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9B5A4F72-E488-4DF4-9115-E1BC2C0753A6@xxxxxxxxxxxxxxxx
What would you suggest as a quick fix for the moment, as we will
have
no
chance to put the RAID 5 to 10. As I say, it's not too bad just
occationally
every other day we might get a 5 min "blip"
4 x 3.2 Xeons, 4GB mem.
c: = Where Exchange Enterprise is installed
Where OS (Windows 2003 Ent)is installed
Where Paging file is installed
Hardware RAID 1
e: = Transaction logs
Hardware RAID 1
f: = Priv (90GB) and Pub DB's (10GB)
Hardware RAID 5
"John Fullbright" wrote:
Physical Disk - sec/write. The average should be below 20ms (.020)
and
you
should see no peaks higher than 50ms (.050) lasting more than a few
seconds.
Source: "Optimizing Storage for Exhange Server 2003"
Database - Log record stalls/sec. The average should be less than
10
and
you should see no peaks higher than 100.
Source: http://support.microsoft.com/kb/328466/en-us
Physical Disk - Transactions/sec and MSExchangeIS - Active User
count.
Use
these to calculate IOPS/user.
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A3D58CC3-4CB4-4D19-8CC5-D9FF29519F81@xxxxxxxxxxxxxxxx
What perfmon disk counters can I run to get a baseline and what
shoulr
the
average around?
"SW" wrote:
what do you mean by spindles?
"John Fullbright" wrote:
No.
Your log files, the most sensitive aspect of exchange IO from
a
user
visibility perspective, are competing with the OS, the page
file,
the
system
temp directory, and the kitchen sink for IO. You need to have
the
logs
on
an isolated set of spindles. You have 7 drives now. If you
add
an
8th
and
reconfigure, you have a mirror for the OS, a mirror for the
logs,
and
RAID
10 for the databases. RAID 10 with 4 spindles outperforms RAID
5
with 5
spindles.
Back in the Outlook 2000 days, read/write ratios used to be
3:1
or
4:1.
These days, with improvements in client side caching, they're
more
like
2:1.
RAID 5 performance is very assymetrical favoring reads over
write
by
4:1.
Write performance of RAID 5 quickly becomes a bottleneck when
the
read
write
ratio is lower.
For example, you are currently saying you have a mirror for
your
logs
and
RAID 5 for the databases.
For a mirror, max write performance = P*N/2. 85*2/2 = 85
For a 5 drive RAID 5 max write performance = P*N'/4 = 85*4/4
=85
For RAID 10 with 4 spindles, max write performance = P*N/2 =
170
Read performance for a 4 drive RAID 10 and a 5 drive RAID 5
are
identical at
340
For a 2:1 read write ratio, RAID 5 Mixed performance = 252
For a 2:1 read write ratio, RAID 10 Mixed performance = 280
and
this
is
with one less spindle than the RAID 5 set.
For a 6 spindle RAID 10 Set:
Read = 510
Write = 255
Mixed = 421
Compare this to RAID 5 with 6 spindles
Read = 425
Write = 106
Mixed = 315
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D8470751-D95E-4392-BB02-0430B475811C@xxxxxxxxxxxxxxxx
Sorry I was slightly wrong:
OS and transactions are on a Mirror. DB is on a RAID 5. It
is
using
2
RAID
cards one for each RAID. Any better?
"John Fullbright" wrote:
And the source of your problem is "5 disk as RAID 5 for DB
and
transactions".
Let's say these ar 10K scsi spindles and every client uses
ol2k3
cached
mode. Your read/write ratio is 2:1.
P=85 at a target 20ms IO
N=5
N'=4
Read perf = P*N' = 85*4 = 340
Write perf=P*N'/4=85*4/4=85
Performance = 340*.66+85*.33 = 224 + 28 = 254. With both
the
logs
and
databases on the same physicals, you might get 100 users on
there
before
you
start seeing performance issues.
Loose the RAID 5, add a spindle and go with a mirror for
the
logs
and
RAID
10 for the databases.
log performance will go to 128 IOPS, and database to 285.
You
will
have
physical seperation of the log and database spindles.
"SW" <SW@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:9EB1C305-5DC4-4DB1-8A83-24C0C289E17A@xxxxxxxxxxxxxxxx
Out Exchange 2003 private DB is 100GB. We are getting
users
saying it
is
slow/sluggish sometimes. Ther is a Dual Xeon Dell
Server,
with
4GB
Mem, 2
disks as RAID 1 for OS, 5 disk as RAID 5 for DB and
transactions.
Users
use
Outlook 2k and 2003.
We are thinking of creating a new storage group and
putting
a
couple of
departments in it then doing an offline defrag of both
DB's
and
the
public
DB. Would this provide better performance? If so why?
Thanks
.
- References:
- Re: Splitting our Exchange 2003 Ent Database
- From: John Fullbright
- Re: Splitting our Exchange 2003 Ent Database
- From: John Fullbright
- Re: Splitting our Exchange 2003 Ent Database
- From: SW
- Re: Splitting our Exchange 2003 Ent Database
- From: SW
- Re: Splitting our Exchange 2003 Ent Database
- From: John Fullbright
- Re: Splitting our Exchange 2003 Ent Database
- From: SW
- Re: Splitting our Exchange 2003 Ent Database
- From: John Fullbright
- Re: Splitting our Exchange 2003 Ent Database
- From: SW
- Re: Splitting our Exchange 2003 Ent Database
- From: John Fullbright
- Re: Splitting our Exchange 2003 Ent Database
- From: SW
- Re: Splitting our Exchange 2003 Ent Database
- Prev by Date: Re: Hotfix 898060 still required for Exch2003?
- Next by Date: Re: Restoring deleted items
- Previous by thread: Re: Splitting our Exchange 2003 Ent Database
- Next by thread: Re: Splitting our Exchange 2003 Ent Database
- Index(es):
Relevant Pages
|
Loading
