Re: WSUS
- From: "Les Connor [SBS MVP]" <les.connor@xxxxxxxxxxxx>
- Date: Wed, 17 Oct 2007 10:05:04 -0500
Hi JJ,
You need to learn how to limit the memory use of the SQL/MSDE instances. A google search of this newsgroup should turn up some hits.
--
Les Connor [SBS MVP]
"JJ" <JJ@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:8CA9A03C-E479-4BA0-9E72-95CB92E3532B@xxxxxxxxxxxxxxxx
"Steve Foster [SBS MVP]" wrote:How do you know that it's "too much"?
Is your server exhibiting significant performance problems, and if so, how
do you know that it's down to excessive memory usage by the WSUS SQL
instance?
You're actually defending Microsoft on this? Try this on a server running
SQL Server:
tasklist /svc /fi "IMAGENAME eq sqlservr.exe"
That gives you the process ids, instance names, etc. of all SQL Server
instances on the PC. Using the process id in Task Manager, you can find which
SQL Server instance is using what amount of memory.
I guess since you do not know these basic things, it's pointless to try to
convince you of anything - it would just bounce off you.
And how do you know my server is not exhibiting performance problems?
Plus, how can you speak for every possible installation of SBS, even with
4GB of RAM?
JJ
JJ wrote:
>Hi:
>
>Is there anyway to uninstall WSUS from a SBS installation? It's SQL >Server
>instance uses way too much memory.
How do you know that it's "too much"?
Is your server exhibiting significant performance problems, and if so, how
do you know that it's down to excessive memory usage by the WSUS SQL
instance?
>And why didn't Microsoft build SBS in a way that is uses a single SQL
>Server
>instance for WSUS, MSFW, SharePoint and SBS Monitoring?
There are a number of factors involved in deciding whether to use multiple
instances of SQL Server or not. Not least in the case of SBS is that it's
a number of pre-canned applications stitched together and there's limited
room for changing installation methodologies for the individual products
without making them unsupportable. Another significant angle is which
versions of SQL are supported by each application, and the consequent
variation in SQL features available to each application.
In the grand scheme of things, it really doesn't matter much anyway. The
major difference is in visibility and manageability - you can tell which
SQL instance(s) are busier or working harder than the others, something
that would be impossible if they were all running together.
>No wonder SBS brings servers with 4GB of RAM to their knees. And to top >it
>all, SBS can't use more than 4GB of RAM due to the 32-bit architecture.
I don't see SBS servers with 4Gb RAM "on their knees". They're running
nicely, and making use of all that RAM, just as I expected them to. If an
SBS server with 4Gb RAM really is suffering, then it's underspecified for
the given workload.
SBS2003 can't use more than 4Gb RAM because it's essentially WS2003
Standard, which also can only use 4Gb RAM.
The next version of SBS is going to be 64-bit, and I speculate that the
RAM limit is likely to rise significantly. If it remains consistent with
WS2003 standard, that would be 32Gb.
>I can't imagine I'm the only person to request this.
You do seem to be, at least so far.
--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
.
- Follow-Ups:
- Re: WSUS
- From: JJ
- Re: WSUS
- Prev by Date: Re: WSS 3 Backup Permissions on SBS 2003
- Next by Date: OS's on Virtual PC and Virtual Server
- Previous by thread: Re: WSUS
- Next by thread: Re: WSUS
- Index(es):
Relevant Pages
|
