asked on
Exchange 2010 limit RAM Usage
Dear experts,
I know this question has been asked a few times before. However, I'd like clarification before I go ahead and make changes. I have an exchange 2010 SP3 with approx 40 users. This is running on a Server 2008 R2 with 20GB of RAM. The issue is the usual one of store.exe taking up all of the available RAM and then the machine becomes very slow.
Have been looking at the guide below;
https://social.technet.microsoft.com/forums/exchange/en-US/00851cd4-bc74-4d94-95b7-8982c5a93380/limit-memory-usage-on-exchange-store
I would like to limit the store usage - however, I'm not sure how to work out what the upper limit of the store RAM usage should be - hence the question - how is it determined what the store upper limit should be so that I achieve a balance between limiting store.exe and also gaining acceptable exchange performance. I'd rather have a guide or other calculation rather than simply guess what the upper limits should be.
Thanks in advance.
I know this question has been asked a few times before. However, I'd like clarification before I go ahead and make changes. I have an exchange 2010 SP3 with approx 40 users. This is running on a Server 2008 R2 with 20GB of RAM. The issue is the usual one of store.exe taking up all of the available RAM and then the machine becomes very slow.
Have been looking at the guide below;
https://social.technet.microsoft.com/forums/exchange/en-US/00851cd4-bc74-4d94-95b7-8982c5a93380/limit-memory-usage-on-exchange-store
I would like to limit the store usage - however, I'm not sure how to work out what the upper limit of the store RAM usage should be - hence the question - how is it determined what the store upper limit should be so that I achieve a balance between limiting store.exe and also gaining acceptable exchange performance. I'd rather have a guide or other calculation rather than simply guess what the upper limits should be.
Thanks in advance.
Microsoft Server OSEmail ServersExchange
Last Comment
rindi
Exchange is usually pretty good about giving RAM back when other processes use it. It will take up close to 90%, but when another application requests memory use, it will release the memory for those applications without issue. As far as how much RAM to have, the minimum supported memory for Exchange servers with all roles installed is 8GB.
If your Exchange Server is a VM and you're looking to optimize the amount of RAM given to the OS, with your existing user base, you could probably get away with the Minimum supported memory levels without a significant loss of performance. I have 8GB assigned to my VM test environment and it moves along pretty smoothly. 40 mailboxes will not cause much performance decrease.
If your Exchange Server is a physical server with 20GB of RAM, just leave it as is and don't worry about configuring memory utilization. Exchange is designed to handle memory a specific way, and messing with the default configuration is really more effort than it's worth.
If your Exchange Server is a VM and you're looking to optimize the amount of RAM given to the OS, with your existing user base, you could probably get away with the Minimum supported memory levels without a significant loss of performance. I have 8GB assigned to my VM test environment and it moves along pretty smoothly. 40 mailboxes will not cause much performance decrease.
If your Exchange Server is a physical server with 20GB of RAM, just leave it as is and don't worry about configuring memory utilization. Exchange is designed to handle memory a specific way, and messing with the default configuration is really more effort than it's worth.
I agree with the above, there is no need to change the RAM usage. Exchange works best when you allow it to use what there is.
What do you mean 'the server becomes slow'?
Does it become slow when you log into an interactive desktop on the server and the GUI is sluggish or it is slow in that it is not delivering emails quickly or responding to OWA/Outlook search queries fast enough?
If it is the former - it is behaving as designed. Type in 'systempropertiesadvanced'
If your emails are being delivered slowly or searches are answered slowly/failing, then you need to add more memory (or other resources), not place artificial caps on them.
My recommendation: You're running Exchange 2010 - Install the Exchange management tools on a separate computer. It can even be a Windows Desktop system. Don't admin servers from a server.
Does it become slow when you log into an interactive desktop on the server and the GUI is sluggish or it is slow in that it is not delivering emails quickly or responding to OWA/Outlook search queries fast enough?
If it is the former - it is behaving as designed. Type in 'systempropertiesadvanced'
If your emails are being delivered slowly or searches are answered slowly/failing, then you need to add more memory (or other resources), not place artificial caps on them.
My recommendation: You're running Exchange 2010 - Install the Exchange management tools on a separate computer. It can even be a Windows Desktop system. Don't admin servers from a server.
ASKER
The issue which prompted this question was that it took a couple of minutes to open Symantec Management Homepage to look at an alert which had been raised. At the weekend have restarted the system and whilst the RAM usage has gone back to 99% - the server itself is fairly responsive to the GUI.
In addition we get constant warnings about the RAM usage at 99% from our monitoring system.
I understand that the RAM should release when required - however, this is permanently at 99% - should we simply just turn off the warnings - and accept this as the way it is?
In addition we get constant warnings about the RAM usage at 99% from our monitoring system.
I understand that the RAM should release when required - however, this is permanently at 99% - should we simply just turn off the warnings - and accept this as the way it is?
Howdy,
As ScottCha said, you should really size the environment again. Yes, Store.exe (ESE store driver) will consume as much RAM as possible but at the same time you should not see a performance degradation if you are properly sized. Depending on the size of the mailboxes, and even the number of items within these mailboxes you will see performance issues on the system that are NOT memory related.
As someone else also stated above the ESE store driver has a process within it internally called store trimming, which will delivery memory back that is is holding if available. In your case it sounds like that is not the case.
I would check your AV exceptions, and resize. Make sure you have enough RAM and Disk IO allocated to the system.
Also changing the values of msExchESEparamCache* (meaning anything) is technically not supported by Microsoft. Keep that in mind before playing with these settings..
As ScottCha said, you should really size the environment again. Yes, Store.exe (ESE store driver) will consume as much RAM as possible but at the same time you should not see a performance degradation if you are properly sized. Depending on the size of the mailboxes, and even the number of items within these mailboxes you will see performance issues on the system that are NOT memory related.
As someone else also stated above the ESE store driver has a process within it internally called store trimming, which will delivery memory back that is is holding if available. In your case it sounds like that is not the case.
I would check your AV exceptions, and resize. Make sure you have enough RAM and Disk IO allocated to the system.
Also changing the values of msExchESEparamCache* (meaning anything) is technically not supported by Microsoft. Keep that in mind before playing with these settings..
ASKER
Thanks for the information.
Can you give me some more information with regards to making sure that Exchange is properly sized both in terms of RAM and also disk IO.
Generally most of our systems are around the 20GB - 32GB mark with between three or four SAS 10K or 15K disks of varying sizes generally in a RAID 5.
Appreciate this is expanding the original question, but how does one move forward from having 'enough' RAM and then also ensuring that the disk IO is sufficient - it would be good to be able to measure these in a meaningful way to be able to determine if the exchange performance is o.k. or whether it is impacted by either of the above.
At the moment the only measure of performance we have is monitoring alerts of high RAM usage and perceived slowness of the GUI with regards to operation of administration operations.
Are there tools which will measure the performance of exchange specifically?
Can you give me some more information with regards to making sure that Exchange is properly sized both in terms of RAM and also disk IO.
Generally most of our systems are around the 20GB - 32GB mark with between three or four SAS 10K or 15K disks of varying sizes generally in a RAID 5.
Appreciate this is expanding the original question, but how does one move forward from having 'enough' RAM and then also ensuring that the disk IO is sufficient - it would be good to be able to measure these in a meaningful way to be able to determine if the exchange performance is o.k. or whether it is impacted by either of the above.
At the moment the only measure of performance we have is monitoring alerts of high RAM usage and perceived slowness of the GUI with regards to operation of administration operations.
Are there tools which will measure the performance of exchange specifically?
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
High RAM usage is normal. As for slow GUI, are you using Chrome? I've noticed that Chrome has some major performance issues running OWA and EAC/ECP
ASKER
Hi Adam, thanks for the responses this system is an inherited one so the planning is really down to the original provider.
It is a domain controller and really runs everything for this client. Pretty much like any other small business - server really as most can't afford to have dedicated servers for each 'application' as it were.
So there is always a trade off between the affordability, the 'ideal' and the practicability.
The slowness of the GUI was really the slowness of the server responding to pretty much anything - in the specific case opening the Symantec Management Homepage with Internet Explorer, although I'm sure everything was affected.
We are planning a replacement for this server in any case and so the information provided will be useful in making sure that the replacement server doesn't have as many issues as the original. However, I'm sure there will have to be a trade off between the costs and the ideal scenario as the budget dictates.
It is a domain controller and really runs everything for this client. Pretty much like any other small business - server really as most can't afford to have dedicated servers for each 'application' as it were.
So there is always a trade off between the affordability, the 'ideal' and the practicability.
The slowness of the GUI was really the slowness of the server responding to pretty much anything - in the specific case opening the Symantec Management Homepage with Internet Explorer, although I'm sure everything was affected.
We are planning a replacement for this server in any case and so the information provided will be useful in making sure that the replacement server doesn't have as many issues as the original. However, I'm sure there will have to be a trade off between the costs and the ideal scenario as the budget dictates.
Just my .02 cents..
I would try and virtualize the environment on a small box, nothing insane you could even use direct attached storage if you liked (e.g: buying something like a Dell 730xd and then using the internal drive space.. which in that server case is 24x 2.5" HDD). Then migrate over Exchange and AD into two separate virtual machines. Exchange really shouldn't be on a domain controller.. but in the case of SBS I cant really say much since I completely understand your position.
I would try and virtualize the environment on a small box, nothing insane you could even use direct attached storage if you liked (e.g: buying something like a Dell 730xd and then using the internal drive space.. which in that server case is 24x 2.5" HDD). Then migrate over Exchange and AD into two separate virtual machines. Exchange really shouldn't be on a domain controller.. but in the case of SBS I cant really say much since I completely understand your position.
ASKER
Thanks Experts for all the comments it is certainly food for thought.
I'm reading different opinions on the replacement strategy;
1) Server with two hyper-v, as suggested one for DC and file sharing, and the other for exchange.
Seems to be mixed opinion and that this is a nightmare scenario if the host fails (but then this is the same as existing server now in any case) and may be difficult to recover?
2) Two physical servers, one for DC and file, and the other for exchange.
This seems to be the best approach, but may not be in terms of cost.
What are the thoughts - virtual or physical?
I'm reading different opinions on the replacement strategy;
1) Server with two hyper-v, as suggested one for DC and file sharing, and the other for exchange.
Seems to be mixed opinion and that this is a nightmare scenario if the host fails (but then this is the same as existing server now in any case) and may be difficult to recover?
2) Two physical servers, one for DC and file, and the other for exchange.
This seems to be the best approach, but may not be in terms of cost.
What are the thoughts - virtual or physical?
Version 1 is no problem at all. Install Hyper-V, and then virtualize 2 VM's, one for a DC and the other for the exchange to run under that. If you backup properly, it is very easy to restore to a new Hyper-V host, as the underlying hardware isn't important to the VM's. Theoretically it is no problem at all just moving the VM's to a new host, it is much easier than moving non VM OS's to new hardware. So recovery is actually a lot easier than if you slap your DC and the exchange server directly onto physical servers and later have to replace them because of hardware failure. So generally I would even virtualize server OS's even if it will be the only VM running on that server, as it makes recovery much easier. The only reason not to virtualize is when you are running something within your OS that needs absolute top performance, as you always loose something to your hypervisor.
v20.9 of the Exchange 2010 Server Role Requirements Calculator
https://gallery.technet.microsoft.com/office/Exchange-2010-Mailbox-Server-Role-
This is a very useful tool in calculating servers for Exchange.
Here's the one for Exchange 2013
https://gallery.technet.microsoft.com/office/Exchange-2013-Server-Role-f8a61780