Re: Unlikely performance issues
- From: Nico <Nico@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 19 Jun 2006 06:10:02 -0700
You are wrong about using RAID 5 at all in an Exchange environment.Ok, I don't agree but thats not the point right now :)
A common cause of clients experiencing problems are stalled log writesOk. That was what I guesed. Is their a way to measure the delay in log
writes or something like that? I need to be sure since I alread bought some
upgrades (extra memory) for that machine. And since 2 extra SCSI disk is
quite an upgrade for a 50 mailbox server i need to be very sure...
"Nuevo" wrote:
You are wrong about using RAID 5 at all in an Exchange environment. The.
reads might be fine but the write penalty is a significant issue. Why are
you sure you are having problems with reading? A common cause of clients
experiencing problems are stalled log writes. I do agree that 50 users is a
small number to be causing a problem which is why I suggested low
level/hardware diagnostics.
Nue
"Nico" <Nico@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A34CEDA5-8793-4173-8549-6B23EE9ADFE6@xxxxxxxxxxxxxxxx
suffering a write penalty because of the use of RAID 5 which willWell, raid 5 is very fast with read operations. I'm quit sure I am having
certainly slow things done.
troubles with reading data. That's what, in my opinion, is the odd thing.
An ideal disk layout would be mirrored system
drives and separate RAID 10 drives for databases and logs.
I don't agree. Ideal would be RAID 5 for the databases, raid 10 for the
logs, raid 1 for the pagefile. But I still will insist that 50 users with
quite large databases shouldn't hurt performance so much as it does. I'm
quite sure something else is wrong.
"Nuevo" wrote:
You are suffering a write penalty because of the use of RAID 5 which will
certainly slow things done. An ideal disk layout would be mirrored system
drives and separate RAID 10 drives for databases and logs. However, if
you
do not have the ability to do this I would think about moving the
pagefile,
and search catalog to C and put the rest on D. See if this helps. I'd
also
run diagnostics on the disk and controller just to be sure.
Nue
"Nico" <Nico@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C5F5076F-4C00-40FB-A53F-512A111D8626@xxxxxxxxxxxxxxxx
Hi,
We run exchange 2003 (standard) / windows 2003 (standard). The server
has
the following disk configuration:
C: scsi raid 5
D: ide raid 1
c: has the transaction logs + mailbox databases
d: has the search catalog + paging file + public databases
the server has 4GB ram and a xeon 2.4GHz cpu
the exchange server has 50 mailboxes. Avarage mailbox has 7000 items
and
is
about 300 MB. some mailboxes have over 50.000 items and some are larger
than
3GB.
Users have performance issues (outlook reports non responsive exchange
server).
I understand that best performance is reached by having the databases
on
seperate disks, and having the logfiles on seperate disks. In my
opinion
this
shouldn't be necessary on a server with just 50 clients. I don't
understand
that an exchange server, wich should be able to handle 1000ths of
clients
is
having troubles with just 50 of them.
I noticed the following in the performance analyzer:
disk queue/disk time of C: reaches 100% on a simple sort operation in
outlook (size) on my own inbox (10.000 items)
pages/sec has an avarage of 0.2
% processor time has an avarage of 3%
The exchange server performance troubleshooting analyzer only indicates
is
should move my transaction logs to another disk.
So, thing point out that I should move my transaction logs. I just
can't
accept I need more/better hardware for just those few users. Okay
okay,
our
.edb file = 30GB and the .STM = 4 GB.. Is this causing all the trouble?
Any comments are very welcome. Thank you,
Nico Venema
- References:
- Re: Unlikely performance issues
- From: Nuevo
- Re: Unlikely performance issues
- From: Nico
- Re: Unlikely performance issues
- From: Nuevo
- Re: Unlikely performance issues
- Prev by Date: Re: logg disk fills up real fast...
- Next by Date: Re: OWA logon screen
- Previous by thread: Re: Unlikely performance issues
- Next by thread: Re: Unlikely performance issues
- Index(es):
Relevant Pages
|