Allocated Memory Alerts & Mem Usage vs. VM Size

Tech-Archive recommends: Fix windows errors by optimizing your registry

The blog post linked below is what got me on the right track (I think) to
solving my Allocated Memory Alerts.
http://msmvps.com/blogs/bradley/archive/2005/02/04/34984.aspx

After working thru the article I have a question. My "Mem Usage" in Task
Manager looks like this (including add'l info from "tasklist /svc"):

store.exe: 666,548 K MSExchangeIS
sqlservr.exe: 182,304 K MSSQL$SBSMONITORING
sqlservr.exe: 147,840 K MSSQL$WSUS
sqlservr.exe: 145,808 K MSSQL$PROTECTIONPILOT
sqlservr.exe: 31,956 K MSSQL$SHAREPOINT

(FYI, ProtectionPilot is the DB used by my enterprise antivirus management
console.)

Seems OK to me; I have 4GB of RAM in this server and thus far am using a
system-managed pagefile, which currently shows 4091MB allocated. I
considered manually setting the pagefile size larger (based on 1.5x physical
memory size it'd be 6GB), but I've continued to let Windows manage it for
now.

Now, when I add the VM Size column to Task Manager to see each process's
contribution to the "total commit charge", things look very different.
Below I've inserted the VM Size column in between the process name and Mem
Usage columns displayed above:

store.exe: 671,040 666,548 K MSExchangeIS
sqlservr.exe: 1,692,708 182,304 K ...$SBSMONITORING
sqlservr.exe: 294,112 147,840 K ...$WSUS
sqlservr.exe: 793,540 145,808 K ...$PROTECTIONPILOT
sqlservr.exe: 104,396 31,956 K ...$SHAREPOINT

The blog article linked at the beginning of my post shows how to throttle
the amount of memory these processes can take, but they refer only to Mem
Usage. Will it be just as effective in helping me get my VM Size under
control? My Allocated Memory alert threshold is currently set to
3758096384, and I'm still tripping it. My Task Manager currently shows a
Commit Charge of 4577M / 7904M, and that seems way high to me, considering
what the servers running and the fact that we're a 30-person shop.

Thanks in advance for all thoughts on this.

Bryan



.