Memory Exhaustion - OS Test

Memory exhaustion in an Operating system occurs when the allocated memory resources of a desktop are completely consumed, causing the system to become slow, unresponsive, or crash. Memory exhaustion can lead to significant performance degradation and potential application failures. When memory resources are depleted, applications inside the desktop may experience significant slowdowns. In the process of managing memory pressures, the system may experience high CPU utilization. Memory being over-utilized may cause the system to swap out to disk, which may be indicated by increased swapping or disk I/O. The operating system may display OOM errors that result from processes being killed to free up memory. Memory-reliant applications like databases, in-memory caches, or web servers may experience crashes or hangs due to memory shortages. Some applications may start throwing memory allocation errors or failing to start. The desktop can experience sluggishness or unresponsiveness, resulting in slow input or network communication. If memory exhaustion is severe, the whole desktop may freeze or require a restart. All the above mentioned issues points towards the importance of monitoring memory usage and proactive identification and remediation of memory exhaustion.

This test monitors every Windows system and notifies the administrators if there is any memory exhaustion happened, if the system commit charge approaches system commit limit, when paged pool and non paged pool usage is unusually high, or if the desktop is using high physical memory. This way the administrators can reduce the risk of memory exhaustion by identifying resource-intensive processes or applications, memory leakage, etc. long before it affects the performance of the system. This in turn helps to improve system stability, and ensure more efficient resource utilization.

Target of the test : A Windows Systems Group

Agent deploying the test : A remote agent

Outputs of the test : One set of results for every Windows system.

Configurable parameters for the test:

Parameter	Description
Test Period	How often should the test be executed. By default, this parameter is set to 1hr.
Host	The nick name of the Windows Systems Group component for which this test is to be configured.
Port	The port at which the specified Host listens. By default, this is NULL.
Inside View Using	To obtain the 'inside view' of performance of the systems - i.e., to measure the internal performance of the systems - this test uses a light-weight eG VM Agent software deployed on each of the systems. Accordingly, this parameter is by default set to eG VM Agent.
Report By User	This flag is set to No by default. This implies that the Windows systems in environments will always be identified using the system name. In other words, this test will, by default, report measures for every systemname. On the other hand, if you want this test to report the measures for every user on a system, then set this flag to Yes. In such a case, this test will report the measures for every username_on_systemname.
Report Powered OS	By default, this flag is set to Yes, then the 'inside view' tests will report measures for even those Windows systems that do not have any users logged in currently. The systems will be identified by their name and not by the username_on_systemname. On the other hand, if this flag is set to No, then this test will not report measures for those systems to which no users are logged in currently.
Is Cloud VMs?	This flag is set to Yes by default. The value of this flag cannot be changed. This implies that the cloud-based Windows systems in environments will always be identified using the login name of the user. In other words, in cloud environments, this test will, by default, report measures for every username_on_systemname.

Measurements made by the test

Measurement	Description	Measurement Unit	Interpretation
Has memory exhaustion happened?	Indicates whether or not any memory exhaustion happened on this system.		The values that this measure can report and their corresponding numeric values are discussed in the table above: Measure value Numeric value No 0 Yes 1 Note: By default, this measure reports the above-mentioned Measure Values while indicating whether memory exhaustion happened or not. However, in the graph of this measure, states will be represented using the corresponding numeric equivalents only.
System commit limit	Indicates the maximum amount of virtual memory that can be committed without extending the paging file(s) on this system.	GB
System commit charge	Indicates the the total amount of virtual memory that all processes have requested and that the system has committed to providing on this system.	GB	If commit charge approach the commit limit, it could lead to performance issues.
Process commit charge	Indicates the total amount of virtual memory that a specific process has requested and that the system has committed to providing on this system.	GB	This measure helps in identifying processes that consume excessive virtual memory.
Paged pool usage	Indicates the amount of paged pool used by this system.	GB	If paged pool usage is unusually high, it may indicate a memory leak or inefficient memory usage by certain drivers or system components. In such cases, consider updating device drivers, especially network drivers, as they are often associated with memory leaks in the paged pool.
Non paged pool usage	Indicates the amount of non paged pool used by this system.	GB	If non-paged pool usage is unusually high, it may indicate a memory leak or inefficient memory usage by certain drivers or system components.
Total memory available	Indicates the total amount of physical memory available for use in this system.	GB
Memory usage	Indicates the amount of physical memory used by this system.	GB	This measure helps in identifying resource-intensive applications and potential memory leaks, ensuring your system operates efficiently.
Total processes	Indicates the total number of processes currently running in this system.	Number