我可以在没有交换的情况下运行 Oracle 服务器吗？

Question

Oracle 官方文档说，对于 RAM 超过 16GiB 的机器，我们需要分配 16GiB 的交换空间。

我们的服务器是 RHEL 7，有 256GiB 的 RAM。

DBA 不想看到系统交换，因此他们希望我们非常积极地监控 16GiB 的交换。

我建议我们将 RAM 加倍到 512GiB（费用已获批准），并禁用交换。然而，即使我们将 RAM 加倍，这也违背了 Oracle 建议的具有 16GiB 的交换空间。

老实说，我不明白拥有 3% 的交换空间有什么意义，或者为什么如果我添加的 RAM 比交换空间多，我们必须保留交换空间。

那么，有没有什么好的论据可以用来证明在没有交换的情况下运行 Oracle 是合理的？

PS 我提到内存翻倍的唯一原因是为了证明我很难争论的论点的荒谬性。我真正要寻找的是证明禁用交换的理由。

Answer 1

禁用交换是一个好主意，如果

• 您的软件可以优雅地处理内存不足情况或限制自身以避免 OOM 情况
• 保持一致的性能至关重要（当您的系统交换延迟时，延迟会增加，这可能会严重到使其对许多应用程序无效）

这种事情经常发生在数据库中。我在 noSQL 数据库中看到的更多，但关系数据库也会遇到同样的挑战。

操作系统中没有任何东西需要交换在那里。Linux 通过杀死最后一个请求内存的进程来非常优雅地处理这个问题。您不想达到那个点，因此请确保将 Oracle 调整为仅使用约 90% 的内存，以便系统守护程序和错误余量留有一些剩余空间。“空闲”内存还用于缓冲磁盘 I/O，这是一个巨大的性能优势，因此尝试由数据库本身消耗更多内存最终会降低整体系统性能，从而产生适得其反的效果。

即使系统的内存只有一小部分，如果应用程序是数据库或缓存或类似系统，我此时默认不进行交换。

当局

所以你不只是依赖我的话：

卡桑德拉

Datastax为 Cassandra 解释：

您必须完全禁用交换。如果不这样做，可能会严重降低性能。因为 Cassandra 有多个副本和透明的故障转移，当内存不足时，最好立即杀死一个副本，而不是进入交换区。这允许流量立即重定向到正常运行的副本，而不是继续访问由于交换而具有高延迟的副本。如果您的系统有很多 DRAM，交换仍然会显着降低性能，因为操作系统会换出可执行代码，以便有更多 DRAM 可用于缓存磁盘。

里亚克

Basho为 Riak 解释说你应该：

理想情况下，您应该禁用交换以确保 Riak 的进程页面不被交换。禁用交换将允许 Riak 在内存不足的情况下崩溃。这将erl_crash.dump在/var/log/riak目录中留下一个名为 的故障转储文件，可用于确定内存使用的原因。

mysql

Percona站在围栏上，并为问题的双方提供了有用的警告。 MariaDB不同意禁用交换：

虽然有些完全禁用交换，并且您当然希望避免任何数据库进程使用它，但保留一些交换空间是明智的，至少允许内核在出现尖峰时正常崩溃。拥有紧急交换至少可以让您在一定范围内杀死任何失控的进程。

服务器故障

这里广受好评的答案包括：

我个人认为交换系统比崩溃的系统更糟糕。崩溃的系统会触发备用备份服务器更快地接管。在主动-主动（或负载平衡设置）中，崩溃的系统会更快地停止旋转。无交换系统再次获胜。

这个答案今天有 22 票赞成，而且已经有 4 年历史了。您还可以在那里看到一些其他的答案，赞美交换的价值，但没有迹象表明他们正在运行数据库。他们也没有那么多赞成票。:)

乌贼

虽然他们并没有公开建议禁用交换，但鱿鱼家伙说：

鱿鱼往往有点记忆力。它将内存用于许多不同的事情，其中​​一些比其他的更容易控制。内存使用很重要，因为如果 Squid 进程大小超过系统的 RAM 容量，则必须临时将进程的某些块交换到磁盘。如果您在同一系统上运行其他需要大量内存的应用程序，也可能发生交换。交换会导致 Squid 的性能迅速下降。

这就是您不希望发生在您的数据库上的事情。

Redis

虽然 redis官方建议交换用户不要购买它：

首先禁用交换 - Redis 和交换不容易混合，这肯定会导致缓慢。

Hadoop

正如在 hortonworks 社区获得最多选票的答案中所见：

对于只有分布式服务的slave/worker/data 主机，您可能会禁用交换。对于分布式服务，最好让进程/主机被杀死而不是交换。杀死该进程或主机不应影响集群可用性。换句话说：你想“快速失败”而不是“慢慢退化”。

[....]

对于masters，swap 也经常被禁用，尽管它不是 Hortonworks 的既定规则，我认为会有一些讨论/分歧。可以像对待其他非 Hadoop 环境中的 master 一样对待 master。

在主节点上禁用交换的担忧是 OOM（内存不足）事件可能会影响集群可用性。但是即使配置了交换，这种情况仍然会发生，只是需要更长的时间。良好的管理员/操作员做法是监控 RAM 可用性，然后在内存不足之前修复任何问题。从而在不影响性能的情况下保持可用性。那时不需要交换。

我喜欢这个是因为它在谈论一个 Java 应用程序，但它得出了很多与上面提到的关于数据库的相同结论。此外，它还提到了对调整高性能应用程序非常有帮助的监控。如果你没有数字来比较，一切都是基于更难比较的感觉。为每个可衡量的指标制作图表 - 应用程序级延迟和吞吐量到 CPU、磁盘、内存和网络图表。这些提供了您必须做出决策的大量真实数据。