Archive

Posts Tagged ‘Extensible Storage Engine’

How x64 changed Exchange

September 6, 2010 Leave a comment

Correct me if I’m wrong but Exchange 2007 is the first 64-bit only product from Microsoft. What is the big deal you ask? The answer in few quick points:

  • access to more RAM
  • Less disk I/O for Exchange (because we get more RAM)
  • Reduced hardware requirements
    or
    Better performance (per same hardware)

If you read my Exchange 2007 Database – Part I & Part II you know that database performance is crucial for the user experience and server functionality. Exchange as an application server is built on top of the database, mainly Extensible Storage Engine (ESE) which it shares with Active Directory and as such, it uses big tables and constantly update them. Updating tables is a tedious job that read and mostly write to the disk (where the database is located) because the memory availability is limited compare with the size of the database.

Items that are used the most (like Inbox messages and rules, Calendar meetings and contacts information) will be re-read over and over creating a massive performance impact on the disk. Using 64-bit platform make more available RAM and as a result, less read actions. The immediate impact is faster access to the information – better user experience and less overhead on the server.

Checkpoint is another place where we notice the difference. Checkpoint is a way to hold writing of data to disk until we have the resources. If you remember, I mentioned this concept in Part I of the database review as I was explaining the transaction log role. Since the data is already written to the transaction logs we can safely wait with writing to the database and wait for a better time when the performance will not be affected. This is where checkpoint come to play:

  • Some of the data is updated frequently and if we hold on writing it to the database we save the re-write of its updates. Think of a calendar meeting that is sent internally. In most cases it will get approval\rejection\tentative updates within couple of minutes. If we write this data for every single update it will raise the I/O significantly while holding it save dozens of writes.
  • Nearby data changes that are written at the same time save I/O. If we wait and 2 Inbox items are updated and then written at the same time we save on access to the disk. Now multiple the close items (mail, calendar, etc.) and you get a significant improvement.

Checkpoint depth (20MG per Storage Group in Exchange 2007) determine how long we wait before writing the data, it is the size of the logs we keep in memory.

Tip: Writing to logs is sequential and with most disk it is handled much better than writing to the database. That is why writing to the logs though using the same theoretical I/O doesn’t cost as much as writing to the database.

Advertisements