Exchange eats RAM!
My exchange server consists of: Dell Poweredge 2950 Rack mount Server 2x Dualcore Xeon 2.0GHz 8GB Ram (recently upgraded from 4GB - and there is also a very large pagefile) 2x 73GB SAS 15k (RAID1) for OS 4x 146GB SAS 15k (RAID 10) for Exchange Data Windows Server 2003 x64 Standard w/SP2 and all available hotfixes. Exchange Server 2007 running all roles. Symantec BackupExec System Recovery Server 7.0 for backup. The problem i have with exchange eating all the RAM is that my backup software (Symantec BUEXEC SRS7) cannot obtain the required RAM to complete a full successful backup. From a fresh boot, the server will backup fine for approx 4 days, or until the Store.exe reaches a memory usage of about 6GB. At this point the only way to achieve a good backup is to reboot the server to free up the memory. Surely a reg key or any other means to restrict memory usage by store.exe would be beneficial to someone like me? After all Symantec will not help me with this problem as they say its an exchange issue. The other problem is that the console is very very slugish and the simplest tasks can take an age to complete. Any one else having similar issues?
August 1st, 2007 11:09am

Exhange is suppose to cache as much as it can in RAM(eat RAM as you say) and its store.exe (Exchange Information Store) doing it. This is normal behavior. Exchange uses RAM insteed of disc since RAM is faster than disc. but its not normal that you cannot start any other application, store is designed to release memory to other apps when they need it. You probably dont need to reboot your server, you can try to restart "Information Store" Tell me more about your system, number of users, etc.
Free Windows Admin Tool Kit Click here and download it now
August 1st, 2007 11:20am

Lasse is right, there is no way to keep the store from consuming as much RAM as possible for caching. I have a lab server with 2.5GB of RAM and NO active mailboxes. After about 24 hours, store.exe is consuming almost 2GB of that RAM. This is something that Microsoft should hear, though. I think this should be an option (to restrict the available RAM that is used by STORE.EXE).
August 1st, 2007 9:53pm

I agree that the principal of using RAM instead of Disc is better for performance. The fact that it just will not release the RAM when BUEXEC SRS wants it bugs me. The server has 176 mailboxes, the largest of which is approx 3GB. I have separated these mailboxes into separate storage groups and separate databases. One thing i have just thought about is that BUEXEC SRS is runningas a32-bit application (despite Symantec saying it supports 64-bit?). Is it that it "asks" Exchange for some RAM, exchange frees up a little, but BUEXEC SRS cannot address it? At the end of the day, rebooting isnt a problem, however i will restart the information store next time the backup fails. The annoying thing is BUEXEC SRS does not flag up that it has missed backups - only after you have rebooted, it relys on me checking to see if it has emailed me saying it has completed successfully.
Free Windows Admin Tool Kit Click here and download it now
August 2nd, 2007 11:29am

Support for running on 64 bit OS and being 64 bit application is different things. If Symantec has a 64 bit version I would use that insted isnt there any error in eventlog? is backup using VSS technology?
August 2nd, 2007 3:34pm

There may be a way around this after all. Check out this KB: http://support.microsoft.com/kb/815372 The ability to set the maximum amount of cache memory apparently applies to E2K7. I have NOT tested this yet, so use with care. Also, keep in mind that if you reduce the amount of RAM that Exchange uses, it could hurt performance and the IOPS profile could be affected.
Free Windows Admin Tool Kit Click here and download it now
August 2nd, 2007 11:11pm

I did some testing on this and had good results restricting the amount of RAM that store.exe uses. I wrote a blog article on it. http://mostlyexchange.blogspot.com/2007/08/restricting-ram-usage-in-exchange-2007.html
August 5th, 2007 3:13am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics