There are two approaches to calculating your disk I/O requirements:
Determine user needs based on theoretical data
Calculate user activity by using the Performance console (Perfmon)
Regardless of your approach, you should plan and calculate based on peak usage periods. In many companies, this occurs at the beginning of business hours, as people arrive at work and check their e-mail.
Calculating I/O Using Theoretical Data
If you do not have Exchange installed but want to plan for impending storage needs that result from an Exchange deployment, you can use data that has already been collected. This data is in the form of mailbox profiles, which describe general usage patterns for Exchange mailboxes.
The following table lists mailbox profiles that can be used as a guideline for capacity planning of Exchange mailbox servers. These profiles represent mailbox access for the “average user” Outlook (or MAPI-based) client within the organization.
User profiles and corresponding usage patterns
User Type
Database Volume IOPS
Send/Receive per day
Mailbox Size
Light
.5
20 sent/50 received
50 MB
Average
.75
30 sent/75 received
100 MB
Heavy
1.0
40 sent/100 received
200 MB
Large
1.5
60 sent/150 received
500 MB
Each profile represents total I/O to the Jet database and does not include I/O related to transaction log file activity. In order to accurately calculate your disk subsystem load, you must split this database I/O into read and write I/O because write operations are more I/O intensive than reads.
To help estimate your own read/write ratio, consider the usage patterns of a company that has a heavy mailbox profile. In a production environment, the company can expect to incur read/write ratios between 75/25 percent and 66/33 percent, depending on the group of users being evaluated.
For a mail system consisting of 2,000 heavily used mailboxes, a total of 1,500 IOPS is generated on the database volume. The formula to calculate this is:
Estimated IOPS per User for User Type × Number of Users
In this example, .75 IOPS × 2,000 mailboxes=1,500 IOPS.
Using a conservative ratio of two reads for every write (66 percent reads to 33 percent writes), you would plan for 1,000 read I/O and 500 write I/O requests per second for your database volume. Every write request is first written to the transaction log file and then written to the database. Approximately 10 percent of the total 1,500 IOPS seen on the database volume will be seen on the transaction log volume (10 percent of 1,500 is 150 IOPS); 500 write I/O requests will be written to the database.
These estimated profiles are for an Exchange server that has no other components installed beyond the base operating system. If other variables, such as third-party Personal Information Management (PIM) software, MAPI-based virus scanning (server and client side), management and monitoring software, or backup software are used during peak usage periods, these profiles will not adequately describe the I/O profile in your organization. In these cases, you must also factor in the additional reads and writes that are requested by these applications.
Database IOPS based on Mailbox count
Database IOPS every 1000 mailboxes
Mailboxes
Database Volume IOPS
IOPS
Actual IOPS
1000
1.0
1000
1000
2000
1.0
2000
2500
3000
1.0
3000
3750
4000
1.0
4000
5000
When you increase the number of users with similar profiles on an Exchange Server, more users must compete with the database cache causing an increase in database disk transfers.
For Example:
1000 mailboxes at 1.0 IOPS produce 1000 IOPS on the database logical unit number (LUN). If you double the number of users with the same profile to 2000, then the formula is: 1.0 IOPS x 2000 mailboxes x 1.25 = 2500 IOPS.
Database IOPS based on Database count
Databases
IOPS Factor
Actual IOPS
1
0%
1000
2
2%
1020
4
6%
1060
8
14%
1140
10
18%
1180
20
38%
1380
The benefits of single instance storage are reduced as you add databases to an Exchange server. The degree of the impact is dependant upon the user profile and the average message size. For Example; if you have 1000 users on 1 database, consuming 1000 database IOPS, splitting those users into 10 databases would consume 18 percent more database IOPS, or 1180 IOPS. When someone sends a 10 MB PowerPoint file as an attachment to 20 mailboxes and they all reside on the same database, only 10 MB is written to the database. If those same 20 recipients are on different databases, 200 MB must be written to disk; a twenty fold increase in write activity. This data is based on the MMB3 test which uses a significant number of distribution lists and is a heavy corporate profile.
User Type
Outlook Cached Mode
Outlook Online Mode
Inbox Size
Corporate
1.0 IOPS
1.0 IOPS
10,000 Items – 500MB
Large
1.0 IOPS
1.25 IOPS
20,000 Items – 1Gb
Huge
1.0 IOPS
1.75 IOPS
40,000 Items – 2GB
With Outlook cached mode, many common disk intensive tasks are performed on the client. The initial full sync in Outlook cached mode is a disk intensive activity, yet it is rarely done. With Outlook online mode, searches and sorts are performed on the server. After the initial index creation, it is automatically updated as mail is received. Users that have an abnormally large number of indexes can exceed the limit, causing some of the indexes to be recreated. Some Outlook plug-ins and external applications create indexes and cause additional physical disk pressure. When moving from 500 MB to 1 GB the physical disk cost to the database increased approximately 25 percent, while a 1 GB to 2 GB change increased the database physical disk cost approximately 40 percent.
Home
Calculating I/O Using Theoretical Data