为什么讨论“ swappiness”像信息这样的行为一次只能在一个地方?

StackOverflow https://stackoverflow.com/questions/147125

我一直在读Linux的“swappiness”。 tuneable,它控制内核在不使用时将应用程序的内存交换到磁盘的积极程度。如果您使用Google这个词,那么您会收到很多页面,例如这个讨论利弊。简而言之,这个论点是这样的:

  

如果你的swappiness太低,非活动应用程序将占用其他程序可能想要使用的所有系统内存。

     

如果你的swappiness太高,当你唤醒那些不活跃的应用程序时,会有一个很大的延迟,因为他们的状态被从磁盘上读回来。

这个论点对我来说没有意义。如果我有一个使用大量内存的非活动应用程序,为什么内核不将其内存分页到磁盘并在内存中留下该数据的另一个副本?这似乎是两个世界中最好的:如果另一个应用程序需要该内存,它可以立即声明物理RAM并开始写入它,因为它的另一个副本在磁盘上,并且可以在非活动应用程序被唤醒时交换回来起来。当原始应用程序唤醒时,仍然在RAM中的任何页面都可以按原样使用,而不必将它们从磁盘中取出。

或者我错过了什么?

有帮助吗?

解决方案

根据这个 1 ,这正是Linux的内容确实

我仍然试图弄清楚这一点,所以任何权威的链接都会受到赞赏。

其他提示

  

如果我有一个使用大量内存的非活动应用程序,为什么内核不将其内存分页到磁盘并将该数据的另一个副本留在内存中?

让我们说我们做到了。我们将页面写入磁盘,但将其保留在内存中。不久之后,另一个进程需要内存,因此我们希望从第一个进程中踢出页面。

我们需要绝对肯定地知道第一个进程是否已经写入磁盘后修改了页面。如果有,我们必须再次写出来。我们跟踪这个的方法是在我们第一次将其写入磁盘时取消该进程对页面的写入权限。如果进程再次尝试写入页面,则会出现页面错误。内核可以注意到,在恢复写入权限并允许应用程序继续之前,该进程已经弄脏了页面(因此需要再次写出)。

存在问题。从页面中取走写入权限实际上有点昂贵,特别是在多处理器机器中。重要的是所有CPU都清除其页面翻译缓存,以确保它们取消写入权限。

如果进程写入页面,则发生页面错误会更加昂贵。我认为这些页面中的一小部分会最终导致这种错误,这会将它留在内存中,从而影响我们所寻求的收益。

值得做什么?我老实说不知道。我只是试图解释为什么将页面留在内存中并不是听起来那么明显。

(*)这整个过程非常类似于一个名为Copy-On-Write的机制,它在进程fork()时使用。子进程很可能只执行一些指令并调用exec(),因此复制所有父页面是愚蠢的。取而代之的是写入权限被取消,孩子只是被允许运行。 Copy-On-Write是一个胜利,因为几乎从不采取页面错误:孩子几乎总是立即调用exec()。

即使您将应用程序内存分页到磁盘并将其保存在内存中,您仍然需要决定何时将应用程序视为“非活动”。这就是交换控制。就IO而言,分页到磁盘的成本很高,而且您不希望经常这样做。这个等式上还有另一个变量,那就是Linux将剩余内存用作磁盘缓冲区/缓存的事实。

VM做的第一件事就是清理页面并将它们移动到干净的列表中 清理匿名内存时(没有实际文件后备存储的东西,你可以看到/ proc //中的段是匿名的,并且后面没有文件系统vnode存储),VM要做的第一件事就是采取“脏”的页面和“清洁”然后通过写出页面的内容来交换。现在当虚拟机缺少完全可用内存并且担心它能够使用新的免费页面时,它可以通过“干净”页面列表并根据它们最近的使用时间和内存类型来查看他们会将这些页面移动到空闲列表中。

将内存页面放在空闲列表中后,它们就不再与之前的内容相关联。如果一个程序出现了一个引用该页面之前服务的内存位置,那么程序将会出现一个主要错误,并且将从空闲列表中抓取(很可能完全不同的)页面,并且数据将从磁盘读入页面。一旦完成,页面实际上仍然是“干净的”,因为它尚未被修改。如果VM选择在交换中将该页面用于RAM中的不同页面,那么该页面将再次被“弄脏”,或者如果应用程序写入该页面则会“脏”。然后这个过程再次开始。

此外,对于业务/事务/在线/延迟敏感环境中的服务器应用程序,swappinness非常糟糕。当我有16GB的RAM盒子,我没有运行很多浏览器和GUI时,我通常希望我的所有应用程序几乎都固定在内存中。我的大部分RAM往往是8-10GB的Java堆,我从不想要分页到磁盘,而且可用的琐事是像mingetty这样的过程(但即使那些应用程序中的glibc页面也是如此)由其他应用程序共享并实际使用,因此即使这些无用进程的RSS大小大多是共享的,已用过的页面)。我通常看不到超过几十个16GB的16GB实际上已经清理掉了。我会建议非常非常低的swappiness数或服务器的零吞吐量 - 未使用的页面应该是整个RAM的一小部分,并试图回收相对少量的RAM缓冲区缓存风险交换应用程序页面并考虑延迟命中正在运行的应用程序。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top