User Load and MAPI Operations
[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at http://go.microsoft.com/fwlink/?linkid=34707.]
Topic Last Modified: 2006-10-17
The Microsoft® Exchange Server Analyzer Tool has determined that a few MAPI operations on the server are contributing to a significant percentage of the server user load. This determination is made by querying for operations that are consuming greater than 4 percent of the CPU time relative to total CPU time used in processing all RPC requests.
Common Causes of High CPU Percentage MAPI Operations
An administrator investigating poor Exchange Server performance should review whether the average mailbox size is high on any servers exhibiting poor performance. It should be determined if individual folders are excessively large (more than 5,000 items in a user’s Inbox, Sent Items, Deleted Items, or Calendar folder). Large folders and mailbox growth can lead to increased CPU and I/O load. An increase in the number of views for each folder can also add overhead to many MAPI operations.
Many of the common, long-running MAPI operations are related to views. A couple of the prominent ones are Restrict and FindRow. These operations do not always take a long time, and if their performance is a problem, you should understand why. Also note that, in addition to the following reasons, anytime there is a bottleneck for resources (generally a disk or CPU bottleneck), the latencies of operations will increase.
Sometimes there may be a high cost in TaskQ User Known in conjunction with Restrict or FindRow operations; this is because some of the work for these operations is performed in a TaskQ and the cost is attributed to TaskQ User Known.
The MAPI Restrict operation is used to select items that match particular criteria. The server creates a view that is, effectively, a table with associated criteria called a restriction. If the view that has a matching restriction already exists, the server uses the existing view to satisfy the user request. Using this view is relatively inexpensive; however, creating a new view is relatively expensive. By default, the store caches only 11 views for each folder. If the server is asked to create a twelfth view, it deletes the oldest cached view and create a new view. Views add overhead to all actions on items that match the views restriction.
Client applications use the MAPI operations SeekRow or FindRow to move the cursor between rows in a view. SeekRow specifies how many rows to move the cursor, and is very low-cost in terms of CPU time. FindRow is quite expensive because it moves the cursor to the first item in a non-materialized (won't 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 cost that can occur with Restrict and FindRow makes these good candidates for running cached mode which would get the cost off the server. Be aware that, sometimes, the high CPU percentage consumed by these may just be caused by shared calendars, in which case cached mode won’t help. High consumption of percentage of CPU time by these operations could indicate a lot of view creation, expensive views, or large folder item counts.