SBS 2011 Store.exe allocating too much memory despite cache adjustment


  • I have a client who is using the trial version (on a new HP ML350 G6 with 12GB RAM allocated to the VM) for their office of six.  They like the product, except it will get very slow for several minutes a few times per day.  When store.exe has a reasonable amount of memory allocated (usually for a while after a restart) the problem does not happen.  Right now, it has almost 5GB allocated.

    I have read several articles online regarding adjustment of the msExchESEParamCacheSizeMax.  There are conflicting numbers out there about the actual size of the cache blocks, so I am not actually sure I am limiting yet having it set to 50,000.  I have reduced this number by about half each time, having done this maybe four times now (I think I started at 500,000 when I errantly thought the blocks were 4KB each - I am still not sure what they are [have seen both 8KB and 32KB mentioned in support docs])

    The server does have Trend Micro Worry-Free Business Standard on it, using their latest version whose patch level (1435) is supposed to be SBS 2011 compatible.  I can pretty well guess they might be part of the issue, but I still should be able to limit the cache independently.

    Please advise.  Thanks, Tom.

    Monday, June 20, 2011 3:37 PM


All replies

  • Hi Tom,

    maybe these articles do help you:

    and this one


    Regards Ronny
    Visit my Blog or follow me on Twitter
    Monday, June 20, 2011 7:12 PM
  • Sorry for the late reply - it seems that the option to email when a reply is posted does not work well for me - this is the second time an SBS post did not alert me (but an issue with a CA in another forum works fine).

    I figured something else needed to be set.  I have set the minimum cache size and restarted the server.  It will take a few hours for things to reach equilibrium.

    Thanks, Tom.

    Monday, June 27, 2011 1:31 PM
  • Tom B_1, I'd appreciate knowing how this turned out.  I logged onto a client's SBS2011 server the other day and was shocked to see physical memory usage at 93%; store.exe just shy of 8GB (server has 16GB RAM).  Coincidentally, I had logged on to install Trend WFBSA7.  I *think* it was before I ever installed Trend that I noticed the high memory usage.  I'm just at the start of my Googling....
    Wednesday, September 07, 2011 7:04 PM
  • store.exe is _designed_ to use available memory and does not normally cause the slowdown encountered by the OP.

    Leave it alone.

    Wednesday, September 07, 2011 10:45 PM
  • SuperG, I like your answer (and thank you)...but 93% of physical RAM (well, store itself is using 50%)?  I've been working with Exchange since 5.5 and never seen this.  In fact, on another client's well-running SBS2008 box, with 12GB RAM (76% used) and a far larger Exchange database, store.exe is stable at 676MB.  On yet another client's SBS2003 box--admittedly, 32-bit--just about the same, ~640MB.  Are you saying it's an Exchange 2010 thing?
    Thursday, September 08, 2011 12:26 AM
  • I don't know the detail but remember someone mentioning that Exch2010 has been further optimised to keep more in RAM, in order to reduce HDD IO.

    If I'd specced a server to have X RAM and it _wasn't_ using (at least most of) it, I'd be worried that I had over-specced the machine.

    BTW: I have a bit of a theory about systems which have poor performance perceived to be related to store.exe's memory use. What 3rd party applications are on such box? Are such 3rd party applications respecting the Windows Memory Manager processes used by such products as Exch and SQL to dynamically use available memory _and hand it back as necessary_?
    • Edited by SuperGumby Thursday, September 08, 2011 12:45 AM
    • Proposed as answer by SuperGumby Saturday, September 10, 2011 12:50 AM
    Thursday, September 08, 2011 12:32 AM
  • Thanks for your follow-up thoughts.  To be sure, as the single most-used data on the server, I'm happy enough to see a whole bunch of Exchange in RAM.  I'll just keep an eye on things.  In fact, there _hasn't_ been any performance issue.  It just gave me a scare ;-0
    Saturday, September 10, 2011 12:48 AM
  • Sorry that I disappeared for a little bit - despite having successfully limited exchange memory to around 4GB, it took expanding the server's total memory from 12GB to 18GB in order to have consistent free memory of a GB or two. 

    My main issue is not that Exchange wants to cache memory, in and of itself, but so do other processes.  Ultimately, I do not doubt that they are all designed to release memory when none is "available".  However, either they do not care about free memory (which I need some of for the server to run well [from observation]) or they cannot throttle themselves back dynamically fast enough in an SBS 2011 server.

    This is an office of six users running SBS 2011 on a Xeon 5504/SAS 15k mirror with 18GB of RAM.  I also have a 50 seat office running SBS 2003 on a Xeon 5520/SAS 15k mirror with 4GB of RAM and never a problem.  Both running Trend Worry Free on the server.  I know SBS 2011 has more going on, but the associated excess baggage (requiring much more hardware - especially memory) is getting ridiculous. 

    If this were just an Exchange box, I'd be less concerned.  I just think the SBS team is throwing in these newer components and not adjusting the whole mix for the presence of the parts together.


    Wednesday, December 07, 2011 2:19 PM
  • store.exe is _designed_ to use available memory and does not normally cause the slowdown encountered by the OP.

    Leave it alone.

    I keep hearing this, but my experience is contrary to this "conventional wisdom".  I rebuilt an SBS 2011 server here recently and was puzzled why it ran great for the first business day, but the next day it would be significantly slower.  And we aren't talking a small box - it has 24GB of RAM!  I forgot that I had made the adjustments referenced earlier in this thread and was reminded of it when I started running performance monitor and watched in annoyance as Store.exe consumed the lions share of memory, causing other processes to have to page in and out.  With 24GB of RAM I should hardly ever have to touch the swap file!


    I really wish the SBS team would re-evaluate this.  The settings might make sense when Exchange is the only major resource on a server in a traditional environment, but SBS is different - there's a bit more going on under the hood than the normal Exchange best practices.  After restricting store.exe, I've never had Exchange performance be an issue - even when limiting the memory useage for store.exe.  But if I don't limit store.exe manually, it makes a huge and noticably negative impact on performance of everything else!


    Rather than dismiss my comment - if someone from MS want's details, I will be more than happy to send them screen casts demonstrating the performance issues, logs or whatever else.  It's not just me, I'm (and the other posters with similar comments) not crazy and it happens to every new server I set up.  I just don't do it that often :)  I'm not just complaining, I'm more than willing to report my experience and/or troubleshoot.


    For those of you who aren't experiencing this - congratulations!  It's no fun for those of us who are, though :(

    • Edited by E Eskam Sunday, December 11, 2011 6:26 PM
    Sunday, December 11, 2011 4:35 PM
  • I don't know the detail but remember someone mentioning that Exch2010 has been further optimised to keep more in RAM, in order to reduce HDD IO.

    And when Exchange is the only application on a server, that makes perfect sense.


    >>If I'd specced a server to have X RAM and it _wasn't_ using (at least most of) it, I'd be worried that I had over-specced the machine.


    Again, SBS does more than just Exchange.  And "unused" RAM in Windows Server isn't unused - it is used for handy things like, I don't know - caching files for file shareing?  :)

    >>BTW: I have a bit of a theory about systems which have poor performance perceived to be related to store.exe's memory use. What 3rd party applications are on such box? Are such 3rd party applications respecting the Windows Memory Manager processes used by such products as Exch and SQL to dynamically use available memory _and hand it back as necessary_?


    Even if they are, store consumes all free memory on my box.  There is none left over for file system caching or other processes.  An new activity causes excessive paging to the swap file.  It's rediculous.  Once I limit store, that all stops.  Heck, unlike SBS 2003 I don't even have to tweak SQL server - it's all Exchange.

    • Edited by E Eskam Sunday, December 11, 2011 4:40 PM
    Sunday, December 11, 2011 4:40 PM
  • This is an office of six users running SBS 2011 on a Xeon 5504/SAS 15k mirror with 18GB of RAM. 


    I've got 24GB, two quad core Xeon's and three mirror sets; two are SAS 15K 300GB based mirrors (with a very nice battery backed up caching controller) and the third is a SATA 1TB mirror set (with another nice battery backed up caching controller).  The first SAS mirror pair has the OS and apps.  The second SAS mirror pair has the Exchange database.  The SATA mirror pair has all the user folders and file shares.  I had a fifth 15K 300GB SAS drive and I had the swap file on that drive.  After a couple days of the store.exe sucking all the RAM up, that drive was constantly being pounded - the other drives had just occasional access - so I could plainly see the excessive swap file activity in hardware and not just in resource monitor or performance monitor.  Unfortunately one of my other SAS drives died and I had to use that drive to repair the failing mirror set.  That meant putting the swap file back on the system disk.  The Exchange disk is practically idle (only 12 active users) but the system drive is practically smoking due to constant activity so I'm thinking of putting the swap file or SQL server database with Exchange database.

    Not all enviroments work with the same assumptions... 


    I've tweaked the cache size via the procedures ronnypot linked to (Thanks Ronny!).  If history is an indicator, my issues will magically go away with a reboot... and then stay gone :)


    And yes, I have Trend Worry Free Business Security, Crashplan Pro and a few otherthings also on the box - but I think my box should be able to handle it easily.  Heck, I should be able to virtualize a couple of SBS servers on it!  Indeed, I'm going to be adding an instance of Microsoft Multipoint Server to it in the near future (As an FYI, Multipoint Premium is also a great way to get a full Windows Server OS for a HyperV host - especially for education or non-profit/charity licensing!).

    Sunday, December 11, 2011 6:44 PM
  • In article <f84f30b8-deab-45ac-aa76-f44910a12e17>, E Eskam says...

    I keep hearing this, but my experience is contrary to this "conventional  wisdom".  I rebuilt an SBS 2011 server here recently and was puzzled why  it ran great for the first business day, but the next day it would be signi ficantly slower.  And we aren't talking a small box - it has 24GB of RAM!

    I did a new install of SBS 2011 standard, with 20 users, and despite allocating 24GB of ram to SBS, it's only using 10.5GB after more than a week in operation.

    Could it be that you're doing something more than just what comes with SBS?

    You can't trust your best friends, your five senses, only the little voice inside you that most civilians don't even hear -- Listen to that.  Trust yourself. (remove 999 for proper email address)

    Sunday, December 11, 2011 10:24 PM
  • It's not an issue if store.exe is taking up memory,on the contrary its a good thing as it reduce's disk I/O.

    Check out following technet article which talks about database cache in ex 2010


    Next check out following blog post from exchange team on memory utilization in exchange 2007,I believe it holds good in exchange 2010 as well as the architecture is 64bit and the underlining logic they gives holds good here as well:


    "Now, one of the results of being able to address more memory is the capability to cache more memory for each application. To allow this to happen for Exchange, the ESE Database Cache Size limit was removed to allow Exchange the ability cache more pages in memory. Accessing pages in memory is extremely fast, so the more data we cache in memory, the less we actually have to read andwrite from the disk. When following our best practice guidance around storage group deployment and memory sizing, Exchange 2007 reduces the amount of I/O required overall. This gave us rather huge performance gains.  

    With no limitation in Database Cache for Exchange 2007, the memory usage for the store process will naturally be much higher compared to what Exchange 2003 used due to the many benefits discussed earlier. Memory allocation for the ESE cache is dynamic, so Jet will use all available memory on a system and return it as needed.  For example, if a server had, let's say, 16GB of physical RAM installed, the database cache could consume approximately 14GB of memory, roughly 2GB less than the total amount of physical RAM in the server, leaving enough memory for the system cache or other applications running on the server."


    Lastly do go through:



    • Edited by Jkazama Sunday, December 11, 2011 10:56 PM
    Sunday, December 11, 2011 10:53 PM
  • If you ask me it is a sick concept. I have exactly the same issue: given power edge2900 is not latest and greatest, but with max memory of 32 GB it should be almost running out of that memory. Instead it utilizes 20 GB just for running store and starves all the other processes from using memory. It would be a great concept, but IT DOES NOT WORK here and sounds like many more have the same issue! I DO NOT see any performance improvements and in matter of fact, my users are certain that old SBS 2003 was performing better by far utilizing fewer resources. So where exactly is the improvement in performance?

    Please let me know how I can limit the amount of memory eaten by Exchange.

    Thank You!


    Tuesday, December 20, 2011 4:52 PM
  • I did a new install of SBS 2011 standard, with 20 users, and despite allocating 24GB of ram to SBS, it's only using 10.5GB after more than a week in operation.

    Could it be that you're doing something more than just what comes with SBS?

    The only other thing loaded on the server is Trend Micro WFBS.  And I didn't put it on for the first two weeks.  I had a "bone stock" SBS install and it immediately used all the memory - I have mine set for 24GB as you.  I even allocated 30GB (The physical box has 32 GB, but I didn't want to starve out the host HyperV OS) and within a couple of days there was no free RAM.  How long has yours been up?  It doesn't happen overnight - it takes three to four days to suck up all the memory...
    Monday, January 09, 2012 2:33 AM
  • It's not an issue if store.exe is taking up memory,on the contrary its a good thing as it reduce's disk I/O.

    Check out following technet article which talks about database cache in ex 2010

    Ya know, all of that is perfectly relevant in an environment that has hundreds of mailboxes on dedicated servers.


    Funny, I thought I was in the Small Business Server (SBS) forum.  I have 14 users and process less than a thousand emails a day.  How much disk IO could we be possibly talking about here for Exchange vs. the rest of the system?  You want to talk about disk IO?  I'll show you swap activity from a loaded down SBS server that has four major applications on it, two of which that aren't properly tuned and sucking up all the resources on the machine causing excessive swapping.


    The rest of the server is rubbish but Exchange is able to service requests with reduced disk IO! Wow!  That's really important for those Outlook clients that are running in cached mode!  Yup!


    I understand the theory, but I can tell you from simply monitoring memory and swap activity with Performance Monitor that Exchange and SQL are set WAY inefficient for SBS.  The amount of memory they consume is ridiculous.  My server spends more time serving files than anything else, but no one seems to care that by sucking up ALL the available memory none is left over for file caching.  That isn't important for a dedicated Exchange server, but it is VERY relevant for SBS!


    I don't care if my WSUS console runs an extra minute longer because SQL server has to do some more disk IO, or that a client machine might have to wait on IIS to deliver the update catalog or an update a little slower.  My users aren't directly interacting with those tasks.  I do care that frequently I can watch them click on a file and it can take several seconds for a response!  I would have expected more tuning for the unique circumstances of SBS.  When I can pull a few settings out of a forum, apply them and reboot and my server more than doubles in responsiveness there's a problem!

    It's called knowing your target audience and tuning for the end user experience, not going gagga over the technology for the technologies sake.  I agree that all that fancy caching stuff is great for Exchange 2010 - when you have hundreds if not thousands of users on a box - but not for SBS!  It's the proverbial swatting a fly with an elephant when a rolled up magazine will work just as well (if not better - greatly reduced collateral damage!)


    And let's just take the whole hardware issue off the table.  My server is no slouch - it's a larger HP (5U) with dual quad cores with hyper threading, 32 GB of RAM (24 of which is allocated to SBS through HyperV) and three 300GB SATA mirror sets with the OS, Email and everything else spread out across them to divide up the disk IO.  Don't go trying to blame my hardware!  My machine is IO bound due to the swap file because Exchange and SQL, out of the box, are absolutely ridiculous in the amount of RAM they grab starving the rest of the stuff on SBS.


    Mind you, I'm not bashing SBS per se.  I really like SBS.  It's perfect for the organizations I support that use it.  And thankfully I know enough to diagnose issues such as ridiculous memory caching, search and find threads with real world solutions and apply them.  And the product is that much more useful because of it.  But for every one of me, there are probably hundreds out there without the support or skills to do the same - throwing ridiculous amounts of money at resources like memory (which thankfully is dirt cheap - relatively speaking) and still getting lackluster performance.


    Instead of "blaming the user", how about paying attention to the real world feedback and adjusting the product to be more balanced?  Again, we aren't talking about boxes dedicated to Exchange or SQL.  Nor is SBS broken and needs to be scrapped - some simple (and I mean simple!) tweaking makes it far more useable.  Not sure why so few seem to be able to grasp that this is an issue, and why their are so many defenders who act like the emperor has clothes on after all...

    Monday, January 09, 2012 2:43 AM
  • I dun wana get into an arrgument over whos right on the whole memory utilization debate ,however I will say that I have seen many sbs 2011/sbs 2008 servers where exchange and sql spike up and there is no delay in file copy or whatever.....I have seen many issues with slow rate of copy which are totally unrelated to memory utilization on the server and the logical way to troubleshoot is to get a network trace.


    Sure if there is a spike it is a possibility that it is causing an issue ,but, to be sure of it you need a memory dump and debug that to say something conclusively,other option could be to add conuters for msexchange* in perfmon and then examin them against network and memory counters at the time of issue.

    Here is the technet article that talks about disk caching which talks about memory being cached:

    And nobody is forcing to believe the explanation,Ronny  had pasted the link on how to limit the memory,I will paste it again:


    For SQl:

    [Make sure you connect to right instance according to SBS 2011]

    And the dedicated servers where we have hundred's of mailbox's aren't running a copy of AD[they are not DC],DHCP,Sharepoint etc....

    Rest I think its up to the administrator to make his own decision [both options are available],my only intention was to get the reasoning behind the change to light.....if you would rather limit it.....then....

    • Edited by Jkazama Monday, January 09, 2012 3:05 AM
    Monday, January 09, 2012 3:03 AM
  • Everyone is quoting the ADSI Edit fix, but when I start ADSI Edit, I don't have Configuration, I have default naming context and no matter how far I drill down, I cannot find anything resembling that string.  My server is not running any third party apps and it is half the speed of the one we replaced.  It is dual Quad Core with 18 GB of RAM and Store.exe takes 14 GB.  When I reset IS it runs significantly faster for a day or so then slows again.  How does one get to the limiting parameters with the "new?" interface?
    Monday, February 20, 2012 6:08 PM
  • in ADSIEDIT you need to 'connect to' the 'configuration' container, it is not open by default.

    rt-clk 'ADSIEDIT' at top left of the msc, 'connect to', name it Configuration, put the 'connection' on 'select or type a DN or NC', type in 'CN=Configuration,DC=AD_name(single level),DC=AD_DNS_Suffix', select your SBS in the 'Computer' area, or maybe leave it at 'default' (I prefer to specify).

    Monday, February 20, 2012 7:36 PM
  • Has anyone seen where they make the database cache limit and after restrarting the information store the limit is not abided?  I ask because I've run into that situation.  I've set the lmit to 131072 (4gb) in both min and max.  (Only 10 users on an SBS2011 box, with 16 gig) however the task manager after restarting the Information Store is growing up to 4.356 gig and growing.  I'll give it a little time but, I would have figured it would stop at 4.2 gig (rounding up). 
    Friday, April 27, 2012 6:13 PM
  • Exact same situation here. restored to new better hardware, 32GB RAM, etc.   all complaints above apply.  changed maxparamcache.  didn't affect the amount of memory store.exe takes.  everybody give up assuming MS will eventually fix the performance problems? 
    Thursday, October 11, 2012 11:02 AM
  • Along with msExchESEParamCacheSizeMax you also have to apply changes for msExchESEParamCacheSizeMin  as per
    • Proposed as answer by abubek Thursday, November 01, 2012 9:21 PM
    Thursday, October 11, 2012 12:06 PM
  • jkazama,

    On SBS2011 memory does not "spike up", it creeps up until store.exe. w3p3.exe and sql use 100% of it.

    To be blunt, you are talking straight out of your rear orifice, as is anybody else here quoting MSDN or another other MS source on the dynamic allocation of memory on an SBS2011 box. MS has made the mistake of leaving SBS, IIS and SQL tuned for hundreds (thousands) of users. In a small business environment (the TARGET demogaphic of SBS2011) the tuning has created a severe performance hit. There is no magic way for data to be instantly paged from RAM to DISK to allow another process to use the RAM. PERIOD. To argue or infer any differently makes you fully ignorant of basic computing architecture and/or how the different components of a computer work together to manipulate information.

    In most installations, the SBS box acts as an application server, file server and remote access server. These operations are ground to a near halt due to the lack of available RAM for caching operations. Again to argue any differently is to demonstrate utter ingorance with regard to system architecture.

    Thursday, October 11, 2012 7:31 PM
  • Someone doesn't understand the operation of paging or dynamic memory allocation.

    Ever had a BSOD? Were you set for full memory dump? Know why full dump requires a paging file of RAM+(i think its)12MB. Because the paging file is wriitten _all the time_ to reflect RAM. This is a hangover from VMS, on which Windows VMM (virtual memory management) is based. The only time this is not so is if the sysop reduces the paging file to be less than RAM (such as fools who think the system will work faster because they have enough RAM to not need a PF). Of course, memory operations are faster than HDD, so the PF is updated 'ASAP'.

    As exchange operates it keeps as much data as it can in RAM but oportunistically writes whatever it can to the database. Also the database transaction logs (because Exchange isn't a mail system, it's an RDBMS) are written as a high priority task. Though Exchange has the content in RAM it can release _most_ of that RAM almost immediately, when requested to do so, because it is already modified on HDD. The effect of this 'almost immediate release' cause inefficiency in Exchange only if an area of the database which has been released needs to again be accessed, and therefore reloaded from HDD.

    What the majority of naysayers contributing to this thread seem to be missing is that _the great majority_ of SBS systems _do not require_ these modifications. Exchange, IIS, SQL etc... co-operate on _the great majority_ of SBS systems, at default values.

    There's also a common practice of limiting the amount of RAM used by the SQL/SQL-like instances. Though I've rarely encountered circumstances where such is necessary (ie. that SQL use has actually caused a problem) I do commonly limit SQL RAM use, mainly so that Exchange doesn't need to fight SQL to find the 'balance'.

    • Proposed as answer by zitatech Friday, October 19, 2012 9:55 AM
    Thursday, October 11, 2012 9:43 PM
  • Wow, takes a while to read though the whole post and attachements.

    So - I have an SBS 2011 server using 98%-99% of memory and the only process that seems to be complaining is Symantec. Every day I get messages saying my server health is poor

    Reason: Memory on your Symantec Endpoint Protection Manager server is running low.

    It doesn't seem to affect any of my 27 users unduly, occassionally I get a slow response time on the server itself when logged in remotely from the PC 2 feet away. Can I just change the threshold at which I get the messages and assume everything works fine?


    Friday, October 19, 2012 10:00 AM
  • Hi!

    I am searching hi and lo for clues on a memory problem with SBS 2011 Essentials. Here, there is no Exchange, hence that argument is not valid.

    However, our server with 8GB of RAM keeps slowly showing more and more memory used. In the course of about 10 days this hits maximum and server crashes.

    Now, examining the memory with process explorer doesn't make sense - it doesn't add up to what task manages claims is being used.

    Using RAMMap we can see the Page Table continually growing until it uses up the page file completely.

    Using poolmon we can't pinpoint excessive memory usage on a single pool tag....   So we are out of luck so far determining what the hell is going on. We have WFBS 7.0 SP1 - but even completely removing that product changes nothing in this regard. The only other application on the server is Accubid Time & Material Billing 11 - so far not been able to point a finger there either.

    I have read somewhere some posts where users are complaining that page table is strewn with allocations of base 20MB per process, after those processes are long gone - in other words, page de-allocation is not occuring.

    I am yet to confirm with a memory dump if we have this issue - but this is the only bit of news that may apply here I have managed to find researching on the web.

    Is anyone here experiencing this issue perhaps?

    Any help would be much appreciated - tired of having to reboot server every week here.



    Monday, November 19, 2012 5:47 PM
  • E, January 9, 2012 - you were feeling pain from the BS Store.exe concept and MS's Training Workshop toolbars that factor their viewpoints on concepts. Unlike them, we have customers, and we work on the ground everyday, massaging end user concern the best we can. It's tedious and stressful when our engines are at the core of another's livelihood. I am a spiritual guy who thinks twice before blurting my first thought. This learned behavior had reaped me great reward. This being said, there is a time and a place for exhausting a strong, educated, passionate rant. I'm grateful that I read your Post today from January of 2012. I can tell you with all sincerity it truly helped me, as I have recently inherited the same issue. What has 15 years in this business taught me? For one thing, people are human. Could it actually be that the 2011 SBS Deployment Team didn't consider flexing its code to address the memory allocation? I imagine the Exchange department in Redmond holds a pretty good size stick, considering Exchanges bread winning ways and market saturation. Seriously, do we really think they would adjust the foundation of this prize winning code for an SBS team who most likely doesn't show up in their quarterly finance review. Yes, people are human. And yes, Microsoft will release products that simply don't butter the bread once deployed in the real world. Thanks for telling it how it is. Again, you helped me today. Based on your post, I'm going to research how best to govern memory allocated by this selfish process. Best regards, Mike
    Thursday, October 17, 2013 12:42 PM
  • Would just like to weigh in to the debate with my 2 cents worth. Anyone claiming that by using all available RAM for any application is a good thing as to not have wasted RAM sitting around doing nothing is surely kidding themselves. As many posters have pointed out this is SBS server and not dedicated to just exchange server and the server needs to provide a range of services to the network users. My general rule is that a Windows server I spec out would be done so as to at least have 20% free RAM. The situation whereby store.exe keeps gobbling up available RAM until the server has next to no RAM available is ludicrous and to claim this is by design and a good one at that is farcical. We have a similar situation with our one and only SBS 2011 install and performance is clearly affected when the RAM utilisation builds to 97% plus.
    Tuesday, February 25, 2014 12:58 AM
  • I've had this conversation with my co-worker who's a smart guy with databases...yes I totally understand why you'd want more of Exchange in RAM, but when it squeezes everything else to a D.O.S. situation I can't agree it's well desgined.

    Despite what anyone thinks about it should or shouldn't have as much or as little RAM as whoever anyone thinks...why not just have the ability to control it, and you can choose on an individual basis as to whether you want to use the function or not. End of story, people aren't necessarily arguing which is 'best''s just there's no 'option'.

    I've too set the Max and Min cache size in ADSI, and from what I can see, the SBS server i'm dealing with is ignoring it.

    Work-around, i'm going to stop and restart the store each night with a settings, we have to do hack jobs like this then.

    Not good enough...just give us the option. If it works without adjusting it, then can run as default, if exchange goes crazy it'll be good to have the adjustment there.

    Friday, July 18, 2014 5:10 AM
  • I too have had the SBS 2011 memory problems causing all the RAM to be consumed by the Exchange Store.  Rebooting the server works but, only for a short time.  Then I found a easy way to fix the issue.

    I installed PGWare SuperRam and the problem has disappeared.

    I have SBS 2011 with exchange (standard) and 16GB ram.  Originally the store was growing to 97-98%, which slowed the server to a crawl and sometimes caused a crash.

    With the SuperRam installed it is working happily and is using 4.3GB ram or 26%.

    Note:  This is the software for dealing with the ram problem I had access too.  I know there are others that will work fine, this is just an FYI.

    Wednesday, August 27, 2014 3:48 PM