High buf/cache memory consumption on Oracle Linux 7 is typically caused by the kernel caching file system data and directory entries rather than active application processes. To resolve this issue, you can manually trigger a cache drop using specific sysctl parameters or adjust the swappiness value to encourage the kernel to reclaim memory more aggressively during high-load scenarios.
Understanding buf/cache Memory Usage
In Linux systems, memory management is handled dynamically by the kernel. The term
buf/cache refers to two distinct but related areas of kernel memory: buffers and caches. Buffers are used for raw block device I/O, while caches store metadata about files and directories. When you observe that
free command output shows low available memory despite low process usage, it is often because the kernel has filled these structures with recently accessed file data to speed up future reads. This behavior is intentional and designed to optimize performance, but it can lead to out-of-memory errors if the system is under heavy disk I/O pressure or if the total RAM is insufficient for the workload.
The confusion often arises because tools like
top or
htop may not attribute this memory to any specific user-space process. Instead, it appears as a global kernel reserve. It is crucial to distinguish this from application memory leaks or GPU memory issues, which require different diagnostic approaches as detailed in our guide on
Process Memory Usage on Different Operating Systems. Unlike GPU memory, which is isolated to graphics drivers, buf/cache is shared across all file system operations.
Diagnosing the Source
Before attempting to free memory, verify that no runaway processes are actually consuming RAM. Use the
ps aux --sort=-%mem | head -n 10 command to list the top ten memory-consuming processes. If these processes show reasonable memory footprints, the bulk of the "used" memory is indeed likely in the kernel cache. You can also check the status of dirty pages, which are cached blocks waiting to be written to disk, using
vmstat 1 5. High values in the
bi (blocks in) or
bo (blocks out) columns indicate intense I/O activity that keeps the cache populated.
Manually Dropping the Cache
If the system is stable but memory is critically low, you can instruct the kernel to drop the page cache, dentries, and inodes. This action forces the kernel to discard cached data, freeing up RAM immediately. However, note that subsequent file access will incur disk I/O latency until the cache is rebuilt.
To perform this operation safely, follow these steps:
- Synchronize pending writes: Run the
sync command to ensure all dirty data is flushed to disk. This prevents data loss when the cache is dropped.
- Drop the caches: Execute the following command as root:
echo 3 > /proc/sys/vm/drop_caches
The value 3 tells the kernel to drop both page cache and dentries/inodes. Using 1 drops only page cache, while 2 drops only dentries and inodes.
- Verify memory recovery: Run
free -h again to confirm that the available memory has increased.
This method provides immediate relief but does not prevent the cache from filling up again. For persistent issues, consider adjusting kernel parameters.
Adjusting Kernel Parameters for Stability
Modifying kernel settings can change how aggressively the system reclaims memory. Two primary parameters influence this behavior:
vfs_cache_pressure and
swappiness.
Tuning VFS Cache Pressure
The
vfs_cache_pressure parameter controls the tendency of the kernel to reclaim memory used for caching directory and inode objects. The default value is usually
100. Increasing this value makes the kernel more aggressive in reclaiming these objects. For example, setting it to
200 doubles the rate at which these caches are shrunk relative to page cache.
To apply this temporarily:
sysctl -w vm.vfs_cache_pressure=200
To make it permanent, add
vm.vfs_cache_pressure=200 to
/etc/sysctl.conf and run
sysctl -p. Be cautious not to set this too high, as excessive reclamation can degrade performance due to frequent lookups.
Configuring Swappiness
Swappiness defines how much the kernel prefers to swap out runtime memory to disk versus dropping page cache. A lower value encourages the kernel to keep data in RAM. On systems with ample RAM, setting swappiness to
10 or
0 can help retain cached data longer, though this might increase the risk of OOM if actual application memory spikes occur. Refer to our article on
Debugging Sudden Memory Usage Spike on Rocky Linux 8.9 for broader context on memory spike diagnostics across RHEL-based distributions.
Monitoring and Prevention
Regular monitoring helps identify patterns leading to high cache usage. Tools like
iostat and
iotop can reveal if specific applications are causing excessive I/O. If certain services consistently generate large temporary files or log outputs, consider configuring them to use tmpfs (RAM-backed file systems) for transient data, which automatically clears upon reboot and avoids polluting the main buffer cache. Additionally, ensure your kernel is updated, as newer versions of Oracle Linux 7 may include optimizations for memory management that address known inefficiencies.
Frequently Asked Questions
Is dropping the cache dangerous for running services?
Dropping the cache is generally safe but causes a temporary spike in disk I/O as services re-read necessary data. Ensure you have synced data first to prevent corruption of unwritten logs or transactions.
Why does buf/cache memory come back after being freed?
The kernel repopulates the cache as soon as files are accessed again. This is normal behavior designed to improve read speeds. If it fills up too quickly, investigate which processes are performing heavy sequential reads.
Can I disable buf/cache caching entirely?
No, you cannot disable caching entirely without severely degrading system performance. The kernel relies on it for efficient I/O operations. You can only tune its aggressiveness via sysctl parameters.
How do I check what is using the cache specifically?
You can use
slabtop to view detailed breakdowns of kernel slab caches, including dentry and inode usage. This helps identify if specific subsystems are holding onto memory excessively.
Does increasing RAM solve high buf/cache usage?
Adding RAM allows the cache to grow larger before triggering reclamation, effectively pushing the problem further away. It does not fix the underlying cause of high I/O or inefficient caching strategies.