How to limit file cache in CentOS(Linux)? Setting up Swappiness and caching in Linux Managing the cache cache in the Linux kernel 2.4.
It is often important to check shared and process memory usage on servers, as well as unused resources. If you are running a web server, then the server must have enough memory to serve site visitors. If this is not the case, then the site will become very slow or even become unavailable when there is a surge in traffic, simply because there will not be enough memory. The same thing as what happens on a desktop computer.
1. Free command
The free command is the simplest and easiest to use command to check memory usage on Linux. Here's a short example
$ free -m total used free shared buffers cached Mem: 7976 6459 1517 0 865 2248 -/+ buffers/cache: 3344 4631 Swap: 1951 0 1951
Option -m displays all data in megabytes. Total total volume RAM 7976 MB installed on the system, that is, 8 GB. Column used shows the amount of RAM that can be used on Linux, in our case it will be about 6.4 GB. The catch here is the speakers cached And buffers. The second line says that 4.6 GB is free. This is the free memory in the first line with the addition of buffers and cache memory.
Linux has a habit of caching to improve performance so that memory can be freed and used when needed.
The last line is memory swap ( swap), which in this case is completely free.
2. /proc/meminfo
The next way to check memory usage is to read the /proc/meminfo file. Be aware that the /proc file system does not contain any real files. They are virtual files that contain dynamic information about the kernel and system.
$ cat /proc/meminfo MemTotal: 8167848 kB MemFree: 1409696 kB Buffers: 961452 kB Cached: 2347236 kB SwapCached: 0 kB Active: 3124752 kB Inactive: 2781308 kB Active(anon): 2603376 kB Inactive(anon): 309 056 kB Active( file): 521376 kB Inactive(file): 2472252 kB Unevictable: 5864 kB Mlocked: 5880 kB SwapTotal: 1998844 kB SwapFree: 1998844 kB Dirty: 7180 kB Writeback: 0 kB AnonPages: 2603272 kB Mapped: 788380 kB Shmem: 311596 kB Slab: 200468 kB SReclaimable: 151760 kB SUnreclaim: 48708 kB KernelStack: 6488 kB PageTables: 78592 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 6082768 kB Committed_AS: 9397536 kB VmallocTo tal: 34359738367 kB VmallocUsed: 420204 kB VmallocChunk: 34359311104 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 62464 kB DirectMap2M: 8316928 kB
Let's change Ubuntu's behavior regarding RAM usage and swap (swap partition). There is a parameter called vm.swappiness, which has a default value of 60, and controls the percentage of free memory at which active dumping of pages into the swap partition will begin. In other words, at 100-60=40% of occupied memory, Ubuntu will already start using the swap partition. At large quantities RAM in the computer, it is better to change the vm.swappiness parameter to 10 and thereby order Ubuntu not to use swap until the occupied RAM reaches 100-10=90%. Let's set the value to 10 instead of 60. In the console, enter the following command:
Echo 10 > /proc/sys/vm/swappiness
Sysctl -w vm.swappiness=10
To save the setting after a reboot, add the following line to the end of the /etc/sysctl.conf file:
Vm.swappiness=10
To immediately apply the setting:
Sysctl -p
In addition, we can talk about several more parameters.
The pseudo-file vfs_cache_pressure stores a value - the level of memory allocated for the cache. Default value: 100. Increasing this parameter causes the kernel to more actively dump unused memory pages from the cache, i.e. The amount of RAM allocated to the cache will grow more slowly, which in turn will reduce the likelihood that the swap partition will be used. By decreasing this parameter, the kernel, on the contrary, will keep memory pages in the cache longer, including in swap. This makes sense when there is a small amount of RAM, for example, if we have 512 MB of memory, then the vfs_cache_pressure parameter can be set to 50. This will reduce the number of disk operations in the swap partition, so removing unused pages will occur less frequently. Further reducing this parameter can lead to memory shortage.
If you want to speed up the system and you have enough RAM (2 GB or more), then change the system value like this: swappiness = 10, vfs_cache_pressure = 1000 (default 100), add the following line to the /etc/sysctl.conf file:
Vm.vfs_cache_pressure=1000
or on the fly:
Sysctl -w vm.vfs_cache_pressure=1000
Caching in Linux
When data is written to disk (by any program), Linux caches this information in an area of memory called Page Cache. Information about this memory area can be viewed using the free, vmstat or top commands. Full information You can see about this memory area in the /proc/meminfo file. Below is an example of this file on a server with 4 GB RAM:
MemTotal: 3950112 kB
MemFree: 622560 kB
Buffers: 78048 kB
Cached: 2901484 kB
SwapCached: 0 kB
Active: 3108012 kB
Inactive: 55296 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 3950112 kB
LowFree: 622560 kB
SwapTotal: 4198272 kB
SwapFree: 4198244 kB
Dirty: 416 kB
Writeback: 0 kB
Mapped: 999852 kB
Slab: 57104 kB
Committed_AS: 3340368 kB
PageTables: 6672 kB
VmallocTotal: 536870911 kB
VmallocUsed: 35300 kB
VmallocChunk: 536835611 kB
HugePages_Total: 0
HugePages_Free: 0
Hugepagesize: 2048 kB
The Page Cache size is shown in the "Cached" parameter, in this example it is 2.9 GB. As pages are written to memory, the size of the "Dirty" parameter increases. When you start writing to disk, the "Writeback" parameter will increase until the recording ends. It is quite difficult to see the "Writeback" parameter high, since its value only increases during polling, when input/output (I/O) operations are queued but not yet written to disk.
Linux typically writes cache data to disk using the pdflush process. At any moment, there are from 2 to 8 pdflush threads running on the system. In the file /proc/sys/vm/nr_pdflush_threads you can see how many at the moment active threads. Every time all existing pdflush threads are busy for at least 1 second. New threads try to write data to free device queues, so that for each active device there was 1 thread flushing data from the cache. Every time a second passes without any activity from pdflush, 1 thread is removed. In Linux, you can configure the minimum and maximum number of pdflush threads.
Setting up pdflush
Each pdflush thread is controlled by several parameters in /proc/sys/vm:
- /proc/sys/vm/dirty_writeback_centisecs (default 500): in hundredths of seconds. This setting indicates how often pdflush resumes to write data to disk. By default, 2 threads are resumed every 5 seconds.
There may be an undocumented behavior that thwarts attempts to reduce dirty_writeback_centisecs to allow the pdflush process to cache data more aggressively. For example, in early versions of the 2.6 Linux kernel, the mm/page-writeback.c file included logic that said "if disk writes take longer than the dirty_writeback_centisecs parameter, then set the interval to 1 second." This logic is described only in the kernel code, and its operation depends on the version of the Linux kernel. Since this is not very good, you will therefore be protected from reducing this parameter. - code>/proc/sys/vm/dirty_expire_centiseconds (default 3000): in hundredths of seconds. This parameter specifies how long data can remain in the cache before it must be written to disk. The default value is very long: 30 seconds. This means that when normal operation Until enough data has been written to the cache to call another pdflush method, Linux will not write data to disk that has been in the cache for less than 30 seconds.
- /proc/sys/vm/dirty_background_ratio (default 10): The maximum percentage of RAM that can be filled by the page cache before writing data to disk. Some versions of the Linux kernel may set this parameter to 5%.
Most documentation describes this parameter as a percentage of total RAM, but according to source codes The Linux kernel is not. Looking at meminfo, the dirty_background_ratio parameter is calculated from the value MemFree + Cached - Mapped. So for our demo system, 10% is a little less than 250MB, but not 400MB.
When does pdflush start recording?
In the default configuration, data written to disk remains in memory until:
If write operations occur frequently on the server, then one day the dirty_background_ratio parameter will be reached, and you will be able to see that all writes to the disk go only through this parameter without waiting for the dirty_expire_centiseconds parameter to expire.
Page writing process
The parameter /proc/sys/vm/dirty_ratio (default 40) is the maximum percentage of total RAM that can be allocated to the page cache before pdflush writes data to disk.
Note: While writing to disk, all writing processes are blocked, not just the one that has filled the write buffer. This can cause one process to block all I/O operations on the system.
Best practices for optimizing Linux for write-intensive operations
Usually, when trying to increase the performance of the disk subsystem, they encounter the problem that Linux buffers too much information at once. This is especially noticeable for operations that require file system synchronization using fsync calls. If during such a call there is a lot of data in the cache, then the system may freeze until this call ends.
Another common problem occurs because too much needs to be written before the physical disk is written to, causing I/O operations to occur more frequently than normal operation.
- dirty_background_ratio: Basic tuning tool. Usually this parameter is reduced. If your goal is to reduce the amount of data stored in the cache, so that data is written to disk gradually rather than all at once, then reducing this parameter is the most effective way. The default value is most suitable for systems with a lot of RAM and slow disks.
- dirty_ratio: The second most important parameter to configure. If this setting is significantly reduced, applications that need to write to disk will be blocked all together.
- dirty_expire_centisecs: Try reducing this parameter, but not too much. It allows you to reduce the time pages spend in the cache before being written to disk, but on the other hand, this will significantly reduce the average write speed to disk, which will be especially noticeable on systems with slow disks.
As a result we get
In the /etc/sysctl.conf file we add:
Vm.dirty_background_ratio = 10 vm.dirty_ratio = 40
Then we synchronize the cache and disk data, clear the cache and save the parameters:
Sync; echo 3 > /proc/sys/vm/drop_caches; sysctl -p
To reduce the number of disk write finalizations, you need to adjust:
Vm.dirty_writeback_centisecs = 15000
Like any other operating system,Linux is very efficient with RAM. Available memory is freely distributed between processes, unused pages are flushed to the swap partition on the disk, and in the event of memory overflow, a special mechanism built into the kernel is triggered, which analyzes all processes and destroys the culprit.
When any process writes data to disk, it is stored by the kernel in a separate cache. Very often this cache takes up quite a lot of space. In this article we will look at how to free up memory in Linux, or more precisely, how to clear the cache created by programs.
In every Linux distribution, you can use three commands to clear the Linux memory cache. Moreover, we do not have to complete any processes. These are the commands:
Clearing PageCache:
sync; echo 1 > /proc/sys/vm/drop_caches
Cleaning inode and dentrie:
sync; echo 2 > /proc/sys/vm/drop_caches
Cleaning inode and dentrie and PageCache:
sync; echo 3 > /proc/sys/vm/drop_caches
Before running any of these commands, run:
This is necessary because each command requires superuser rights to work. Now let's look at what happens when these commands are executed.
The sync utility forces the system to write all cached but not yet written data to disk. This is necessary to free up as much memory as possible. By default, data is not deleted from the cache after being written to disk; this is necessary so that the program can read it faster if necessary.
If we do not execute the sync command, we will also free up some space, but after executing it, the result will be better.
Symbol of division; tells the shell to wait until the first command completes before executing another command. The last command echo 1 > /proc/sys/vm/drop_caches writes the value 1 to the file /proc/sys/vm/drop_caches. This signals to the kernel that we need to clear the type of cache we have selected.
Types of cache in Linux
Now let's look at the types of caches that allow you to clear these commands, and how it all works.
PageCache or page cache is where the kernel puts all the data you wrote to or read from disk. This greatly speeds up the system, since if the program needs the same data a second time, it will simply be taken from RAM. But for this reason, this cache takes up the most space.
You can view the size of the page cache using the free utility. Here it is shown in the last column - cached:
This type of cache is the most efficient and safest to clear.
Inode and dentrie cache also applies to the file system. Only it is not the data itself that is written to it, but the structure of the file system, the location of files and folders. When asked for the location of a file or the contents of a folder, the kernel generates special structures that contain all this information. The next time the request is made, the structures will already be stored in memory. Each file system has its own inode cache and a shared dentrie cache.
This cache takes up very little memory. The data is presented in bytes, and as you can see, it is very small. You can view it with the command:
cat /proc/slabinfo | egrep dentry\|inode
Clearing it to free up Linux memory is not recommended, since little memory is consumed, and a new scan of the file system takes a relatively long time.
Do I need to clear the cache at all?
First, if there is a lot of memory being used, you may want to clear the page cache, especially if it is the page cache that is taking up a lot of memory. Secondly, you may need to clear the Linux memory cache if you have changed any file system or kernel settings, and now want to check how this affected the speed of read/write operations. In this case, you can clear all caches and do it without rebooting, which is very convenient.
The Linux operating system is designed in such a way that before accessing the disk, the disk cache will be looked at, and if the necessary data is there, the disk will not be accessed. If you clear the Linux cache, the operating system will run a little slower because it will have to look for data on the disk.
Automatic cache clearing
Let's look at how to automatically clear the memory cache every day at two in the morning using the cron job scheduler.
First let's create bash script with the following content:
sudo vi /usr/local/bin/clearcache.sh
sync ; echo 1 > /proc/sys/vm/drop_caches
We will only clear the page cache, since it takes up the most. We will not touch other types, so as not to needlessly reduce system performance.
sudo chmod 755 /usr/local/bin/clearcache.sh
All that remains is to add the task to the cron scheduler. To do this, run the command:
And in the editor that opens, add the line:
0 2 * * * /usr/local/bin/clearcache.sh
Now this script will run every night and clean up the memory so that the server can run normally.
Setting the memory cache size
It is much more convenient not to clear the cache every time, but to set a limit, if exceeded, the system itself will delete unnecessary pages. You cannot explicitly limit how many megabytes the system can use for cache. All available memory will be used as needed, but the rate at which expired pages are removed from the cache can be adjusted.
The file /proc/sys/vm/vfs_cache_pressure is responsible for this. It contains a relative measure of how aggressively you should remove pages from the cache. By default, the parameter is set to 100. If you reduce it, the kernel will delete pages less often and this will lead to a very rapid increase in the cache. If set to zero, pages will not be deleted at all. If the value is greater than 100, the cache size will grow more slowly and unused pages will be removed immediately.
For example, let's make the minimum cache size:
echo 1000 > /proc/sys/vm/vfs_cache_pressure
Don't forget that this will greatly reduce the performance of your system because data will be read from disk instead of cache.
How to clear swap memory
Clearing swap space is very easy. To do this, run:
swapoff -a && swapon -a
Keep in mind that when clearing swap, all data will be transferred back to RAM.
Conclusions
That's all. You already know how to clear the Linux cache and free up memory. Do not forget that all the commands given in this article must be executed as a superuser, otherwise nothing will work. If you have any questions, ask in the comments!
Related posts:
Recently at one of virtual servers I ran into a problem that took a long time to write to disk. And under this topic I found an interesting one, which discussed in detail the issue of how caching of disk write operations works in Linux. Today there will be a translation of this article.
Caching in Linux
When data is written to disk (by any program), Linux caches this information in an area of memory called Page Cache. Information about this memory area can be viewed using the commands free, vmstat or top. Full information about this memory area can be found in the file /proc/meminfo. Below is an example of this file on a server with 4 GB RAM:
MemTotal: 3950112 kB MemFree: 622560 kB Buffers: 78048 kB Cached: 2901484 kB SwapCached: 0 kB Active: 3108012 kB Inactive: 55296 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 3950112 kB LowFree: 62256 0 kB SwapTotal: 4198272 kB SwapFree: 4198244 kB Dirty: 416 kB Writeback: 0 kB Mapped: 999852 kB Slab: 57104 kB Committed_AS: 3340368 kB PageTables: 6672 kB VmallocTotal: 536870911 kB VmallocUsed: 35300 kB VmallocChunk 536835 611 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB
The Page Cache size is shown in the "Cached" parameter, in this example it is 2.9 GB. As pages are written to memory, the size of the "Dirty" parameter increases. When you start directly writing to the disk, the "Writeback" parameter will increase until the recording ends. It is quite difficult to see the "Writeback" parameter high, since its value only increases during polling, when input/output (I/O) operations are queued but not yet written to disk.
Linux typically writes data from the cache to disk using a process pdflush. At any moment there are from 2 to 8 threads running in the system pdflush. In file /proc/sys/vm/nr_pdflush_threads You can see how many active threads are currently active. Every time all existing pdflush threads are busy for at least 1 second. New threads try to write data to free device queues, so that for each active device there is 1 thread flushing data from the cache. Every time a second passes without any activity from pdflush, 1 thread is removed. In Linux, you can configure the minimum and maximum number of pdflush threads.
Setting up pdflush
Each pdflush stream is controlled by several parameters in /proc/sys/vm:
- /proc/sys/vm/dirty_writeback_centisecs(default 500): in hundredths of seconds. This setting indicates how often pdflush resumes to write data to disk. By default, 2 threads are resumed every 5 seconds.
There may be an undocumented behavior that thwarts attempts to reduce dirty_writeback_centisecs to allow the pdflush process to cache data more aggressively. For example, in early versions of the 2.6 Linux kernel, the mm/page-writeback.c file included logic that said "if disk writes take longer than the dirty_writeback_centisecs parameter, then set the interval to 1 second." This logic is described only in the kernel code, and its operation depends on the version of the Linux kernel. Since this is not very good, you will therefore be protected from reducing this parameter. - /proc/sys/vm/dirty_expire_centiseconds(default 3000): in hundredths of seconds. This parameter specifies how long data can remain in the cache before it must be written to disk. The default value is very long: 30 seconds. This means that during normal operation, until enough data has been written to the cache to call another pdflush method, Linux will not write data to disk that has been in the cache for less than 30 seconds.
- /proc/sys/vm/dirty_background_ratio(default 10): The maximum percentage of RAM that can be filled by the page cache before writing data to disk. Some versions of the Linux kernel may set this parameter to 5%.
Most documentation describes this setting as a percentage of total RAM, but according to the Linux kernel source code, this is not the case. Looking at meminfo, the parameter dirty_background_ratio is calculated from the value MemFree + Cached - Mapped. So for our demo system, 10% is a little less than 250MB, but not 400MB.
Total: When does pdflush start recording?
In the default configuration, data written to disk remains in memory until:
- they remain in memory for more than 30 seconds;
- cached pages occupy more than 10% of working memory.
If write operations occur frequently on the server, then one day the dirty_background_ratio parameter will be reached, and you will be able to see that all writes to the disk go only through this parameter without waiting for the dirty_expire_centiseconds parameter to expire.
Page writing process
Parameter /proc/sys/vm/dirty_ratio(default 40): The maximum percentage of total RAM that can be allocated to the page cache before pdflush writes data to disk.
Note: While writing to disk, all processes are blocked from writing, not just the one that has filled the write buffer. This can cause one process to block all I/O operations on the system. Carry out this
Recommendations for optimizing Linux for operations that require frequent recording
Typically, people when trying to increase the performance of the disk subsystem are faced with the problem that Linux buffers too much information at once. This is especially difficult for operations that require file system synchronization using fsync calls. If during such a call there is a lot of data in the cache, then the system may freeze until this call ends.
Another common problem occurs because too much needs to be written before writing to the physical disk begins; I/O operations occur more frequently than normal operation. You will get longer periods where no disk writes occur until the large cache is full, at which point one of the pdflush triggers will fire and the data will be written at maximum speed.
dirty_background_ratio: The main adjustment tool, usually reduce this parameter. If your goal is to reduce the amount of data stored in the cache, so that data is written to disk gradually rather than all at once, then reducing this parameter is the most effective way. The default value is more acceptable for systems with a lot of RAM and slow disks.
dirty_ratio: The second most important parameter to configure. If this setting is significantly reduced, applications that need to write to disk will be blocked all together.
dirty_expire_centisecs: Try to reduce it, but not much. Allows you to reduce the time pages spend in the cache before being written to disk, but this will significantly reduce the average write speed to disk, because it's less efficient. This will be especially noticeable on systems with slow disks.
Instructions for setting parameters
In file /etc/sysctl.conf We enter, for example:
Vm.dirty_background_ratio = 10 vm.dirty_ratio = 40
Then we synchronize the cache and disk data, clear the cache and save the settings.
Sync; echo 3 > /proc/sys/vm/drop_caches; sysctl -p
When it comes to performance optimization Linux systems, physical memory is the most important factor. Naturally, Linux offers many options to control the use of precious memory resources. Different tools vary in terms of their monitoring granularity (e.g. system-wide, per process, per user), interface (e.g. graphical, command line, ncurses) or mode of operation (e.g. interactive, batch mode).
Here is a partial list of programs with graphical interface or the command line so that you have plenty to choose from to check used and free memory on Linux platforms.
1. /proc/meminfo
The easiest way to check RAM usage is through /proc/meminfo. This dynamically updated virtual file is actually the source of display information for many other memory-related tools such as free, top and ps tools. From quantity available/ physical memory to the amount of buffer expected to be written back to disk, /proc/meminfo has everything you want to know about usage system memory. Process memory information is also available from /proc/
$ cat /proc/meminfo
2. atop
The atop command is an ncurses-based interactive system and process observer for the terminal environment. It shows dynamically updated summary information about system sources (CPU, memory, network, I/O, kernel) with color-coded warnings in case high load systems. It can also sort processes (or users) in order of their highest resource consumption, so that system administrator can tell which process or user is responsible for booting the system. Memory statistics reports include total/free memory, cached/buffered memory, and memory information. virtual memory.
$ sudo atop
3.free
The free command is a quick and easy way to get an overview of memory usage gleaned from /proc/meminfo. It shows a snapshot of the total/available physical memory and system swap as well as used/free buffer space in the kernel.
4. GNOME System Monitor
GNOME System Monitor is graphic application which is shown a short history use system resources for CPU, memory, swap space and network. It also offers a monitoring process for CPU and memory usage.
$gnome-system-monitor
5.htop
The htop command is an ncurses-based interactive process viewer that shows memory usage by process in real time. It can report the process's memory footprint in main memory (RSS), total program size in memory, library size, total page size, and dirty page size (in cache) for all running processes. You can scroll horizontally or vertically through the (sorted) list of all processes.
6. KDE System Monitor
While the GNOME desktop has the GNOME System Monitor, the KDE desktop has its own counterpart: the KDE System Monitor. Its functionality is mainly similar to the GNOME version, i.e. Shows real-time history of system resource usage, as well as CPU/memory consumption of individual processes.
$ksysguard
7. memstat
The memstat utility is useful for identifying which executable process(es) and shared libraries are consuming virtual memory. By obtaining the process ID, memstat reveals how much virtual memory is used by the executable code, data, and shared libraries associated with that process.
$ memstat -p
8.nmon
The nmon utility is an ncurses-based system benchmark tool that monitors the CPU, memory, disk I/O, kernel, file system and online sources. Based on memory usage, it can show information such as total/free memory, swap space, buffered/cached memory, loaded/unloaded virtual memory statistics, all in real time.
9.ps
The ps command can show memory usage of individual processes in real time. Memory usage information displayed includes %MEM (percentage of physical memory used), VSZ (total amount of virtual memory used), and RSS (total amount of physical memory used). You can sort the list of processes using the "–sort" option. For example, to sort in descending RSS order:
$ ps aux --sort -rss
10. smem
The smem command allows you to measure the physical memory usage of various processes and users based on information available from /proc. This utility uses the Proportional Set Size (PSS) metric to accurately estimate Linux processes' effective memory usage. Memory usage analysis can be exported to graphical bar and slice charts.
$ sudo smem --pie name -c "pss"
11.top
The top command offers real-time monitoring of running processes along with various process statistics regarding resource usage. Memory-related information includes %MEM (percentage of memory used), VIRT (total amount of virtual memory used), SWAP (amount of swapped virtual memory), CODE (amount of physical memory allocated for code execution), DATA (amount of physical memory allocated for non-execution). -executable data), RES (total amount of physical memory used, CODE+DATA) and SHR (amount of memory potentially shared with other processes). You can sort the list of processes based on memory usage or size.
12.vmstat
The vmstat command line utility displays immediate and average statistics for various system activities, including CPU, memory, interrupts, and disk I/O. As a source of memory information, this command shows not only physical memory usage (eg, total/used memory and memory buffer/cache), but also virtual memory statistics (eg, pages loaded/paged memory, paged/loaded).
The vmstat command-line utility displays instantaneous and average statistics of various system activities covering CPU, memory, interrupts, and disk I/O. As for memory information, the command shows not only physical memory usage (e.g., tota/used memory and buffer/cache memory), but also virtual memory statistics (e.g., memory paged in/out, swapped in/out).
$ vmstat -s
