Oracle 官方文档说，对于具有超过 16GiB RAM 的机器，我们需要分配 16GiB 的交换空间。
我们的服务器是 RHEL 7，具有 256GiB 的 RAM。
DBA 不想看到系统交换，所以他们希望我们非常积极地监控 16GiB 的交换。
我建议我们将 RAM 增加一倍至 512GiB（费用已获批准），并禁用交换。然而，这违反了 Oracle 建议的 16GiB 交换，即使我们将 RAM 增加一倍。
老实说，我不明白 3% 的交换空间有什么意义，或者为什么如果我添加的 RAM 比交换空间还多，我们就必须保留交换空间。
那么，有什么好的理由可以用来证明运行不带交换的 Oracle 是合理的吗？
PS 我提到 RAM 翻倍的唯一原因是为了证明我很难反驳的论点是多么荒谬。我真正想要的是证明禁用交换的合理性的理由。
答案1
如果
- 你的软件可以妥善处理内存不足的情况，或者限制自身以避免 OOM 情况
- 拥有一致的性能至关重要（当你的系统交换时，延迟会增加，这可能会严重到让许多应用程序无法使用）
这种事情经常发生在数据库中。我更多地在 noSQL 数据库中看到这种情况，但关系数据库也会遭遇同样的挑战。
操作系统中没有任何东西需要交换。Linux 通过终止最后一个请求内存的进程来非常优雅地处理这个问题。您不想达到这一点，因此请确保调整 Oracle 以仅使用约 90% 的内存，以便为系统守护程序和错误留出一些空间。“空闲”内存还用于缓冲磁盘 I/O，这是一个巨大的性能提升，因此试图让数据库本身消耗更多内存最终会降低整个系统的性能，从而适得其反。
即使系统只拥有一小部分内存，但如果应用程序是数据库、缓存或类似的系统，我此时会默认不进行交换。
当局
这样你就不会仅仅依赖我的一句话：
卡桑德拉
数据税Cassandra 的解释如下：
您必须完全禁用交换。不这样做会严重降低性能。由于 Cassandra 具有多个副本和透明故障转移，因此最好在内存不足时立即终止副本，而不是将其转入交换。这样可以将流量立即重定向到正常运行的副本，而不是继续访问由于交换而具有高延迟的副本。如果您的系统有大量 DRAM，交换仍然会显著降低性能，因为操作系统会换出可执行代码，以便有更多 DRAM 可用于缓存磁盘。
里亚克
芭蕉向 Riak 解释道你应该：
理想情况下，您应该禁用交换以确保 Riak 的进程页面不会被交换。禁用交换将导致 Riak 在内存不足的情况下崩溃。这将
erl_crash.dump在/var/log/riak目录中留下一个名为 的崩溃转储文件，可用于确定内存使用的原因。
mysql
佩科纳处于中立态度，并为问题的双方提供了有用的警告。 玛拉雅数据库不同意禁用交换：
虽然有些系统会完全禁用交换，而您肯定希望避免任何数据库进程使用它，但谨慎的做法是留出一些交换空间，至少让内核在出现峰值时能够正常切换。拥有紧急交换空间至少可以让您有一定范围来终止任何失控进程。
服务器故障
这里有一个广受好评的答案包括：
我个人认为 swappy 系统比崩溃的系统更糟糕。崩溃的系统会触发备用备份服务器更快地接管。而在主动-主动（或负载平衡设置）中，崩溃的系统会更快地退出轮换。无 swap 系统再次获胜。
这个答案今天有 22 个赞成票，而且已经有 4 年了。你还可以看到其他一些赞美交换价值的答案，但没有迹象表明它们正在运行数据库。它们也没有那么多赞成票。:)
乌贼
虽然他们不建议禁用交换，但鱿鱼人说：
Squid 往往占用大量内存。它将内存用于许多不同的事情，其中一些事情比其他事情更容易控制。内存使用很重要，因为如果 Squid 进程大小超出系统的 RAM 容量，则必须将进程的某些块暂时交换到磁盘。如果在同一系统上运行其他占用大量内存的应用程序，也可能发生交换。交换会导致 Squid 的性能迅速下降。
这正是您不希望发生在数据库中的事情。
redis
首先禁用交换 - Redis 和交换不容易混合，这肯定会导致速度缓慢。
Hadoop
如图所示这是 Hortonworks 社区中投票最多的答案：
为了从属/工作/数据主机只有分布式服务，您可能可以禁用交换。对于分布式服务，最好让进程/主机被终止，而不是交换。终止该进程或主机不应影响集群可用性。换句话说：您希望“快速失败”而不是“缓慢降级”。
[...]
为了大师，交换也经常被禁用，尽管这不是 Hortonworks 的既定规则，我认为会有一些讨论/分歧。主服务器的处理方式可以像在其他非 Hadoop 环境中处理主服务器一样。
禁用主服务器上的交换的担忧在于，OOM（内存不足）事件可能会影响集群可用性。但即使配置了交换，这种情况仍会发生，只是会花费更长的时间。良好的管理员/操作员做法是监控 RAM 可用性，然后在内存耗尽之前修复任何问题。从而在不影响性能的情况下保持可用性。这样就不需要交换了。
我喜欢这篇文章，因为它讨论的是 Java 应用程序，但它得出了很多与上面关于数据库相同的结论。此外，它还提到监控这对调优高性能应用程序非常有帮助。如果没有数字来比较，那么一切都是基于感觉，而感觉很难比较。为每个可测量的指标制作图表 - 从应用程序级延迟和吞吐量到 CPU、磁盘、内存和网络图表。这些提供了您做出决策所需的大部分真实数据。
答案2
Linux 上的 Alex 有一篇关于这个主题的有趣文章：“交换与无交换” http://www.alexonlinux.com/swap-vs-no-swap
底线是，没有交换：
- 您的系统将不太稳定。
- 与具有交换分区的系统相比，您系统中的磁盘访问速度会更慢。而且，磁盘访问速度会随着时间的推移而下降。
答案3
为什么不为未使用的页面保留合理数量的交换空间，并修改 vfs 缓存压力以将交换性修改为仅在 OOM 情况下进行交换。您还可以将 oracle 进程固定到主内存，以确保它们永远不会接触磁盘。这既满足了数据库不受慢速 IO 系统影响的要求，又允许您从主内存中释放垃圾以供数据库、缓冲区和缓存使用。这是两全其美的办法。
答案4
这个话题经常出现。交换只是 RAM 的扩展，所以我们要买更多的 RAM，对吧？错了。设置 16 GiB 交换和 512 GiB RAM 使得完美的经济意义。让我解释一下。
如果你熟悉主要软件，你就会知道它占用了多少“愚蠢”的内存。什么是“愚蠢”的内存？各种代码和数据最初显示在 RAM 中，但永远不会再被迫切需要。也就是说，用户看到的性能永远不会受到影响，因为这些东西在内存中不容易获得。
你不用修复软件，只需给它该金额掉期但不超过该金额。是的，让它使用 100% 的交换空间。这就是重点。不要增加交换空间，否则你可能会冒着某些关键内容意外落入交换空间的风险。记录下来，这样人们就不会因为看到 100% 的交换空间使用率而惊慌失措。以防 Oracle该金额是 16 GiB，根据我的经验，即使在 700 GiB 的盒子上，它也会被使用，而且你不会发生影响性能的 swpin。
实际上，您有 16 GiB 的 RAM 可用于实际工作并造福您的用户。截至 2017 年，它可为您的组织减少约 50 美元的成本。如果您的服务器有 256 GiB RAM，您可以配置交换并节省 50 美元。如果您的服务器有 10 TiB RAM，您可以配置交换并节省... 50 美元。看到了吗？还是一样。
目前，它总是安全的零掉期。你只需要花费那 50 美元，仅此而已。
如果您的组织没有能力处理 100% 使用的交换（例如单独的监控团队等），请不要这样做。如果您让任何人考虑这个问题，那么您已经浪费了他们 50 美元的时间。
有些供应商确实做到了零浪费内存。而有些供应商没有足够的信心估计“愚蠢”分配的数量，所以他们说“零交换”以避免未知问题，只是为了节省一大笔钱。那也没关系！我只会相信供应商，他们支持安装，他们知道他们的东西。