?
Solved

Performance issue found on disk containing transaction log files Exchange 2007

Posted on 2009-12-22
6
Medium Priority
?
478 Views
Last Modified: 2012-05-08
I installed exchange 2007 in a HP DL380 G6 running win 2008 std 64bit. This exchange server coexist with my exisitng exchange 2003. I moved about 200 users already but lately, I noticed we are having some performance issues. The operating system is installed on the the C:\ drive. Exchange and databases are installed in the D:\ drive. Both partitions are running in the same RAID5. The total free space is about 50% for my D:\ drive. I am wonderign if I shrink my d:\ drive and create a new partition would help. Everythign would still reamin on the same RAID 5 with SAS hard drives anyway.
Thanks for any help!
Moises Perez

exchange2007-error.jpg
0
Comment
Question by:moisesperez
  • 3
  • 2
6 Comments
 

Author Comment

by:moisesperez
ID: 26108488
I just added a screenshot from the server
0
 
LVL 58

Accepted Solution

by:
tigermatt earned 1600 total points
ID: 26108880

>> Both partitions are running in the same RAID5

If you are hitting the server hard, that's going to be where the problem is. Using separate partitions doesn't improve performance at all, because the same RAID array (and therefore the same disks) are being used to service all the partitions on that array. Creating new partitions on the same array is not going to improve the situation at all - if anything, it could make it worse.

Transaction Logs also require very low latency storage, otherwise you will see performance issues. This is what the error message you see above is warning you about. RAID 5 is not necessarily low latency for write operations (compared with other flavours of RAID), and this is particularly apparent when one array is split into separate partitions.

The usual recommendation for an Exchange Server is to install the Operating System, Exchange application files and page file on a RAID 1 (mirror) array. This requires 2 disks and would become your drive C:. A second ARRAY (not just another partition, a completely isolated array in its own right), also RAID 1 with 2 disks, would be dedicated to the transaction logs. RAID 1 is low latency but still has redundancy, should one disk fail. Finally, again, a third ARRAY in RAID 10 would be recommended to store the Exchange databases. RAID 10 is good on performance for database work, which involves a lot of random reads and writes to disk. RAID 10 requires 4 disks, but you can't achieve the same performance with a RAID 5 array until you start increasing the number of disks in the array considerably.

Since this is a new server, I would certainly be looking to get this issue resolved. The values you are seeing are only a millisecond off the recommended value, so it's debatable whether you do anything (and I'm sure other people will post here with their own opinion). However, I know from experience that with your number of users, a single RAID 5 array isn't going to be your best solution. If you can, get the RAID sorted out as I described above; if you can't, I'd suggest at least installing a RAID 1 array specifically for transaction logs.

-Matt
0
 
LVL 47

Assisted Solution

by:David
David earned 400 total points
ID: 26108889
both disks are using the same disk drive(s), so I/Os from C compete with I/Os from D.    Unless you are under 10% free, give-or-take on C, or you can't defrag, then it doesn't matter what block number on the logical disk separates C from D.   The RAID controller doesn't do anything differently.

Buy 2 more SAS disks and set them up as a RAID1, set it to 64KB NTFS allocation size, then migrate SQL to it.  THEN you'll see a nice improvement.
0
Fill in the form and get your FREE NFR key NOW!

Veeam is happy to provide a FREE NFR server license to certified engineers, trainers, and bloggers.  It allows for the non‑production use of Veeam Agent for Microsoft Windows. This license is valid for five workstations and two servers.

 

Author Closing Comment

by:moisesperez
ID: 31669197
Thank you Matt and dlethe. I just ordered more hardrives and an extra controller for the server.
Thanks again!
Moises Perez
0
 
LVL 47

Expert Comment

by:David
ID: 26115577
No prob, you might want to run a benchmark before & after and post as a follow-up.  That type of positive feedback can really put things in perspective.  

Here is followup on aligning into 64KB (Full link is at: http://technet.microsoft.com/en-us/library/bb738145%28EXCHG.80%29.aspx )

Most partitions are misaligned when they are using the Disk Management tool. Therefore, we recommend that you create partitions by using the Diskpart.exe tool instead. Aligning sectors to track boundaries can have performance benefits, depending on the storage. Always use the storage vendor's recommended setting, but if your storage vendor does not have a recommended setting, use 64 kilobytes (KB). When running Exchange 2007 on Windows Server 2003, we recommend that you use Diskpart to align the storage track boundaries on all Mailbox servers (including clustered mailbox servers), Edge Transport servers, and Hub Transport servers, regardless of the partition type you are using. For detailed steps about how to use Diskpart to align input/output (I/O) with storage track boundaries, see How to Align Exchange I/O with Storage Track Boundaries. You do not need to use Diskpart when running Exchange 2007 Service Pack 1 (SP1) on Windows Server 2008.

Partition Allocation Unit Size

In Exchange 2007, we recommend that you configure the NTFS file system volumes hosting databases with an NTFS allocation unit size of 64 KB. This recommendation is based on performance improvements seen with large sequential read operations. This type of profile is typically seen with streaming backup and Exchange Server Database Utilities (Eseutil) tasks.

In some scenarios, there is a benefit with sequential I/O, particularly when performing a streaming backup, or when running Eseutil for a Volume Shadow Copy Service (VSS) checksum integrity or database repair. Always use your storage vendor's recommended setting, but if your storage vendor does not have a recommended setting, use 64 KB.

Testing has shown that changing the NTFS allocation size from 4 KB to 64 KB does not result in any increase in transaction log sequential throughput. Therefore, you can utilize the default NTFS allocation size (4 KB) for NTFS volumes hosting transaction log files.
0
 

Author Comment

by:moisesperez
ID: 26115618
ok. thank you!
Moises
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Want to know how to use Exchange Server Eseutil command? Go through this article as it gives you the know-how.
Stellar Exchange Toolkit: this 5 in 1 toolkit comes loaded with mega-software tool. Here’s an introduction to tools’ usage and advantages:
To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
how to add IIS SMTP to handle application/Scanner relays into office 365.
Suggested Courses
Course of the Month15 days, 18 hours left to enroll

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question