I'm currently running a SCCM hierarchy with about 2500 clients spread over 6 physical sites. One of the sites has a central site server which handles everything on one box - Site Server, SUP database, reporting point and SQL server. Each of the other sites is running a secondary site server with a DP, MP and SUP. I also have one site system server in the DMZ with a DP, MP and SUP on it for IBCM clients. The central site server's specs are as follows: 2x Xeon E5405 2GHz Quad Cores 8GB Memory 2x 73GB 15k SAS RAID1 (OS, SCCM install directory, SQL install directory, WSUS install directory) 4x 500GB 7.2k SAS RAID10 (DP, software source files, SQL DB, WSUS content) I've been monitoring the server and noticed that the memory usage is almost constantly between 7.3-7.5GB while the virtual memory is constantly at ~8GB of 16GB avail but the page file itself has only about 620MB used out of that 8GB. Disk usage on the C: drive (2x 73GB) and D: drive (4x 500GB) is very low so I don't think that's the bottleneck. When I say its slow, I mean the console routinely hangs/freezes/crashes and is generally very slow to respond. I'm not a SQL expert by any means so if there are any SQL tweaks or best practices for SCCM, I'd love to hear them. Also, is 8GB of physical memory enough? Would adding more help at all? Thanks in advance for any assistance.

Are you running the console on the site server or remotely? If remotely, how remote? When you say disk usage is low, what does that mean? What perf counters did you use to determine this? Generally, due to the high disk IO demands of ConfigMgr itself, putting it on its own dedicated spindles is suggested. As for the memory, SQL Server, by default, grabs as much physical memory as it can when it starts. You should throttle this so that some memory is left over for ConfigMgr. 8GB should be enough though. Have you baselined this system and are you monitoring it with a real tool like OpsMgr? Have you verified that you have no hardware failures? Are the RAID arrays still healthy?Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys

OMG, 2500 clients! I have more chunks of corn in...uh...nevermind...old joke... Anyway, you should be able to handle plenty of clients on that box. Now, there are just so many things that could be wrong here. It could be a console issue, it could be a memory issue (I know, it may not seem like it, but it may still be), it could be that there are too many roles on this box, it could be the configuration of your disks, it could be the frequency at which you inventory or scan for patches or DCM or collection evaluation or the number of deployments you do. It's almost endless. But one of the first things that's bit me is SQL having too much memory allocated to it. You have 8GB...which should be plenty for SQL and CM to coexist on a hierarchy that small. But during times of stress, SQL has snitched a little more than I'd like. So, open SQL Management Studio and look at the properties for that server. What is the "Maximum Server Memory (in MB)" set to? I think out of the box it's set to it's max (which I think is 2147483647). So, you'll want to make sure the OS has 1.5GB or so, CM has maybe 1.5 with all those roles, and SQL has the rest. So maybe set SQL to 6000 (you may have to play with this to see what's best for you). I know the brochure says that SQL is so much better now at being polite with memory when other processes need it, but in practice I've seen this directly affect our servers bottom line. It's quick and easy to fix, so I don't see a down side to changing this. Second, (and perhaps this should have been first) do you have any schedules set to outrageous frequency? Are you inventorying hardware or software faster than daily? What about heartbeats or collection evaluation or discovery or DCM scans or patch scans? My point is, all of these can multiply the amount of disk I/O that you need to just do the day to day stuff. If it's too frequent, then it could be the whole problem for you. The server would be so busy trying to handle DDRs and MIFs and replication traffic and whatnot through the inboxes that it wouldn't get around to servicing the console in a reasonable amount of time. Be honest with yourself and see if this is an issue. Third, sounds like you've got Site Server, SUP DB, Reporting Point and SQL DB all on this server. Well, the SUP DB shouldn't be a big drain, it's just not a high-volume DB. But the reporting point, now that could be a deal. Depending on how many people are running reports, what kinds of reports, how poorly they've been written, etc. you could find yourself with a simple report exhausting resources from your primary and hanging the console. That was the main thrust for our team to start replicating the primary DB off to another box and reporting from there. Its something to look at. Check the logs or watch SQL trace or something to see how much of your DB I/O is being chewed up by reporting. Often times the simplest stuff can cause deadlocks between reports and day-to-day CM I/O. I'm sure I could go on and on, but there should be enough there to chew on. If it's not one of those, then we gotta gear down.

Sorry, obviously I missed the above updates before I wrote my response. You are already limiting SQL memory.Number2 - (John Nelson)Microsoft MVP (2009) - System Center Configuration Managerhttp://number2blog.com

I changed the HW inventory frequency, but all others are default or once per day... HW Inv: every 12 hrs to every 1 day SW Inv: every 1 day Policy Polling: every 10 mins (default, I think) State Reporting: every 15 mins (default, I think) DCM: every 7 days SUP Scan: every 1 day SUP Eval: every 1 day Heartbeat: every 1 day All AD-related Discoveries: every 1 day I changed SQL max/min from 1024/6144 to 1024/5120 to see if it helps. The reporting doesn't get used enough to make it much of a drain. I know the console is notoriously slow, I guess I just don't expect to wait quite as long as I have to wait - particularly when working with software updates. That seems to be the worst.