How big is too big?
In Exchange 2003, theoretical limits for Store sizes are 72GB for Standard Edition and 8TB for Enterprise Edition. While the Standard limits are well within the means of most hardware, 8TB is a whopping amount of data for any server to handle, much less one running a resource-intensive application like Exchange Server.
In reality, the largest single store I’ve seen in the real world was around 800GB, and even that one was suffering from performance issues. Most of these revolved around attempts to do full-text indexing, however even when that was removed from the equation, performance to Outlook users was still something that was far below par.
Everyone’s servers are different, and therefore everyone’s environments will also be different, but there are some universal constants in the Exchange 2003 world that will impact how big a Store can grow. First off, there are the physical limits to how much RAM can exist on an x86 system. Even with the /3GB switch, Exchange will have a limited amount of physical memory to work with, after which, virtual memory paging will begin. As Exchange is notorious for performance grinding down when paging is overused, this is a condition you want to avoid at any time. Therefore, each Exchange server will be limited to how many Outlook connections, SMTP connections and other resources that require RAM that it can run at any given time.
Secondly, third-party solutions may have issues as databases grow larger. I’ve personally seen Blackberry Enterprise Server start to have issues with larger Stores around the 500GB mark. Since BES requires the ability to stay in communication with the Store, as performance degrades, there is a significant risk that you could have BES issues, including re-scanning of the databases. This process can take up to several hours on larger databases, which means that you do not have mobile email during that time.
There are many articles written about sizing Exchange Servers properly, such as those at www.msexchange.org and others, so I won’t go into a lot of detail here. It is important, however, to keep aware of the size of Exchange databases, and how ever-growing email Stores can dramatically impact your servers’ ability to serve.
In reality, the largest single store I’ve seen in the real world was around 800GB, and even that one was suffering from performance issues. Most of these revolved around attempts to do full-text indexing, however even when that was removed from the equation, performance to Outlook users was still something that was far below par.
Everyone’s servers are different, and therefore everyone’s environments will also be different, but there are some universal constants in the Exchange 2003 world that will impact how big a Store can grow. First off, there are the physical limits to how much RAM can exist on an x86 system. Even with the /3GB switch, Exchange will have a limited amount of physical memory to work with, after which, virtual memory paging will begin. As Exchange is notorious for performance grinding down when paging is overused, this is a condition you want to avoid at any time. Therefore, each Exchange server will be limited to how many Outlook connections, SMTP connections and other resources that require RAM that it can run at any given time.
Secondly, third-party solutions may have issues as databases grow larger. I’ve personally seen Blackberry Enterprise Server start to have issues with larger Stores around the 500GB mark. Since BES requires the ability to stay in communication with the Store, as performance degrades, there is a significant risk that you could have BES issues, including re-scanning of the databases. This process can take up to several hours on larger databases, which means that you do not have mobile email during that time.
There are many articles written about sizing Exchange Servers properly, such as those at www.msexchange.org and others, so I won’t go into a lot of detail here. It is important, however, to keep aware of the size of Exchange databases, and how ever-growing email Stores can dramatically impact your servers’ ability to serve.
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home