In May of 2015, Microsoft released a blog post titled "Troubleshooting High CPU utilization issues in Exchange 2013" in which Microsoft acknowledged (for the first time, to our knowledge) that CPU over-sizing is one of the chief causes of performance issues on Exchange Server 2013. We wish to highlight the fact that the Exchange 2013 Server Role Requirements Calculator is the main culprit in this state of affair. One thing we noticed with the release of Exchange Server 2013 and its accompanying "Calculator" is the increase in the compute resources it recommends when compared to similar configuration in prior versions of Exchange Server.
We at VMware have been drawing our customers' attention to this anomaly and have been educating them to not take the "Calculator's" recommendation as gospel. Unfortunately, not may customers like to buck Microsoft, especially in the face of strident claims of "This is our product and we are the experts". Sadly, customers who have moved to Exchange Server 2013, using the Calculator's recommendation (or the equally disruptive "Preferred Architecture" design from Microsoft) have been invariably hurt by the unsound recommendation.
Fortunately for everyone concerned, Microsoft appears to be moving in the right direction - if the recent blog post from the Exchange Server's Principal PM is an indication of things to come. in his "Ask the Perf Guy: How big is too BIG?" Jeff Mealiffe expounded on the revelation in the "Troubleshooting High CPU utilization issues in Exchange 2013" blog post, and provided a handy chart of recommended Exchange Server 2013 Server CPU and Memory sizing:
In a nutshell, we recommend not exceeding the following sizing characteristics for Exchange 2013 servers, whether single-role or multi-role (and you are running multi-role, right?).
Recommended Maximum CPU Core Count 24
Recommended Maximum Memory 96 GB
If you have upgraded your Exchange infrastructure to Exchange Server 2013, you will do yourself a lot of good if you find the opportunity to completely read the discussion presented in the links above.
A corresponding (and hopefully, less atrocious) "Calculator" has also been released to accompany this new recommendation -Exchange 2013 Server Role Requirements Calculator.
While we are glad that Microsoft has evolved in some ways and the Exchange team is now more open in discussing the inherent defects in Exchange Server 2013, we cannot but notice that Jeff' et al continued to propagate the "Combine Role" design recommendation, in spite of the fact that such design unnecessarily complicates performance troubleshooting and hinders fault domain isolation. We at VMware once wondered what necessitated Microsoft's change in design prescription around the time of Exchange Server 2013's release (Microsoft previously championed separated roles design, with the exception of the CAS/HT roles). Our (speculative) conclusion was that it was the ONLY reasonable design option that the Microsoft Exchange Server team could propose in order to continue to justify their "Exchange is Better on Physical" design proposition.
Given what Microsoft has revealed in the aforementioned blog posts, and given the new "maximum" guideline that Jeff posted in his write-up, the case for leaving Exchange Server on physical hardware becomes much more untenable - it will lead to the same resource wastage that we have all known to be the Achilles' heels of Microsoft's anti-virtualization stance. This is why Microsoft is recommending "commodity servers", ones that (hopefully) don't have more than 24 CPUs and 96GB of RAM. Well, if you are an enterprise standardizing on commodity hardware with such limited compute resources and you do not mind the associated server sprawl in the year 2015, the case for NOT virtualizing Exchange Server may make sense to you.
One of the major issues addressed in Jeff's and the previous blog posts is the way Exchange pre-allocates memory based on the number of CPU cores that it "sees". We suspect that this is the main reason why the Exchange Team is not virtualization-friendly. Perhaps on some hypervisors, the virtualized Exchange server "sees" ALL the CPUs that the parent sees, hence if the parent host sees 64 CPUs cores, Exchange Server will count all 64 cores as needing to be accounted for in memory allocation, even if the Exchange VM itself has only been allocated, say, 8 vCPUs. We speculate. But, this would be a logical rationale for Microsoft's insistence on multitudinous proliferation "itsy-bitsy-sized" silo'ed physical hardware for Exchange Server. For the avoidance of doubt, this is NOT a problem on the vSphere platform - the virtualized Exchange Server does NOT "see" more than the number of CPUs that is has been allocated, regardless of the size of the Esxi Host's physical hardware.
Let's repeat that - you do NOT need to resort to procuring tons of "commodity hardware" of less than 96GB memory and 24 CPUs in order to avoid the performance issues that Jeff and co have detailed in their posts. All you need to do is virtualize the Exchange Servers on vSphere and tell the VMs how much CPUs they are allowed to "see" and use. You get all the benefits of virtualization without unnecessarily triggering the Exchange Server's garbage collection anomaly.
from vmwarenews.de , Original Post Here
