Re: Exchange, Virtual Memory, too much RAM? Event ID 9582
From: Michael Palermiti [MSFT] (michaelp_at_online.microsoft.com)
Date: 02/25/04
- Next message: Larry: "Security Event Monitor"
- Previous message: Daniel Woodhouse: "SUS"
- In reply to: Ben Winzenz [Exchange MVP]: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582"
- Next in thread: Matthew: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582 - thank you everyone!"
- Reply: Matthew: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582 - thank you everyone!"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 25 Feb 2004 14:13:08 -0500
Hi Ben - I think your point is valid, strictly from a troubleshooting
perspective. The same argument could be made for a lot different problems,
even outside of memory or computer issues. For example (and it may be a
poor one at that!), a race car team is not going to reduce the engine's
horsepower because the engine is starving for oxygen at high altitudes,
instead they are going fine tune the engine, fuel intake, or whatever to
make sure they maintain top output from the engine.
A few points of clarification from your post: Exchange 2000's store cache is
hard coded at 858Mb, regardless of the amount of RAM installed. 2003
adjusts the cache size based on the RAM and OS settings. I think you are
referring to the Dynamic Buffer Allocation mechanism.
My point, and I'll keep it very brief, is that the Windows 2000 Standard
Server OS can support up to 4GB of RAM. Therefore it was advertised and
sold as an OS to support up to that max (though it was also never designed
to support the /3GB switch). Well, then came Exchange 2000 which makes the
recommendation that with 1GB RAM or more, you need the /3GB switch in the
boot.ini. So, YES, what you mentioned about the planning part is definitely
correct! We really try to stress that to customers, but like I said in my
weblog, with Win2003 this shouldn't be as big a deal. But for those who
don't, tweaking/optimizing the memory usage should always be the way to go,
versus MS asking customer's to remove memory from their system that was sold
and designed to support the amount of RAM they purchased. Its just a poor
solution in more than one way. Besides that big "marketability" aspect, we
can't forget about the smaller one... when you take memory out of the
system; you are restricting the overall scalability, because now the server
has less to work with. There are other reasons too, that are probably
outside the scope of this forum.
I hope this makes sense and sheds some light on what I meant. I'm going to
update my blog with this info, so thanks for the question! ;)
-------------------------
Michael Palermiti
Enterprise Messaging Support
This posting is provided "AS IS" with no warranties, and confers no rights.
© 2004 Microsoft Corporation. All rights reserved.
"Ben Winzenz [Exchange MVP]" <benwinzenz@NOSPAM.gardnerwhite.com> wrote in
message news:uKjWb87%23DHA.2808@TK2MSFTNGP10.phx.gbl...
> I'm interested to know why you say removing RAM is not a recommended
> solution? In fact, on your blog, you state that it is never a good
> solution. Why exactly is that? If Exchange tunes it's VM usage in part
> based on the amount of physical memory, why is it a "bad" solution to
remove
> memory so that Exchange can correctly tune itself? You and I both know
that
> there is no way that W2K Standard running Ex2K is going to be able to
> utilize more than 2gb of physical RAM. Or do you think that's not true?
> I'm not looking for an argument or anything, just some clarification
because
> I have never heard anywhere else that removing RAM is not a solution.
> Obviously, the best solution would be to correctly spec out the server,
and
> order Advanced Server if it is going to have more than 1gb or RAM, but I
am
> interested in your views on this (or the views of others from the Support
> team as well). Feel free to either post replies here, or simply e-mail me
> directly.
> --
> Ben Winzenz
> MVP - Exchange
> Network Engineer
> Gardner & White
> http://www.techtidbits.net
>
> Exchange FAQ's: http://www.swinc.com/resource/exch_faq.htm
> Exchange 2000 FAQ's: http://www.swinc.com/resource/e2kfaq.htm
>
> "Michael Palermiti [MSFT]" <michaelp@online.microsoft.com> wrote in
message
> news:%23stibE6%23DHA.3284@TK2MSFTNGP09.phx.gbl...
> > Steve -
> >
> > For SBS2000: Correct. Beyond that those tweaks, there are other things
> > that
> > can be done, but they require in-depth data analysis by PSS.
> > Hope this helps.
> >
> > ---------------------------------
> > Michael Palermiti
> > Enterprise Messaging Support
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > © 2004 Microsoft Corporation. All rights reserved.
> >
> >
> > "Steve Foster [SBS MVP]" <steve.foster@picamar.co.uk> wrote in message
> > news:xn0dey2lyy2v3700e@msnews.microsoft.com...
> >> Michael Palermiti [MSFT] wrote:
> >>
> >> > Hi guys - I just read this thread and thought I'd chime in. First of
> >> > all, I just wrote a bunch on the 9582 event in my MSDN weblog (i.e.,
> >> > blog) at http://blogs.msdn.com/mfp2. Enjoy!
> >> >
> >> > Defragging the database is not going to do a thing for virtual memory
> >> > fragmentation. Removing RAM is not a recommended solution either.
> >> > Please see my weblog for a lot of information on this topic, which
> >> > includes a link to my webcast on Troubleshooting Exchange 2000
> >> > Performance.
> >>
> >> You refer readers to:
> >>
> >> http://support.microsoft.com/?id=325044
> >> 325044 HOW TO: Troubleshoot Virtual Memory Fragmentation in Exchange
> >> 2003 and Exchange 2000
> >>
> >> And from reading that article, it would appear that the only aspects
> >> suitable for SBS2000 operators are the following:
> >>
> >> http://support.microsoft.com/?315407
> >> 315407 XADM: The "HeapDecommitFreeBlockThreshold" Registry Key
> >>
> >> and
> >>
> >> http://support.microsoft.com/?266768
> >> 266768 XSTR: How to Modify the Store Database Maximum Cache Size
> >>
> >> --
> >> Steve Foster [SBS MVP]
> >> ---------------------------------------
> >> MVPs do not work for Microsoft. Please reply only to the newsgroups.
> >
> >
>
>
- Next message: Larry: "Security Event Monitor"
- Previous message: Daniel Woodhouse: "SUS"
- In reply to: Ben Winzenz [Exchange MVP]: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582"
- Next in thread: Matthew: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582 - thank you everyone!"
- Reply: Matthew: "Re: Exchange, Virtual Memory, too much RAM? Event ID 9582 - thank you everyone!"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
