Exchange Server Forums
Forums |
Register |
Login |
My Profile |
Inbox |
RSS 
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Big Performance Problem:: Trying to retrieve data from Microsoft Exchange Server
|
Users viewing this topic:
none
|
Logged in as: Guest
|
Login  | |
|
 Limited time MSExchange.org offer! -- 1.Sep.2008 1:00:00 PM
|
|
TechGenix and SolarWinds have partnered to provide free copies of SolarWinds Exchange Monitor to all visitors who join the MSExchange.org Forums. SolarWinds Exchange Monitor is a handy desktop dashboard that continuously monitors Microsoft Exchange to deliver real-time insight into Exchange services, mail queue sizes, and host server health. Learn more about Exchange Monitor and the free offer!
|
Big Performance Problem:: Trying to retrieve data from ... - 1.Oct.2008 12:23:41 PM
|
|
|
IT84
Posts: 4
Joined: 1.Oct.2008
Status: offline
|
For the past couple of days we have been experiencing performance problems with our exchange server. When users go to delete, reply, send, and open messages it takes a long period of time for the task to complete. One user was trying to delete messages and it took about a 3 minuets per email to complete. Users are also reporting that they keep getting a "Trying to retrieve data from Microsoft Exchange Server [servername.domainname.com]" bubble error message periodically thru out the day.
The performance problems seem to be impacting some users more than others, for example, my computer hasn’t had any noticeable performance problems, however I am getting the “trying to connect” error message.
We’ve rebooted the server and plugged the server into a different port on the switch, however that didn’t correct the problem. I’m also wondering if we might be having a problem with the NIC card dropping packets. We also analyzed the hard disk using the disk defrag tool and it recommended that we defrag the data volume; the report is below. Our exchange store size is 47gb for priv1.edb and 24gb for the priv1.stm file.
I was wondering if anyone had any ideas as to other potential causes of the problem, or if you think it might be NIC or the fragmented drive. Any ideas would be greatly appreciated and thanks in advance to anyone who helps.
Disk Defrag Report
-----------
Volume Data (E:)
Volume size = 87.89 GB
Cluster size = 4 KB
Used space = 69.06 GB
Free space = 18.84 GB
Percent free space = 21 %
Volume fragmentation
Total fragmentation = 49 %
File fragmentation = 99 %
Free space fragmentation = 0 %
File fragmentation
Total files = 17
Average file size = 6.27 GB
Total fragmented files = 4
Total excess fragments = 728
Average fragments per file = 43.82
Pagefile fragmentation
Pagefile size = 0 bytes
Total fragments = 0
Folder fragmentation
Total folders = 7
Fragmented folders = 1
Excess folder fragments = 0
Master File Table (MFT) fragmentation
Total MFT size = 560 KB
MFT record count = 44
Percent MFT in use = 7 %
Total MFT fragments = 2
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 1.Oct.2008 1:21:06 PM
|
|
|
jveldh
Posts: 635
Joined: 12.Apr.2008
From: The Netherlands
Status: offline
|
Hi,
Have a look with perfmon if disk queueing is the issue. This can be a reason why users get this messages. Also check the NIC settings on both the switch and the NIC. Make sure their set to both the same value.
If a lot of users have cleaned up their mailboxes perform an offline defrag of thr Exchange DB.
Also check the event log for strange events.
_____________________________
Best regards,
Johan Veldhuis
Visit my website
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 1.Oct.2008 1:28:43 PM
|
|
|
Sembee
Posts: 3500
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
|
Don't defrag the drive Exchange databases are on, unless you want to practise disaster recovery procedures. Due to the way the Exchange database works a fragmented file system will have zero impact.
However I also would not recommend an offline defrag. Offline defrag should not be considered something that needs to be done as routine and is not something I do as a rule.
Most Exchange performance issues are caused by the disk system. I would suggest running the Exchange best practises tool on the server, see if it flags anything, and then run the performance tool. You can get both from http://www.exbpa.com/
Simon.
_____________________________
Simon Butler,
Exchange MVP
Blog: http://www.sembee.co.uk/
Web: http://www.amset.info/
In the UK? Hire me: http://www.amset.co.uk/
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 1.Oct.2008 3:53:05 PM
|
|
|
IT84
Posts: 4
Joined: 1.Oct.2008
Status: offline
|
I ran the Best Practices Analyzer and it didn’t find any thing that was performance related, however the Troubleshooting Assistant found a bunch of problems, which I’ve listed below. Do you think that adding a second disk array to the server, splitting the store, moving part of it to the new array, and then doing an offline defrag on the original store would be a good course of action? Any other advice that anyone offers would be greatly appreciated. Thank you.
Troubleshooting Assistant Report
----------------------
SMTP drive: Average '\LogicalDisk(D:)\Avg. Disk sec/Write' should be less than 10 (0.01 ms). The measured value is 0.237 (237 ms).
Database disk: The average value for '\LogicalDisk(E:)\Avg. Disk sec/Read' should be less than 0.02 (20 ms). The measured value is 0.026 (26 ms).
Database disk: The maximum value for '\LogicalDisk(E:)\Avg. Disk sec/Read' should be less than 0.05 (50 ms). The measured value is 0.296 (296 ms).
Page file drive: The average value for '\LogicalDisk(F:)\Avg. Disk sec/Write' should be less than 0.01 (10 ms). The measured value is 0.237 (237 ms).
TEMP drive: The average value for '\LogicalDisk(C:)\Avg. Disk sec/Read' should be less than 0.01 (10 ms). The measured value is 0.06 (60 ms).
TEMP drive: The maximum value for '\LogicalDisk(C:)\Avg. Disk sec/Read' should be less than 0.05 (50 ms). The measured value is 1.351 (1351 ms).
TEMP drive: The average value for '\LogicalDisk(C:)\Avg. Disk sec/Write' should be less than 0.01 (10 ms). The measured value is 0.27 (270 ms).
TEMP drive: The maximum value for '\LogicalDisk(C:)\Avg. Disk sec/Write' should be less than 0.05 (50 ms). The measured value is 2.823 (2823 ms).
Transaction log disk: The average value for '\LogicalDisk(D:)\Avg. Disk sec/Write' should be less than 0.01 (10 ms). The measured value is 0.237 (237 ms).
Transaction log disk: The maximum value for '\LogicalDisk(D:)\Avg. Disk sec/Write' should be less than 0.05 (50 ms). The measured value is 2.106 (2106 ms).
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 1.Oct.2008 5:06:17 PM
|
|
|
Sembee
Posts: 3500
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
|
How are the hard disks physically configured?
How much white space is in the store? Look for event ID 1221.
The major performance gain is splitting the database from the transaction logs.
Simon.
_____________________________
Simon Butler,
Exchange MVP
Blog: http://www.sembee.co.uk/
Web: http://www.amset.info/
In the UK? Hire me: http://www.amset.co.uk/
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 2.Oct.2008 7:26:07 AM
|
|
|
IT84
Posts: 4
Joined: 1.Oct.2008
Status: offline
|
We have three 73gb disks in a RAID 5 for a total capacity of 135gb in that array. That array has 4 partitions; the configuration of the partitions is below. Thanks again for the help.
C:\ - Capacity:15gb Free:4gb (System)
D:\ - 19gb/12gb (Programs)
E:\ - 87gb/18gb (Data)
F:\ - 12gb/10gb (Paging)
Here is the 1221 Event ID from the Exchange server’s log.
-------
Event Type: Information
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1221
Date: 10/2/2008
Time: 5:03:10 AM
Description:
The database "First Storage Group\Mailbox Store (SERVERNAME)" has 1081 megabytes of free space after online defragmentation has terminated.
Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: General
Event ID: 1221
Date: 10/2/2008
Time: 4:01:00 AM
Description:
The database "First Storage Group\Public Folder Store (SERVERNAME)" has 35 megabytes of free space after online defragmentation has terminated.
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 2.Oct.2008 10:01:20 AM
|
|
|
uemurad
Posts: 5469
Joined: 7.Jan.2004
From: California, USA
Status: online
|
Best practices dictates that you separate your Log files from your Database files. If you can also separate the OS/Application files into a third partition that is even better.
Understand that this refers to physical drive sets, not logical ones. Transactional Logs are very write-intensive, as are the database files. Having them on the same physical drives means your drive heads are constantly in contention.
If your hardware can accommodate it, the best situation is:
OS/Application files on a RAID1 drive set
Transactional logs on a separate RAID1 drive set
Exchange database files on a RAID5 drive set
The OS/Application and transactional log drive sets can be combined into a single set without much of a performance hit.
_____________________________
Regards,
Dean T. Uemura
Microsoft MVP - Exchange
exchangeguy.blogspot.com
uemurad@yahoo.com
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 2.Oct.2008 5:57:54 PM
|
|
|
Sembee
Posts: 3500
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
|
To echo what is being said above - your performance hit is because you have a single array. Partitions do nothing for performance.
I usually combine the OS and the transaction logs on the same array, but in different partitions, with the database on its own array.
You need to get some more disks and create a new array and separate the database and the transaction logs. Nothing else will resolve the problem.
Simon.
_____________________________
Simon Butler,
Exchange MVP
Blog: http://www.sembee.co.uk/
Web: http://www.amset.info/
In the UK? Hire me: http://www.amset.co.uk/
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 8.Oct.2008 9:58:25 AM
|
|
|
IT84
Posts: 4
Joined: 1.Oct.2008
Status: offline
|
I just wanted to give an update. We have ordered 3 additional drives and are planning to migrate all of the mailboxes to a new RAID5. That way we will have our system volume, transaction log, and paging on their own array, and the mail stores on their own array. We have also ordered a new Smart Array 6400 RAID controller to replace our Smart Array 641 controller.
In fact, we tried to do the whole upgrade last night. We got the new controller in; however one of the new hard disks that we got were bad, so we have to wait for them to ship another drive in order to build our new array.
Once we have completed our upgrade the new disk configuration will look like what I have listed below. Do you think that we will need to split up the first array some more? Because, we aren’t going to have any more available bays after the upgrade. Thanks again for everyone’s help.
RAID 5 #1
Disk 0, 1, 2
System volume, Program volume,
Paging volume, and Transaction log.
RAID 5 #2
Disk 3, 4, 5
Mail stores
|
|
|
|
|
RE: Big Performance Problem:: Trying to retrieve data f... - 8.Oct.2008 7:05:42 PM
|
|
|
Sembee
Posts: 3500
Joined: 17.Jan.2008
From: Somewhere near London, UK
Status: offline
|
Keeping the logs and the database separate should be fine. The only slight performance gain you would get is a complete rebuild of the first array from a RAID 5 to a mirrored system, but that is a major impact so I wouldn't consider doing it.
Simon.
_____________________________
Simon Butler,
Exchange MVP
Blog: http://www.sembee.co.uk/
Web: http://www.amset.info/
In the UK? Hire me: http://www.amset.co.uk/
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
Printable Version
