我希望find一些好的方法（通过查看/ proc）或者我可以用来确定磁盘caching的有效性的好工具。 我希望能够确定在磁盘caching中使用的RAM有多less正在被使用。 我希望更好地了解磁盘caching的使用情况，以便我可以更准确地为将来的服务器购买内存。
理想情况下，我希望看到的东西（虽然我不期待这个详细程度）会是这样的一些报告（或者自己做这个报告的方法）：
1.4GB of RAM is used in the disk cache which is used for 10 IO requests per second 2.3GB of RAM "" "" for 2 requests per second 5.3GB of RAM "" "" is basically never used 我不认为有可能收集这样的信息。 内存不是真的用来处理请求。 可能只有一个请求在内存中映射页面，然后可能会长时间保持使用状态，系统不知道使用了多less，除了周期性探测寻找过时的内存。
另外，请求背后的推理是错误的。 即使绝大部分的caching从未被使用过，所使用的部分的命中率仍然取决于你有多lesscaching。
让我给你比喻。 假设有20种不同的球，你可以保留18个库存。 如果你随机caching，有18/20的机会，你会有人需要的球存货。 所以如果有人问你一个特定的球，并有库存，只有1/18的球会被使用。 但是你有18/20的机会拿到那个球，因为另外17个球坐在那儿没用。
所以用于服务请求的数量并不是真正的衡量标准。
系统并没有真正保留足够的信息，以便让您能够弄清楚如果caching大小不同，caching的效果会如何。
更新 ：让我再试一次来解释为什么这不起作用。 你试图从5GB内存被用于没有被访问的caching的事实推断出，如果系统的内存less了5GB，那么系统的性能大致相同。 但是这完全是错误的。
假设你经营一家书店。 你注意到在一个特定的月份里，你只能卖出10％的库存。 你会这样想：“真是太浪费了，我书里90％的东西都坐在那儿没用，我不需要保存那么多的库存。 所以你减less了90％的库存。 你认为会发生什么？
是的，事实之后 ，你看到很多你的库存没有出售。 但是，由于库存小得多，大多数客户不会在库存中find他们想要的图书。 事后知道哪些书没有出售并不意味着你可以在事实之前用一个较小的库存做 – 在你知道哪些书是人们想要的，哪些不是。
所以即使你想要的信息可用，也不会让你得出你想要得出的结论。 你将不得不保留足够的信息来进行模拟，并说 – 如果我把更less的东西留在记忆里，我会保留下来吗？ 因此，我是否仍然拥有后来被使用的信息？
因此，即使caching中只有less量的数据被使用，除非您可以预测将使用哪些信息，但您不能通过允许caching来推断caching的其余部分没有显着的性能影响你要记住所使用的数据。