我有一个运行 Ubuntu 16.04 的 AWS ec2 实例，具有 64 GB 的 RAM，并且交换文件配置为 8GB。在每晚的批处理过程中，该批处理将备份数据从此实例的 EBS 卷同步到 S3 存储桶，交换内存几乎 100% 利用率，但主内存仍有 10-15 GB 的可用空间。
这是 swappiness 的默认值：
$ cat /proc/sys/vm/swappiness
60
这令人担忧吗？如果是，我是否应该通过更大的交换文件来增加交换空间，或者选择交换分区？
答案1
尽管有足够的 RAM，但夜间批处理作业后仍会使用大量交换空间，这种现象并不令人担忧。这尤其不令人担忧，因为它发生在夜间，计算机前没有用户。因此，您的用户体验不会受到这种交换空间使用的影响。很可能，就目前情况而言，您的特定批处理过程以最高的效率和速度执行。
如果您当时坐在电脑前执行其他任务，这种高交换使用率才会引起实际问题。高交换倾向有时会导致用户界面响应略有延迟，因为您需要从交换中检索应用程序的某些 RAM。较低的交换倾向将降低软件被交换出去的可能性，并减少您遇到的延迟。您会认为这是更快的性能，即整个系统的即时响应，但代价是其他进程没有“喘息空间”来执行其活动，因为您一直占用 RA，即使对于您不再需要的进程也是如此。
答案2
如果您想要更严格的交换策略，您可以降低您发布的交换设置。这回答很好地解释了 swapiness 的含义。
根据我的个人经验，如果您想在不损失系统稳定性的情况下尽可能多地利用 RAM，则 swapiness 为 10 就可以了。
答案3
这不一定会引起担忧，也不表示减少或调整交换性。
vandium 的回答非常全面，但我还想提几点。
可以将较低的交换值视为风险更大，而较高的值则更为保守。也就是说，较低的交换值将等到内存情况更加糟糕且紧张，缓存所剩无几时才会进行交换，而较高的交换值将在可用内存和缓存大小仅受到轻微威胁时进行交换。许多人认为降低交换值是减少交换的全面方法，但通常情况下您仍会进行交换，但会在稍后系统更需要内存时进行。减少交换的真正全面解决方案是增加更多 RAM。
其次，交换数据的行为是，它会一直保留在交换区中，直到再次被请求，而不是在内存需求再次下降时立即换出。有些人看到这种情况，认为这是不可取的；他们认为应该避免交换，但这样做的理由是换出的性能损失与换入的性能损失大致相同，因此系统可以避免不必要的换出。如果您最终确实需要交换中的某些东西，那么无论如何，换出都会在某个阶段发生，但通过将其延迟到请求时，它会让可用内存和缓存空间保持良好和高水平（以获得良好的系统性能，并且在内存需求快速再次回到之前的高位时（例如，如果高内存事件是按计划发生的）可以获得更好的响应）并避免不必要的 I/O。