You remember my allocated memory alert problem?  My SBS Monitoring would start growing after I rebooted for monthly patches and would just keep notching up until I would get umpteen annoying alerts in the system telling me that something was wrong.  Mine was easily solved by ‘throttling’ the amount of memory that my system would take for the MSDE instance of SBSMonitoring. 

There are those out in SBSland that are instead seeing that Sharepoint is the one doing this ‘ram memory’ suck.  Now first I will state that I am personally NOT seeing this, but if you are a heavy SQL user, you may or may not.  SQL, like Exchange is designed to give and take the memory that it needs.  However, if SQL starts ‘sucking’ so much that the alerts start freaking you out …here’s what I would do if it’s Sharepoint that is the one causing the RAM to ‘tick up’.  [again remember, for SBSMonitoring I have NO ISSUE is just saying follow the blog post from before and take a look at the ‘RAM’ values in your daily performance alerts and SBS monitoring is probably going to be in the 125-150 range [your actual RAM value may differ].  For those where it’s Sharepoint, I want you to get a better ‘feel’ for your system as there isn’t a real good ‘one size fits all’ answer and you need to ‘build a baseline’.

As always, you are wandering into the area that I would STRONGLY advise customers to call Microsoft PSS, and partners to use the Partner support resources.

  • Step one – establish the baseline – like in the prior blog post, the best thing to do is to establish that it is truly Sharepoint doing the ‘sucking’ of the RAM.  If it is, reboot the server and record the amount of RAM Sharepoint is now using ‘after’ the reboot.

  • Step two – build a baseline value – watch the Sharepoint instance for a few days, how long before it starts ‘ticking up’?  You can get a ‘feel’ for where that ‘throttle value should be by watching it for a few days.

  • Step three – do you have enough RAM in the machine?  For SBS 2000 I had 2 gig, for 2003 I have 4 gig.  Most are comfortable at about a 2 gig level on SBS 2003 [I tend to overbuy]

  • Step four – is your page file large enough?  If you have the RAM in place at the time of building the machine, your paging file is about 1.5 times your physical ram.  If you add RAM later, you’ll need to adjust this manually.

  • Step five – ask yourself, are your applications truly slowing down by this?  Do you see true performance impact?

  • Step six – Is it just that you have a lot of things going on in your box?  Les has a box that throws off these allocated memory alerts but he’s got like three Virtual machines running under it, look at the services running on that server and none of them look bad at all.  What you are truly looking for is one of the services not ‘settling down’ as I would call it.  Again, if it’s just SBSmonitoring, I’d adjust that with no hesitation.  For anything else, I’d monitor and call.

You should be aware that Mariette on the site [which yes, is a real live production SBS 2003 under the hood handling that traffic], she did ‘throttle’ the SQL/Sharepoint to be 250 megs of RAM which she says appears to be enough BUT [and here’s the caveat] she’s smart enough to know what she is doing and used Performance monitoring tools to make sure she set it right.

Bottom line if you aren’t comfortable with SQL [as I would not be at this stage, whereas Mariette is very capable], I would call PSS or Microsoft partner support if Sharepoint is the service that is making your memory alerts go too high and start to annoy…. and I mean REALLY annoy…. really and truly annoy….. Annoyingly annoy….

Kinda reminds me of the annoying Perf errors we used to get in SBS 2000…ah what memories…


Comments are closed.