How to find out if my Windows Server 2003 needs more memory?

Solution 1:

You really want to see whether you're having a significant number of hard page faults (that is, page faults that have to go to the disk) or not. Watch the "Pages Input / sec" to get a feel for how many hard page faults are occurring. This is your first best indication that you're running low on RAM.

"Page Faults / sec" includes both hard and soft (that is, page faults where the page needed is still in physical memory) faults.

The "Working Set" counter on the "_Total" instance of the "Process" object will show you the total amount of memory used by all processes. Ideally, you'd like this number to be under the amount of physical RAM in the computer.

Edit:

Your question was about memory, but the phrasing raises the question as to whether you're aware of what your specific bottleneck is or not.

You should be watching the "big 4" counters, just as a matter of day-to-day business:

• Processor - % Processor Time
• Memory - Pages Input / sec
• Physical Disk - Avg. Disk Queue Length - For each physical disk in the computer
• Network - Bytes Total / Sec - For each network interface on the computer

You don't want processor time to be consistently high. Different people will give you different opinions on what you should see. My take is: This is the last thing to upgrade (since it generally means "replace the computer") unless you're seeing consistently high processor time. Even then, it can be cheaper to profile the application and improve the performance that way then to replace the computer (when you consider all the costs associated with replacing the computer).

We've already talked about the memory counter.

The disk queue represents the number of requests waiting on the disk subsystem to have availability. You should monitor each discrete physical disk or RAID volume on the machine as an individual counter. The specifics of a "bad disk queue" number depend on the application. Microsoft SQL Server 2005 and up, for example, will load the disk queue more heavily than other applications because it's trying to maximize the IO bandwidth. In general, though, you want to see this number smaller than 2 unless you know your app. is purposefully loading the queue up.

The network counter indicates the number of bytes sent and received per interval and should be tracked on each discrete netwokr interface as an individul counter. Ideally, you'll scale this counter such that 100% bandwidth is near the top of the graph. You shouldn't see 100% bandwidth utilization on Ethernet, but you might see spikes close to it. If you're seeing consistently high network load it's probably a sign that you could use more / faster network connectivity to the server computer.

Watching these "big 4" counters can give you a great "at a glance" view of where a bottleneck might lie. From that, you can dig down using the "Process" object into individual processes to determine where IO's or network activity is occurring.

Solution 2:

How much memory you need is relative to your applications. If performance is slow, than it could be for a variety of reasons (not just memory).

You should set up a number of performance monitors with perfmon and see what happens when users complain that things are "slow."

Is it because the CPU is hitting 100%? Is it because your memory requirements jump? Is your hard disk thrashing?

I wouldn't assume right away that memory is the bottleneck.