完全交换内存，但内存可用

Question

我有一个使用64 GB RAM运行Ubuntu16.04的AWS ec2实例，并将一个交换文件配置为8GB。在将从该实例的EBS卷到S3桶的备份数据同步的夜间批处理过程中，交换内存几乎100%被利用，但主内存仍然在10-15 GB可用范围内有大量空间。

以下是swappiness缺省值：

$ cat /proc/sys/vm/swappiness
60

担心吗？如果是，我应该通过拥有更大的交换文件或选择交换分区来增加交换空间吗？

Answer 1

在这个观察中，尽管有大量的RAM，但在夜间批处理作业之后，您看到了大量的交换使用，这并不令人担忧。尤其是没有人担心，因为它发生在夜间，没有用户在电脑前。因此，您的用户体验不会受到这种交换使用的影响。很可能，就目前情况而言，您的特定批处理过程以最大的效率和速度执行。

只有当您在此期间在计算机前执行其他任务时，这种较高的交换使用率才会引起实际关注。交换的高倾向有时会导致用户界面的响应稍有延迟，因为您的应用程序的某些RAM需要根据需要从交换区中检索。使用较低的交换倾向将降低软件交换的可能性，并且您会遇到延迟。您将认为这是更快的性能，即整个系统的即时响应，但牺牲了其他没有多少“喘息空间”来执行其活动的进程，因为您一直占用RA，即使您不再立即需要进程。

Answer 2

如果你想要一个更严格的掉期政策，你可以降低你张贴的交换设置。这个回答很好地解释了什么是虚张声势。

根据我个人的经验，如果你想在不失去系统稳定性的情况下利用尽可能多的内存，那么10的波动就会很好。

Answer 3

这不一定是引起关注的原因，也不意味着减少或调整了交换。

钒的答案是相当全面的，但我也想提几件事。

它有助于将较低的互换值视为更高的风险，而较高的值则更保守。也就是说，较低的交换值将等到内存状况更加糟糕和紧张时再进行交换，而当可用内存和缓存大小只受到轻微威胁时，则会出现较高的交换值。许多人认为减少交换是减少交换的一种普遍方式，但这种情况经常发生，你仍然会进行交换，但在稍后的时候，当你的系统更加迫切地需要内存时，你仍然会进行交换。减少交换的真正解决方案是增加更多的RAM。

第二，交换数据的行为是在交换数据之前保持在交换中，直到再次请求为止，而不是在内存需求再次减少时被交换掉。有些人认为这是不可取的；他们认为应该避免交换，但这样做的理由是，交换的性能损失与交换差不多，因此系统避免不必要的交换。如果您确实需要交换中的某些内容，那么交换就会在某个阶段发生，但是将其推迟到请求时，就会使可用的内存和高速缓存空间变得更好和更高(为了更好的系统性能，并在内存需求迅速恢复到以前的高点时，如高内存事件按计划进行一样)，从而避免不必要的I/O。