Sizing Exchange 2013 for capacity and performance

Exchange 2013 - compute resource calculator
Exchange 2013 - storage space capacity calculator
Exchange 2013 Server Role Requirements Calculator

Space requirements

Gather requirements and user data:

Requires 2 pieces of data:

• The average number of messages per user per day
• The average message size

These can be obtained by using:

• Performance monitor: MSExchangeIS\Messages Submitted/sec and MSExchangeIS\Messages Delivered/sec and transport performance counters
• The MessageStats script: User Profile Analysis for Exchange Server 2007/2010/2013
• SCOM reporting (Daily Mailflow Statistics)

Determine mailbox size:

Consider 3 factors: the mailbox storage quota, database white space, and recoverable items.

Estimated size of whitespace is 1 day worth of messaging content:

Number of messages per day x average message size

Deleted items retention at its default time frame (14 days) increases mailbox size for ~1.2%.

Calendar item version logging (on by default) increases mailbox size for ~3%.

In calculating Recoverable Items folder size, these are multiplied with mailbox quota:

mbx quota x 0.012 + mbx quota x 0.03

So, the total mailbox size is the sum of these 3 factors:

Mailbox Size on disk = mailbox quota + database whitespace + Recoverable Items Folder

Content indexing:

The space required for files related to the content indexing process can be estimated as 20% of the database size.

Per-Database Content Indexing Space = database size x 0.20

You must additionally size for one additional content index (e.g. an additional 20% of one of the mailbox databases on the volume) in order to allow content indexing maintenance tasks (specifically the master merge process) to complete.

So, I simply increased the total content indexing to 30% of the total database space:

Total Content Indexing Space = total DBs space requirement x 0.30

Log space:

The value for Number of transaction logs generated per day is based on the message profile selected and the average message size. It indicates how many transaction logs will be generated per mailbox per day. The log generation numbers per message profile account for:

• Message size impact
• Amount of data sent/received
• Database health maintenance operations
• Records Management operations
• Data stored in a mailbox that is not a message (tasks, calendar appointments, contacts)
• Forced log rollover (a mechanism that periodically closes the current transaction log file)

Message profile (75 KB average message size	Number of transaction logs generated per day
50	10
100	20
150	30
200	40

• If the average message size doubles to 150 KB, the logs generated per mailbox increases by a factor of 1.9. This number represents the percentage of the database that contains the attachments and message tables (message bodies and attachments).
• Thereafter, as message size doubles beyond 150 KB, the log generation rate per mailbox also doubles, increasing from 1.9 to 3.8.

In addition to this, the log space requirement factors in 7 days of log truncation failure (it’s assumed that a full DB backup runs daily and truncates logs regularly, so this space provides capacity for a week of logs in case the backup keeps failing for 7 days) and logs generated by moving 1% of all mailboxes per week.

Log capacity to support 7 days of truncation failure = (number of mailboxes x number of logs/day) x 7 days

Log capacity to support 1% mailbox moves per week = number of mailboxes x 0.01 x mailbox size

So, the total log capacity is calculated as:

Total local capacity required = Log capacity to support 7 days of truncation failure + Log capacity to support 1% mailbox moves per week

Compute requirements

Calculate IOPS requirements

Messages sent or received per mailbox per day	Estimated IOPS per mailbox
50	0.034
100	0.067
150	0.101
200	0.134
250	0.168
300	0.201
350	0.235
400	0.268
450	0.302
500	0.335

Storage bandwidth requirements

While IOPS requirements are usually the primary storage throughput concern when designing an Exchange solution, it is possible to run up against bandwidth limitations with various types of storage subsystems. The IOPS sizing guidance above is looking specifically at transactional (somewhat random) IOPS and is ignoring the sequential IO portion of the workload. One place that sequential IO becomes a concern is with storage solutions that are running a large amount of sequential IO through a common channel. A common example of this type of load is the ongoing background database maintenance (BDM) which runs continuously on Exchange mailbox databases. While this BDM workload might not be significant for a few databases stored on a JBOD drive, it may become a concern if all of the mailbox database volumes are presented through a common iSCSI or Fibre Channel interface. In that case, the bandwidth of that common channel must be considered to ensure that the solution doesn’t bottleneck due to these IO patterns.

In Exchange 2013, we expect to consume approximately 1MB/sec/database copy for BDM which is a significant reduction from Exchange 2010.

Transport storage requirements

Transport storage capacity is driven by two needs: queuing (including shadow queuing) and Safety Net (which is the replacement for transport dumpster in this release). You can think of the transport storage capacity requirement as the sum of message content on disk in a worst-case scenario, consisting of three elements:

• The current day’s message traffic, along with messages which exist on disk longer than normal expiration settings (like poison queue messages).
• Queued messages waiting for delivery.
• Messages persisted in Safety Net in case they are required for redelivery.

To determine the maximum size of the transport database, we can look at the entire system as a unit and then come up with a per-server value.

Overall Daily Messages Traffic = number of users x message profile

Overall Transport DB Size = average message size x overall daily message traffic x (1 + (percentage of messages queued x maximum queue days) + Safety Net hold days) x 2 copies for high availability

Microsoft’s best practices guidance for the transport database is to leave it in the Exchange install path (likely on the OS drive) and ensure that the drive supporting that directory path is using a protected write cache disk controller, set to 100% write cache if the controller allows optimization of read/write cache settings. The write cache allows transport database log IO to become effectively “free” and allows transport to handle a much higher level of throughput.

Processor requirements

CPU sizing for the Mailbox role is done in terms of megacycles. A megacycle is a unit of processing work equal to one million CPU cycles. In very simplistic terms, you could think of a 1 MHz CPU performing a megacycle of work every second. Given the guidance provided below for megacycles required for active and passive users at peak, you can estimate the required processor configuration to meet the demands of an Exchange workload. Following are our recommendations on the estimated required megacycles for the various user profiles.

Messages sent or received per mailbox per day	Mcycles per User, Active DB Copy or Standalone (MBX only)	Mcycles per User, Active DB Copy or Standalone (Multi-Role)	Mcycles per User, Passive DB Copy
50	2.13	2.93	0.69
100	4.25	5.84	1.37
150	6.38	8.77	2.06
200	8.50	11.69	2.74
250	10.63	14.62	3.43
300	12.75	17.53	4.11
350	14.88	20.46	4.80
400	17.00	23.38	5.48
450	19.13	26.30	6.17
500	21.25	29.22	6.85

 
The internal architecture of modern processors is different enough between manufacturers as well as within product lines of a single manufacturer that it requires an additional normalization step to determine the available processing power for a particular CPU. We recommend using the SPECint_rate2006 benchmark from the Standard Performance Evaluation Corporation.

Keep in mind that a good Exchange design should never plan to run servers at 100% of CPU capacity. In general, 80% CPU utilization in a failure scenario is a reasonable target for most customers. Given that caveat that the high CPU utilization occurs during a failure scenario, this means that servers in a highly available Exchange solution will often run with relatively low CPU utilization during normal operation. Additionally, there may be very good reasons to target a lower CPU utilization as maximum, particularly in cases where unanticipated spikes in load may result in acute capacity issues.

Memory requirements

Recommended amount of memory for the Mailbox role on a per mailbox basis.

Messages sent or received per mailbox per day	Mailbox role memory per active mailbox (MB)
50	12
100	24
150	36
200	48
250	60
300	72
350	84
400	96
450	108
500	120

 
To determine the amount of memory that should be provisioned on a server, take the number of active mailboxes per-server in a worst-case failure and multiply by the value associated with the expected user profile. From there, round up to a value that makes sense from a purchasing perspective (i.e. it may be cheaper to configure 128GB of RAM compared to a smaller amount of RAM depending on slot options and memory module costs).

Mailbox Memory per-server = (worst-case active database copies per-server x users per-database x memory per-active mailbox)

It’s important to note that the content indexing technology included with Exchange 2013 uses a relatively large amount of memory to allow both indexing and query processing to occur very quickly. This memory usage scales with the number of items indexed, meaning that as the number of total items stored on a Mailbox role server increases (for both active and passive copies), memory requirements for the content indexing processes will increase as well. In general, the guidance on memory sizing presented here assumes approximately 15% of the memory on the system will be available for the content indexing processes which means that with a 75KB average message size, we can accommodate mailbox sizes of 3GB at 50 message profile up to 32GB at the 500 message profile without adjusting the memory sizing. If your deployment will have an extremely small average message size or an extremely large average mailbox size, you may need to add additional memory to accommodate the content indexing processes.

Multi-role server deployments will have an additional memory requirement beyond the amounts specified above. CAS memory is computed as a base memory requirement for the CAS components (2GB) plus additional memory that scales based on the expected workload. This overall CAS memory requirement on a multi-role server can be computed using the following formula:

CAS Memory per-server = 2 GB + ((2 GB x ((max number of users x megacycles per user) x 0375) / per-core megacycles))

Regardless of whether you are considering a multi-role or a split-role deployment, it is important to ensure that each server has a minimum amount of memory for efficient use of the database cache. There are some scenarios that will produce a relatively small memory requirement from the memory calculations described above. We recommend comparing the per-server memory requirement you have calculated with the following table to ensure you meet the minimum database cache requirements. The guidance is based on total database copies per-server (both active and passive). If the value shown in this table is higher than your calculated per-server memory requirement, adjust your per-server memory requirement to meet the minimum listed in the table.

Per-Server DB Copies	Minimum Physical Memory (GB)
1-10	8
11-20	10
21-30	12
31-40	14
41-50	16

 
Unified messaging

With the new architecture of Exchange, Unified Messaging is now installed and ready to be used on every Mailbox and CAS. The CPU and memory guidance provided here assumes some moderate UM utilization. In a deployment with significant UM utilization with very high call concurrency, additional sizing may need to be performed to provide the best possible user experience. As in Exchange 2010, we recommend using a 100 concurrent call per-server limit as the maximum possible UM concurrency, and scale out the deployment if the sizing of your deployment becomes bound on this limit. Additionally, voicemail transcription is a very CPU-intensive operation, and by design will only transcribe messages when there is enough available CPU on the machine. Each voicemail message requires 1 CPU core for the duration of the transcription operation, and if that amount of CPU cannot be obtained, transcription will be skipped. In deployments that anticipate a high amount of voicemail transcription concurrency, server configurations may need to be adjusted to increase CPU resources, or the number of users per server may need to be scaled back to allow for more available CPU for voicemail transcription operations.

Active Directory capacity for Exchange 2013

The recommendation is a ratio of 1 Active Directory global catalog processor core for every 8 Mailbox role processor cores handling active load.

AD cores requirements = ((mailbox users x megacycles per active user) / megacycles per core) / 8

Ask the Perf Guy: Sizing Exchange 2013 Deployments
.