Long-running MAPI 'FindRow' operation
Topic Last Modified: 2006-11-22
The Microsoft® Exchange Server Analyzer Tool uses the Exchange Server User Monitor (ExMon) tool to determine whether user MAPI operations are taking longer than should reasonably be expected on a healthy Exchange server.
As part of its analysis, the Exchange Server Analyzer reviews the ExMon data for user issued MAPI FindRow operations that have taken longer than 30 seconds to be completed.
An increase in the number of views for each folder can add overhead to many MAPI operations. Client applications use the MAPI operations SeekRow or FindRow to move the pointer between rows in a view. SeekRow specifies how many rows to move the pointer, and is very low-cost with regard to CPU time. FindRow is very expensive because it moves the pointer to the first item in a non-materialized (will not be cached) view that matches the restriction criteria, and then discards the view after the client application is finished with the action. The ultimate CPU cost of FindRow depends on the complexity of the restriction, and how many rows the store has to review before finding the first item that matches the criteria and so is loosely correlated with the number of items in the folder.
The high costs that can occur with FindRow make it a good candidate for running cached mode which would get the cost off the server. Be aware that, sometimes, the high CPU percentage consumed by this may merely be caused by shared calendars, in which case cached mode will not help. High consumption of percentage of CPU time by the FindRow operations could indicate lots of view creation, expensive views, or large folder item counts.
If the Exchange Server Analyzer determines that a user issued MAPI FindRow operation has taken longer than 30 seconds, the Exchange Server Analyzer displays an error.
MAPI FindRow operations taking longer than 30 seconds may not always be a problem. If the identified user or users are experiencing frequent delays, or delays that adversely affect their messaging experience, you should understand why. Work with the user experiencing the high latency to determine:
If the item counts in folders are high.
What applications the user is running.
To address this issue:
Encourage users who have many items in their folders to reduce the number of items per folder. We recommend that you keep items in the Inbox, Calendar, Sent Items, Contacts and Deleted Items folders under 5,000.
Configure the most operationally expensive client computers (especially those with long latencies on Restrict, SetColumns or FindRow operations) to use Cached Exchange Mode. Cached Exchange Mode isolates the server from most of the excess RPC traffic.
Try turning off all the applications and then turn them on one by one to find which one might be causing the problem. If these applications are not required for business, or if the applications have a published hot fix, permanently turn off the applications or update them to reduce the load to an appropriate level.
|Some applications can significantly increase server load without issuing lots of MAPI operations. This is because some operations are more expensive than others. It may take only a small increase in the number of costly operations to noticeably affect server performance. In ExMon, these users are reported as having a high CPU effect, without necessarily having issued lots of MAPI operations.|
Also be aware that when there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies for the FindRow operations will increase.
For more information, see the following Exchange Server resources:
Performance and Scalability Guide for Exchange Server 2003 (http://go.microsoft.com/fwlink/?LinkId=47576)
Troubleshooting Microsoft Exchange Server Performance (http://go.microsoft.com/fwlink/?LinkId=47588)
Exchange Server 2003 Performance: 10 Things to Think About (http://go.microsoft.com/fwlink/?LinkId=56460)
Microsoft Knowledge Base article 905803, "Outlook users experience poor performance when they work with a folder that contains many items on a server that is running Exchange Server 2003 or Exchange 2000 Server" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=905803)