3.1.2 Memory monitoring examples
This subsection explains how to monitor memory performance.
- Organization of this subsection
(1) Overview
You can monitor memory performance to detect physical memory shortages and incorrect process operations.
Memory consists of physical memory and a paging file, as illustrated below. However, because the causes of bottlenecks are not limited to a small amount of physical memory or a small paging file, the paging status, page faults, and other items related to efficient memory usage must be monitored as well.
The following figure illustrates the configuration of the memory space.
|
|
![[Figure]](GRAPHICS/ZU01002.GIF)
Insufficient physical memory degrades overall system performance. Memory areas not accessed by programs for a long time are saved to the paging file, and are loaded into physical memory on demand. Physical memory is efficiently used in this manner. Note, however, that paging file access is markedly slower than physical memory access. Therefore, frequent paging or frequent page faults will considerably delay system processing.
-
Paging
Paging is the movement of code and data between physical memory and a page file. Loading from the paging file into physical memory is referred to by the term page-in, and saving from physical memory to the paging file is referred to by the term page-out.
-
Page fault
A page fault is an attempt to access to an area that does not exist in physical memory.
Because paging often occurs even in normal processing, measure performance when the system is operating stably before attempting to determine proper thresholds.
The Available Memory alarm is provided by the monitoring templates. If you want to perform more detailed monitoring, see the following table, which lists and describes the principal records and fields related to memory monitoring.
|
Record |
Field |
Description (example) |
|---|---|---|
|
PI |
Pages/sec |
The number of operations that caused paging per second. If the value of this field continues to be at or above the threshold, memory might be a system bottleneck. |
|
Page Faults/sec |
The number of page faults occurring per second. If the value of this field continues to be at or above the threshold, memory might be a system bottleneck. |
|
|
Data Map Hits % |
The percentage of the number of requests that mapped a page to the file system cache. If the value of this field continues to be low, memory might be a system bottleneck. |
|
|
Total Physical Mem Mbytes |
The amount of physical memory. |
|
|
Available Mbytes |
The amount of available physical memory. |
|
|
Used Physical Mem Mbytes |
The amount of physical memory in use. |
|
|
% Physical Mem |
Physical memory usage. |
|
|
Commit Limit Mbytes |
The amount of virtual memory. |
|
|
Non Committed Mbytes |
The amount of available virtual memory. |
|
|
Committed Mbytes |
The amount of virtual memory in use. If the value of this field continues to be at or above the threshold (the Total Physical Mem Mbytes field value of the PI record), a larger amount of memory might be required. |
|
|
% Committed Bytes in Use |
Virtual memory usage. If the value of this field continues to be at or above the threshold (determined by the system load status), the paging file might need to be expanded. |
|
|
PD_PAGF |
% Usage |
Paging file usage. If the value of this field continues to be at or above the threshold (determined by the system load status), the paging file might need to be expanded. |
The cause of a system memory shortage is not always physical memory itself. A problem with a program can also cause a shortage. By monitoring memory usage for each process, you can identify the cause of shortages. If there is a process improperly occupying memory or if the amount of memory used by a process continues to increase steadily, the program running the process is likely to be defective.
The following table lists and describes the principal records and fields related to monitoring the memory usage of a specific process.
|
Record |
Field |
Description (example) |
|---|---|---|
|
PI |
Pool Nonpaged Bytes |
The amount of physical memory that is being used and cannot be paged out. If the value of this field continues to increase even when server activities are not increasing, a process causing a memory leak might exist. |
|
PD_PDI |
Page Faults/sec |
The number of page faults occurring per second. A process causing a bottleneck can be detected from the frequency of process-specific page faults. |
|
Pool Nonpaged Kbytes |
The amount of other types of memory and the number of handles being used. If the value of any of these fields continues to increase, a process causing a memory leak might exist. |
|
|
Pool Paged Kbytes |
||
|
Working Set Kbytes |
||
|
Page File Kbytes |
||
|
Private Kbytes |
||
|
Handle Count |
(2) Monitoring methods
(a) Monitoring the amount of available physical memory
The unused size for physical memory (Available Mbytes field in the PI record) can be monitored using the Available Memory alarm provided by the monitoring templates.
For details, see 3.2.2(1) Monitoring template.
(b) Monitoring the usage status of virtual memory
You can use the usage status of virtual memory as a guideline for determining whether to increase physical memory.
Even when memory usage is temporarily high, if the high load status does not persist, performance degradation might be permissible. Therefore, monitoring both the load status of virtual memory and the usage status of virtual memory is recommended.
If the amount of used virtual memory (the Committed Mbytes field of the PI record) is larger than the total amount of physical memory (the Total Physical Mem Mbytes field of the PI record), more memory might be required.
For definition examples, see 3.2.2(2) Definition examples other than for monitoring templates.
(c) Monitoring the load status of virtual memory
You can use the load status of virtual memory as a guideline for determining whether to increase physical memory.
Even though memory usage is temporarily high, if the high load status does not persist, performance degradation might be permissible. Therefore, monitoring both the load status of virtual memory and the usage status of virtual memory is recommended.
If the number of page faults (the Page Faults/sec field of the PI record) is at or above the threshold, the amount of memory allocated on the server might be less than the amount of memory secured by applications.
If the paging frequency (the Pages/sec field of the PI record) is at or above the threshold, the amount of physical memory might be insufficient.
For definition examples, see 3.2.2(2) Definition examples other than for monitoring templates.
(d) Checking whether a memory leak has occurred
A memory leak, which decreases the amount of available memory, might prevent the entire system from operating correctly. You can detect memory leaks by checking the line graph of a historical report for whether the amount of nonpaged-pool memory (the Pool Nonpaged Bytes field of the PI record) is increasing steadily.
If the amount of nonpaged-pool memory (the Pool Nonpaged Bytes field of the PI record) is increasing steadily even when the number of active processes has not changed, a process causing a memory leak might exist.
For definition examples, see 3.2.2(2) Definition examples other than for monitoring templates.
(e) Monitoring the amount of memory used by processes
If you think a memory leak has occurred, you can identify the process that is causing the memory leak.
To do so, in a status in which server activities are not increasing, use a real-time report to monitor the amount of memory used by each process for a period from a few to some tens of minutes. For this monitoring, you can use, for example, the Working Set Kbytes field of the PD_PDI record. Then, in the displayed line graph, check for a process whose memory usage is increasing.
If you identify a process causing a memory leak, you can contact the vendor or take other appropriate action.
For definition examples, see 3.2.2(2) Definition examples other than for monitoring templates.