This measure corresponds to a shortage of memory to satisfy all program needs. That means the operating system must flush the buffer pool to store and retrieve data from the hard disk.
Such situations will result in high Paging File usage. When free memory runs low, the server flushes the oldest page to disk when it requires new space. Thus, sustained physical I/O both for reading and writing, which is a significant performance concern
The more memory your server has, the more cached disk reads and writes it can perform. Lack of system memory can cause high non-cached disk reads and writes. Adding memory to your server can help lower physical disk access.
As well as measuring and alerting to the absolute total of available memory (in Gbyte), this alert compares available to total, which can be a more meaningful indicator of stress.
The source may be either a virtual or physical memory limit, memory pressure from other applications, or inside the SQL Server.
Find out how you can save hours of work when investigating the root cause of this issue.
Symptoms:
Free memory is low – all host functions are running slower than usual.
Impact: High
A fall in available RAM may slow SQL responses.
Available memory running below the critical level can be an indicator of an impending crash or freeze.
Expected behavior
There is no standard metric for free memory. Based on the experience of our Expert Support team, a minimum of available space should be 1 gigabyte or more for low total RAM Servers (up to 16 GB) and more than 15 GB available memory for high total RAM servers.
Also, this level must be maintained for an extended period. A steady memory availability level is essential for the server’s good functionality. Consider adding memory while investigating the root cause to allow the server to run smoothly.
This alert measures and alerts current free RAM Memory in MBS or GBs.
Possible causes
1- Long system tasks Priority: High
Low free memory might occur once too many applications are running simultaneously. Otherwise, low free memory happens due to memory leaks, malware, or non-optimal settings.
Problem identification:
Identify the cause of low free memory and check if it’s recurrent. Use system monitoring tools.
- Check if you have several applications running simultaneously; they can consume a lot of RAM memory. While doing it, also look for background processes. You should consider closing applications that you are not using currently. To do so, you need to enter the task manager and look at the current processes running. However, you can’t guarantee precise results when checking the online status with no historical events.
- On Windows, use Task Manager to check which applications are using more memory and identify possible memory leaks. Consider reinstalling it. In a Linux environment, use “free: or “free – h” commands to display memory usage statistics, including available memory. Take into account that part of Linux systems has configured swap space, which can be monitored as well when using tools like “swapon -s” or “free -h” commands.
- Run a malware scan on your computer to identify and remove any threats. It might take time and should not be done during working hours.
- Consider upgrading your RAM to improve performance – This might be an expensive solution.
- Run a system file check in order to locate corrupted files.
Recommended action :
Possible short-term action – add RAM.
Check the buffer pool cache hit ratio and adjust the buffer pool allocation. For more information, see our knowledge base regarding cache hits here.
In urgent cases, activating an Out of Memory (OOM) Killer might be helpful when the system runs out of memory and has no more space to allocate.
2- Low page life expectancy – Priority: Medium
For SQL Server database servers, the main process that takes most of the RAM memory is the “sql server”. If there’s a memory issue, apps can’t work.
See our recommendations regarding PLE here.
Recommended action :
Possible short-term action – add RAM.
Check the buffer pool cache hit ratio and adjust the buffer pool allocation. For more information, see our knowledge base regarding cache hits here.
3- Long-running transactions – Priority: Medium
Properly size your log file and disk capacity to account for a worst-case scenario (e.g., maintenance or known large operations).
Problem identification:
Identify long-running transactions that hold on OS resources while focusing on cache usage.
- Use SQL Server Management Studio to identify the long-running transaction consuming memory. For Oracle, you should use Oracle Dynamic Performance Views or other tools.
- Look for queries with code written ineffectively. Consider how to improve the performance of these queries. Try to look at improving query code, reducing transaction length, or identifying inefficient operations in the query’s plan. This task might be complicated, requiring a highly skilled DBA.
- You may need to increase the amount of memory allocated to SQL Server or Oracle.
Recommended action :
Optimize the application code – avoid starting a transaction in your application that is having long conversations with SQL Server or risks leaving one open too long. If doing operations on large numbers of rows, consider batching them up into more manageable chunks and giving the log time to recover.
Improve the query execution plan, increase the allocated max memory, or consider upgrading your hardware to increase the amount of RAM available to the server.
See our knowledgebase entry regarding long queries here.
4- SQL not releasing memory to the operating system – Priority: Medium
On SQL Server, check the Max Server Memory configuration option, which determines how much memory SQL Server can consume. It needs to allow sufficient space for the operating system’s activities. If too much is reserved for SQL, it is not released when the SQL Server is under light load, so the dynamic balance between OS and SQL does not adjust automatically. Compare the Max Server Memory with the existing total RAM memory.
On Oracle, use the System Global Area (SGA) or Program Global Area (PGA), for the Oracle database process. As long as it’s in use, if Oracle does not release memory back to the operating system after executing SQL statements, it can contribute to memory exhaustion over time, as well as in Linux systems.
Oracle processes’ gradual accumulation of unused memory can lead to memory shortages on the system as available memory becomes exhausted.
- Verify that the maximum server memory setting is appropriate for your server’s hardware and workload.
Too low? SQL Server or Oracle may not have enough memory to store frequently accessed data in the buffer pool.
Too high? SQL Server or Oracle may be consuming too much memory, which can lead to memory pressure and paging to disk. - Compare the maximum server memory setting in SQL Server with the existing total RAM memory. Use the Max Server Memory configuration option to configure how much memory SQL Server can consume.
- For Oracle, you should use oracle dynamic performance views or run scripts in SQL-plus.
- You need to do it parallelly while entering the task manager and viewing the current performance, which changes every moment. Keep in mind that you don’t have historical data on it.
Recommended action :
On SQL Servers, change current max memory settings while allowing sufficient space for the operating system’s own activities. If too much is reserved for database activity, it is not released when the SQL server is under light load, so the dynamic balance between OS and SQL does not adjust automatically.
On Oracle databases, ensure that memory parameters, such as SGA and PGA sizes, are properly configured based on the workload and available system resources.
