Windows 2000 Memory Bottleneck Performance Counters

Diagnosing memory bottlenecks in Microsoft Windows 2000 requires identifying whether the system lacks sufficient physical RAM, is experiencing excessive paging, or is suffering from memory leaks within specific processes. By using the built-in Performance console (PerfMon), administrators can isolate memory constraints using a targeted set of counters focused on available memory, paging activity, committed memory thresholds, and pool allocations.

1. Memory\Available Bytes

This counter measures the amount of physical memory immediately available for allocation to a process or system use.

  • Diagnosis: In Windows 2000, a sustained value below 4 MB indicates a critical memory shortage. A consistent threshold under 10 MB suggests that the system is low on RAM and may begin aggressive paging.

2. Memory\Pages/sec

This counter tracks the rate at which pages are read from or written to disk to resolve hard page faults.

  • Diagnosis: While occasional spikes are normal during application startup, a sustained value consistently higher than 20 to 30 pages per second indicates excessive disk paging. When paired with high disk activity, this is the primary indicator of a physical memory bottleneck (thrashing).

3. Memory\Pages Input/sec

This counter measures the number of pages read from disk to resolve page faults.

  • Diagnosis: Because Pages/sec accounts for both reads and writes, Pages Input/sec specifically isolates the read operations required when requested code or data is not found in physical RAM. High sustained values confirm that processes are starved of physical memory.

4. Memory\Committed Bytes and Memory\Commit Limit

  • Committed Bytes: Represents the amount of virtual memory that has space allocated in physical memory and the paging file combined.
  • Commit Limit: Represents the total amount of virtual memory that can be allocated without expanding the paging file.
  • Diagnosis: If Committed Bytes approaches the Commit Limit, the operating system is running out of total virtual memory capacity. This requires increasing the paging file size, adding physical RAM, or terminating memory-heavy processes.

5. Paging File(_Total)% Usage and % Usage Peak

These counters show the current and peak percentages of the paging file that are actively in use.

  • Diagnosis: Sustained usage exceeding 70% to 80% signifies that the operating system relies heavily on secondary storage to compensate for insufficient physical RAM. Consistently high peak usage indicates that the page file size should be increased or more RAM must be installed.

6. Memory\Pool Nonpaged Bytes and Memory\Pool Paged Bytes

These counters monitor system memory pools used by the operating system kernel and hardware drivers.

  • Pool Nonpaged Bytes: Tracks memory that must remain in physical RAM and cannot be written to the page file.
  • Pool Paged Bytes: Tracks system memory that can be paged to disk.
  • Diagnosis: A steady, uninterrupted upward trend in either counter without stabilizing suggests a memory leak within a device driver or system service.

7. Process(*)\Working Set

This counter tracks the amount of physical RAM currently dedicated to each running process.

  • Diagnosis: Once system-wide counters confirm a bottleneck, review this counter to identify which specific application or service is consuming excessive physical memory. If an individual process shows a continuous increase in its Working Set without releasing memory, that process has a memory leak.