Linux vm/min_free_kbytes - 为什么要保持最小保留内存?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/21374491/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
vm/min_free_kbytes - Why Keep Minimum Reserved Memory?
提问by user3063877
According to this article:
根据这篇文章:
/proc/sys/vm/min_free_kbytes: This controls the amount of memory that is kept free for use by special reserves including “atomic” allocations (those which cannot wait for reclaim)
/proc/sys/vm/min_free_kbytes:这控制了保持空闲以供特殊保留使用的内存量,包括“原子”分配(那些不能等待回收的)
My question is that what does it mean by "those which cannot wait for reclaim"? In other words, I would like to understand why there's a need to tell the system to always keep a certain minimum amount of memory free and under what circumstances will this memory be used? [It must be used by something; don't see the need otherwise]
我的问题是“那些不能等待回收的人”是什么意思?换句话说,我想了解为什么需要告诉系统始终保持一定的最小内存空闲量,在什么情况下会使用这些内存?[它必须被某物使用;否则看不到需要]
My second question: does setting this memory to something higher than 4MB (on my system) leads to better performance? We have a server which occasionally exhibit very poor shell performance (e.g. ls -l takes 10-15 seconds to execute) when certain processes get going and if setting this number to something higher will lead to better shell performance?
我的第二个问题:将此内存设置为高于 4MB(在我的系统上)会导致更好的性能吗?我们有一个服务器,当某些进程开始运行时,它偶尔会表现出非常差的 shell 性能(例如 ls -l 需要 10-15 秒来执行),如果将此数字设置为更高的值会导致更好的 shell 性能?
回答by Shaun Dewberry
All linux systems will attempt to make use of all physical memory available to the system, often through the creation of a filesystem buffer cache, which put simply is an I/O buffer to help improve system performance. Technically this memory is notin use, even though it is allocated for caching.
所有 linux 系统都会尝试利用系统可用的所有物理内存,通常通过创建文件系统缓冲区缓存,简单地说就是一个 I/O 缓冲区,以帮助提高系统性能。从技术上讲,这个内存没有被使用,即使它被分配用于缓存。
"wait for reclaim", in your question, refers to the process of reclaiming that cache memory that is "not in use" so that it can be allocated to a process. This is supposed to be transparent but in the real world there are many processes that do not wait for this memory to become available. Java is a good example, especially where a large minimum heap size has been set. The process tries to allocate the memory and if it is not instantly available in one large contiguous (atomic?) chunk, the process dies.
在您的问题中,“等待回收”是指回收“未使用”的缓存内存以便将其分配给进程的过程。这应该是透明的,但在现实世界中,有许多进程不等待此内存可用。Java 就是一个很好的例子,尤其是在设置了很大的最小堆大小的情况下。该进程尝试分配内存,如果它不能在一个大的连续(原子?)块中立即可用,则该进程将终止。
Reserving a certain amount of memory with min_free_kbytes
allows this memory to be instantly available and reduces the memory pressure when new processes need to start, run and finish while there is a high memory load and a full buffer cache.
保留一定数量的内存min_free_kbytes
允许该内存立即可用,并在新进程需要启动、运行和完成时降低内存压力,同时存在高内存负载和完整的缓冲区缓存。
4MB does seem rather low because if the buffer cache is full, any process that wants an immediate allocation of more than 4MB will likely fail. The setting is verytunable and system-specific, but if you have a few GB of memory available it can't hurt to bump up the reserve memory to 128MB. I'm not sure what effect it will have on shell interactivity, but likely positive.
4MB 看起来确实很低,因为如果缓冲区缓存已满,任何想要立即分配超过 4MB 的进程都可能会失败。该设置非常可调且特定于系统,但如果您有几 GB 的可用内存,则将保留内存增加到 128MB 不会有什么坏处。我不确定它会对 shell 交互性产生什么影响,但可能是积极的。
回答by Arno
(link is dead, looks like it's now here)
(链接已失效,看起来现在在这里)
That text is referring to atomic allocations, which are requests for memory that must be satisfied without giving up control (i.e. the current thread can not be suspended). This happens most often in interrupt routines, but it applies to all cases where memory is needed while holding an essential lock. These allocations must be immediate, as you can't afford to wait for the swapper to free up memory.
该文本指的是原子分配,即必须在不放弃控制的情况下满足内存请求(即当前线程不能挂起)。这种情况最常发生在中断例程中,但它适用于所有需要内存同时持有基本锁的情况。这些分配必须是即时的,因为您不能等待交换器释放内存。
See Linux-MMfor a more thorough explanation, but here is the memory allocation process in short:
请参阅Linux-MM以获得更详尽的解释,但这里是内存分配过程的简短说明:
- _alloc_pages first iterates over each memory zone looking for the first one that contains eligible free pages
- _alloc_pages then wakes up the kswapd task [..to..] tap into the reserve memory pools maintained for each zone.
- If the memory allocation still does not succeed, _alloc pages will either give up [..] In this process _alloc_pages executes a cond_resched() which may cause a sleep, which is why this branch is forbidden to allocations with GFP_ATOMIC.
- _alloc_pages 首先遍历每个内存区域,寻找第一个包含合格空闲页面的内存区域
- _alloc_pages 然后唤醒 kswapd 任务 [..to..] 进入为每个区域维护的保留内存池。
- 如果内存分配仍然不成功,_alloc 页面要么放弃 [..]在这个过程中 _alloc_pages 执行 cond_resched() 这可能会导致睡眠,这就是为什么这个分支被禁止使用 GFP_ATOMIC 分配。
min_free_kbytes is unlikely to help much with the described "ls -l takes 10-15 seconds to execute"; that is likely caused by general memory pressure and swapping rather than zone exhaustion. The min_free_kbytes setting only needs to allow enough free pages to handle immediate requests. As soon as normal operation is resumed, the swapper process can be run to rebalance the memory zones. The only time I've had to increase min_free_kbytes is after enabling jumbo frames on a network card that didn't support dma scattering.
min_free_kbytes 不太可能对描述的“ls -l 需要 10-15 秒执行”有太大帮助;这可能是由一般内存压力和交换而不是区域耗尽引起的。min_free_kbytes 设置只需要允许足够的空闲页面来处理即时请求。一旦恢复正常操作,就可以运行交换进程以重新平衡内存区域。我唯一一次必须增加 min_free_kbytes 是在不支持 dma 散射的网卡上启用巨型帧之后。
To expand on your second question a bit, you will have better results tuning vm.swappiness and the dirty ratios mentioned in the linked article. However, be aware that optimizing for "ls -l" performance may cause other processes to become slower. Never optimize for a non-primary usecase.
为了稍微扩展您的第二个问题,您将获得更好的结果,调整 vm.swappiness 和链接文章中提到的脏比率。但是,请注意优化“ls -l”性能可能会导致其他进程变慢。永远不要针对非主要用例进行优化。
回答by pd12
This memory is kept free from use by normal processes. As @Arno mentioned, the special processes that can run include interrupt routines, which must be run now (as it's an interrupt), and finish before any other processes can run (atomic). This can include things like swapping out memory to disk when memory is full.
该内存不会被正常进程使用。正如@Arno 提到的,可以运行的特殊进程包括中断例程,它必须立即运行(因为它是一个中断),并在任何其他进程可以运行(原子)之前完成。这可能包括诸如在内存已满时将内存换出到磁盘之类的事情。
If the memory is filled an interrupt (memory management) process runs to swap some memory into disk so it can free some memory for use by normal processes. But if vm.min_free_kbytes
is too small for it to run, then it locks up the system. This is because this interrupt process must run first to free memory so others can run, but then it's stuck because it doesn't have enough reserved memory vm.min_free_kbytes
to do its task resulting in a deadlock.
如果内存已满,则会运行一个中断(内存管理)进程将一些内存交换到磁盘中,以便它可以释放一些内存供正常进程使用。但是如果vm.min_free_kbytes
它太小而无法运行,那么它就会锁定系统。这是因为这个中断进程必须首先运行以释放内存以便其他人可以运行,但随后它被卡住了,因为它没有足够的保留内存vm.min_free_kbytes
来完成它的任务,从而导致死锁。
Also see:
另见:
- https://www.linbit.com/en/kernel-min_free_kbytes/and
- https://askubuntu.com/questions/41778/computer-freezing-on-almost-full-ram-possibly-disk-cache-problem(where the memory management process has so little memory to work with it takes so long to swap little by little that it feels like a freeze.)
- https://www.linbit.com/en/kernel-min_free_kbytes/和
- https://askubuntu.com/questions/41778/computer-freezing-on-almost-full-ram-possively-disk-cache-problem(其中内存管理进程的内存很少,需要很长时间来交换一点一点地感觉像冻结了。)