为什么swappiness默认设置为60?

Hug*_*ugo 120 linux kernel swap

我刚刚在 Linux 上阅读了一些关于 swappiness 的东西。我不明白为什么默认设置为 60。

根据我的说法,这个参数应该设置为 10 以减少交换。交换在我的硬盘上,所以它比我的记忆慢得多。

他们为什么要这样配置内核?

Tho*_*man 146

从内核 2.6.28 开始,Linux 使用拆分最近最少使用(LRU) 页面替换策略。具有文件系统源(例如程序文本或共享库)的页面属于文件缓存。没有文件系统支持的页面称为匿名页面,由运行时数据组成,例如为应用程序保留的堆栈空间等。通常属于文件缓存的页面从内存中驱逐的成本更低(因为这些可以在需要时从磁盘中简单地读回) . 由于匿名页面没有文件系统支持,只要程序需要它们,它们就必须保留在内存中,除非有交换空间来存储它们。

一个常见的误解是交换分区会以某种方式减慢您的系统速度。没有交换分区并不意味着内核不会从内存中驱逐页面,这只是意味着内核在驱逐哪些页面方面的选择较少。可用的交换量不会影响它的使用量。

Linux 可以应付没有交换空间的情况,因为默认情况下,内核内存记帐策略可能会过度使用内存。缺点是当物理内存耗尽,内核无法将匿名页面交换到磁盘时,内存不足杀手(OOM-killer)机制将开始杀死占用内存的“流氓”进程以释放内存其他过程。

vm.swappiness选项是一个修饰符,用于更改换出文件缓存页面以支持匿名页面之间的平衡。文件缓存被赋予任意优先级值 200,从中vm.swappiness扣除修饰符 ( file_prio=200-vm.swappiness)。默认情况下,匿名页面以 60 ( anon_prio=vm.swappiness)开头。这意味着,默认情况下,优先权重适度支持匿名页面 ( anon_prio=60, file_prio=200-60=140)。该行为mm/vmscan.c在内核源代码树中定义。

给定vm.swappiness100,优先级将等于(file_prio=200-100=100anon_prio=100)。如果不希望文件缓存中的页面被逐出以支持匿名页面,这对于 I/O 繁重的系统来说是有意义的。

相反vm.swappiness0将设置为将阻止内核从文件缓存中驱逐匿名页面以支持页面。如果程序自己进行大部分缓存,这可能很有用,某些数据库可能就是这种情况。在桌面系统中,这可能会提高交互性,但缺点是 I/O 性能可能会受到影响。

默认值很可能被选为这两个极端之间的近似中间值。与任何性能参数一样,调整vm.swappiness应基于与实际工作负载相当的基准数据,而不仅仅是直觉。

  • 在固态设备上安装操作系统如何影响权衡? (5认同)
  • @gerrit 底层存储介质的类型无关紧要。这种细节对内存管理子系统是不可见的。 (4认同)
  • @MatrixManAtYrService 由于内部磨损均衡和内置冗余,现代 SSD(上一条评论中的问题所指)[已显示持续高达 2 PB (!)](https://techreport.com/ review/27909/the-ssd-endurance-experiment-theyre-all-dead) 在出现错误之前写入。在这些实验中,即使是更便宜的驱动器在发生错误之前也能持续 300TB,远远超出大约 100TB 的官方保修等级。至少在我看来,调整 swappiness 以适应工作站或笔记本电脑上的 SSD 并不是真正有保证的。 (4认同)
  • @ThomasNyman 你说得很好,对于大多数用户来说,这不值得担心。把我带到这篇文章的案例涉及 SD 卡上的交换空间,我认为这是一个边缘案例。 (3认同)

小智 9

问题是没有一个默认值可以满足所有需求。将 swappiness 选项设置为 10 可能是桌面的合适设置,但默认值 60 可能更适合服务器。换句话说,swappiness 需要根据用例进行调整 - 桌面与服务器、应用程序类型等。

此外,Linux 内核将内存用于磁盘缓存,否则不会使用 RAM,这既不高效也不符合预期。缓存中的磁盘数据意味着如果某些东西再次需要相同的数据,它可能会从内存中获取它。从那里获取数据比再次从磁盘获取数据要快得多。而 swappiness 选项是一种机制,Linux 内核更喜欢换出到磁盘而不是缩小磁盘缓存。它应该从缓存中删除旧数据还是应该换出一些程序页面?

这篇文章也可能对这个话题有所了解。特别是,如何估计交换趋势。

  • 如果不太可能访问它们,那么将部分内存移动到交换区是有意义的,这样 Linux 会尽可能多地保留实际 ram 的可用空间,以便为实际需要的情况做好准备。 (7认同)
  • 我不明白为什么60更适合服务器。即使我们有 40% 的空闲 RAM,我也确实有服务器和一些进程进行交换。对我来说没有意义。 (2认同)

小智 5

在上面的答案中添加更多细节。
随着我们越来越多地使用 VM,Linux 主机可能是这些云环境之一上的 vm。在示例 1 和 2 中,我们对正在运行的应用程序以及它们消耗了多少 RAM 有了很好的了解。3、没那么多

  • 示例 1
    一个高性能私有云(想想大多数银行会支付数百万美元的那种),其中磁盘由非常昂贵的存储阵列提供,并且具有非常好的 IO。该存储的一部分可能位于由 SSD 磁盘支持的 RAM(在磁盘阵列中)中,由带有主轴的常规磁盘支持。在这种情况下,VM 看到的磁盘可能只比它可以访问的 RAM 慢一点。对于单个 vm,swap 和 ram 之间没有太大区别。
  • 示例 2
    与示例 1 相同,但您有数百、数千或更多的虚拟机,而不是单个虚拟机。在这种情况下,我们发现服务器(管理程序)RAM 便宜且充足,而存储 RAM 昂贵(相对而言)。如果我们在 Hypervisor RAM 和由我们非常昂贵的存储阵列提供的 SWAP 之间拆分 RAM 需求,我们会发现我们很快使用了存储阵列中的所有 RAM,然后块由 SSD 提供服务,最后由主轴提供服务。突然,每一个都开始变得非常缓慢。在这种情况下,我们可能希望为 VM 分配大量 RAM(来自管理程序)并将 swappiness 设置为 0(仅交换以避免内存不足情况),因为所有这些 vm 的累积效应将对性能产生影响存储,
  • 示例 3 可能带有 SSD 的现代笔记本电脑或台式机。内存要求被认为是未知的。用户将使用哪个浏览器,他们将打开多少个选项卡,他们是否还在编辑文档、RAW 图像或可能的视频,它们都将消耗 RAM。将 swappiness 设置为低值并执行其他文件系统调整将意味着对 SSD 的写入更少,因此它会持续更长时间。

  • 最终用户系统的 SSD 写入耐久性问题被高估了。现代 SSD 通常可以承受数百 TB 的写入量。一个典型的桌面系统即使有大量的交换使用,也不太可能在多年的运行中使用那么多。 (5认同)