对Varnish服务器上的各种Linux命令的影响

有趣的问题！

作为参考，来自VM子系统作者的这个页面会给你一个好主意，可能发生什么;

http://linux-mm.org/PageReplacementDesign

请注意，这实际上很难回答它当前的forms（如果你正在谈论文件支持的caching），因为它依赖于caching的热度，caching项目的时间以及caching中每个对象的“热度” 。

假设如下：

• caching由10G文件支持，并已完全填充。
• caching中3％的对象占所有命中的90％。
• 在任何给定的时间，您都有大约80个处理连接的并发。
• 您尚未从默认值更改您的VM策略。
• 在命令之前，页面caching几乎几乎完全被你的清漆caching中的页面填满。
• 500M的数据专门分配给系统上运行的其他内容的匿名页面。

由于你的清漆caching大小是10G，它永远不会完全适合内存，因此下面的公式是比较有代表性的

• 有3500M的页面caching。
• 最热的1750Mb的清漆caching处于“活动”列表中，并且不受pagecache驱逐的影响。
• 清漆caching冷却器1750Mb处于“不活动”列表，不受驱逐保护。
• 清漆高速caching中最冷的6500Mb不驻留在内存中，并位于某处的磁盘上。

所以，以下可能是你运行的所有命令的结果。

1. 该文件被放入内存并进行caching，但默认情况下，caching中的所有新对象都将被发送到“不活动”列表。
2. 这会从清漆caching中清除1750MB的“冷却器/不活动”内存，并将其replace为捕获的文件。
3. 内核现在被迫将1750M的数据写回磁盘（在绝对最坏的情况下）。
4. IO等待和设备使用率受到打击，因为您正在读取一个2G文件并写出一个1750M文件。
5. 97％的入站请求不受此影响，因为他们想要在页面caching的活动部分中最热的1750Mb的清漆数据！
6. 3％的不幸的客户想要更酷的caching中的数据。 这些人现在看到了一个延迟，因为磁盘利用率已经很高了，他们正在排队等待将页面重新取回到页面caching！ 由于捕获的文件永远不会被重新读取足够快的页面caching驱逐那些页面，有利于3％的客户端需要一些较冷的数据。

这是绝对最坏的情况。 所以，从广义上说，这个影响是什么？

97％的服务请求没有可忽略的影响。

在受影响的3％中，预计服务时间会有更长的延迟 – 大概是500毫秒。

但是不幸的是，其中2％左右的不幸请求的3％本来会很慢，因为他们想从6500Mb的高速caching中find一些永远不在pagecache中的东西！ 但是他们现在却遭受了高磁盘利用率的困扰。

所以，总而言之，就我所做的假设而言，你会看到广义的效率损失3％。 （100％的效率将是每个请求的所有对象都在内存之外）。

在这个人为的例子中，“正常”运行效率约为98％。

对不适合内存的caching不坏！

答案取决于您的caching使用的存储后端。

如果您已将清漆configuration为使用基于文件的存储，则您的文件操作可能会影响性能。

在一个具有4个RAM的专用系统上，我build议你使用“malloc”，大小约为3 GB，作为caching的存储空间。

请参阅： https ： //www.varnish-cache.org/docs/trunk/users-guide/storage-backends.html