vm/min_free_kbytes - 为啥要保留最小保留内存?
Posted
技术标签:
【中文标题】vm/min_free_kbytes - 为啥要保留最小保留内存?【英文标题】:vm/min_free_kbytes - Why Keep Minimum Reserved Memory?vm/min_free_kbytes - 为什么要保留最小保留内存? 【发布时间】:2014-02-17 21:58:32 【问题描述】:据此article:
/proc/sys/vm/min_free_kbytes:这控制了由特殊保留使用的内存量,包括“原子”分配(那些不能等待回收的)
我的问题是“那些不能等待回收的人”是什么意思?换句话说,我想了解为什么需要告诉系统始终保持一定的最小可用内存量以及在什么情况下会使用这些内存? [它必须被某物使用;否则没有必要]
我的第二个问题:将此内存设置为高于 4MB(在我的系统上)是否会带来更好的性能?当某些进程开始运行时,我们的服务器偶尔会表现出非常差的 shell 性能(例如 ls -l 需要 10-15 秒才能执行),如果将此数字设置为更高的值会导致更好的 shell 性能?
【问题讨论】:
【参考方案1】:(链接失效,现在好像是here)
该文本指的是原子分配,即必须在不放弃控制的情况下满足内存请求(即当前线程不能暂停)。这最常发生在中断例程中,但它适用于所有需要内存同时持有必要锁的情况。这些分配必须是即时的,因为您不能等待交换器释放内存。
更详尽的解释见Linux-MM,这里简单说一下内存分配过程:
_alloc_pages 首先遍历每个内存区域,寻找第一个包含符合条件的空闲页面的内存区域 _alloc_pages 然后唤醒 kswapd 任务 [..to..] 进入为每个区域维护的保留内存池。 如果内存分配仍然不成功,_alloc 页面要么放弃 [..] 在这个过程中 _alloc_pages 执行一个 cond_resched() 可能导致睡眠,这就是为什么这个分支被禁止分配GFP_ATOMIC。
min_free_kbytes 不太可能对描述的“ls -l 执行需要 10-15 秒”有太大帮助;这可能是由一般内存压力和交换而不是区域耗尽引起的。 min_free_kbytes 设置只需要允许足够的空闲页面来处理即时请求。一旦恢复正常操作,就可以运行交换进程来重新平衡内存区域。唯一一次我不得不增加 min_free_kbytes 是在不支持 dma 散射的网卡上启用巨型帧之后。
稍微扩展您的第二个问题,调整 vm.swappiness 和链接文章中提到的脏比率会有更好的结果。但是,请注意优化“ls -l”性能可能会导致其他进程变慢。永远不要针对非主要用例进行优化。
【讨论】:
链接再次失效(重定向到主页)。 由于我无法发表评论,这里是问题中提到的页面的更新链接的更新链接的更新链接和顶部回复:-doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/… 当几乎所有的内存都被占用并且没有可用的交换空间时,Linux 性能对我来说往往会跌落悬崖(以至于到达 TTY1 以杀死 Firefox 需要 15 分钟);将/proc/sys/vm/vfs_cache_pressure
提高到 6000(默认为 100)似乎有助于防止这种情况。但是,我不会在生产服务器上这样做。内核文档警告说“将 vfs_cache_pressure 显着提高到超过 100 可能会对性能产生负面影响。”
@Hitechcomputergeek 你可以通过实验尝试this kernel patch(只要你确定你的交换被禁用)只是看看15分钟的事情是否减少到1-2秒,或者实际上看看是否当你内存不足时,Firefox 会在 2 秒内自动终止 OOM。【参考方案2】:
所有 linux 系统都会尝试利用系统可用的所有物理内存,通常是通过创建文件系统缓冲区缓存,简单地说就是一个 I/O 缓冲区,以帮助提高系统性能。从技术上讲,该内存没有在使用中,即使它被分配用于缓存。
在您的问题中,“等待回收”是指回收“未使用”的缓存内存以便将其分配给进程的过程。这应该是透明的,但在现实世界中,有许多进程不会等待此内存可用。 Java 是一个很好的例子,尤其是在设置了较大的最小堆大小的情况下。该进程尝试分配内存,如果它不能立即在一个大的连续(原子?)块中可用,则该进程终止。
使用min_free_kbytes
保留一定数量的内存可以使该内存立即可用,并在新进程需要启动、运行和完成而内存负载很高且缓冲区缓存已满时降低内存压力。
4MB 看起来确实很低,因为如果缓冲区缓存已满,任何想要立即分配超过 4MB 的进程都可能会失败。该设置非常可调且特定于系统,但如果您有几 GB 的可用内存,将保留内存增加到 128MB 也无妨。我不确定它会对 shell 交互性产生什么影响,但可能是积极的。
【讨论】:
【参考方案3】:此内存不会被正常进程使用。正如@Arno 提到的,可以运行的特殊进程包括中断例程,它必须现在运行(因为它是一个中断),并且在任何其他进程可以运行(原子)之前完成。这可以包括在内存已满时将内存换出到磁盘之类的事情。
如果内存已满,则会运行一个中断(内存管理)进程以将一些内存交换到磁盘中,以便它可以释放一些内存以供正常进程使用。但是如果vm.min_free_kbytes
太小而无法运行,那么它会锁定系统。这是因为此中断进程必须首先运行以释放内存以便其他进程可以运行,但随后它被卡住了,因为它没有足够的保留内存vm.min_free_kbytes
来执行其任务,从而导致死锁。
另见:
https://www.linbit.com/en/kernel-min_free_kbytes/ 和 https://askubuntu.com/questions/41778/computer-freezing-on-almost-full-ram-possibly-disk-cache-problem(内存管理进程只有很少的内存可以使用,需要很长时间才能一点一点地交换,感觉就像冻结一样。)【讨论】:
以上是关于vm/min_free_kbytes - 为啥要保留最小保留内存?的主要内容,如果未能解决你的问题,请参考以下文章