正式的Oracle文档说，对于一台RAM超过16GiB的机器，我们需要分配16GiB的交换空间。
我们的服务器是RHEL 7，并有256GiB的RAM。
DBA不希望看到系统交换，所以他们希望我们非常积极地监视交换的16GiB。
我build议我们将内存翻倍至512GiB（费用已经核准），并禁用交换。 但是，这是违反了Oraclebuild议使用16GiB的RAM，尽pipe我们将RAM加倍。
老实说，我不明白3％的交换是否有意义，或者为什么如果我添加的RAM比我们交换的多，我们必须保持交换。
那么，有没有什么好的论点可以用来certificate在没有交换的情况下运行Oracle呢？
PS我提到RAM的翻倍的唯一原因是为了certificate我很难争论的论点的荒谬性。 我真正想要的是有理由认为禁用交换。
禁用交换是一个好主意，如果
这种事情经常发生在数据库上。 我更多地使用noSQL数据库来看它，但是关系数据库可能遭受同样的挑战。
操作系统中没有任何东西需要交换。 Linux通过杀死最后一个需要内存的进程来处理这个问题。 您不希望到达这一点，所以请确保您调整Oracle仅使用大约90％的内存，所以有一些留给系统守护进程和误差的余地。 “免费”内存也被用于缓冲磁盘I / O，这是一个巨大的性能胜利，所以试图通过数据库本身消耗更多的内存将最终降低整体系统性能足以产生反作用。
即使系统只有一小部分内存，如果应用程序是一个数据库或一个caching或类似的系统，我会默认在这个时候不交换。
所以，你不只是依靠我的话：
Datastax解释Cassandra：
您必须完全禁用交换。 否则会严重降低性能。 由于Cassandra具有多个副本和透明的故障转移，因此当内存不足时，副本最好立即终止，而不是进入交换。 这允许stream量立即被redirect到正在运行的副本，而不是继续击中由于交换而具有高延迟的副本。 如果您的系统拥有大量的DRAM，则交换操作会使性能显着下降，因为操作系统会将可执行代码交换出来，以便为caching磁盘提供更多的DRAM。
Basho解释Riak你应该：
理想情况下，您应该禁用交换，以确保Riak的进程页面没有交换。 禁用交换将允许Riak在内存不足的情况下崩溃。 这将在
/var/log/riak目录中留下名为erl_crash.dump的崩溃转储文件，该文件可用于确定内存使用情况的原因。
Percona坐在围栏上，为问题的双方提供有用的注意事项。 MariaDB不同意禁用交换：
虽然一些禁用交换完全，你当然希望避免任何数据库进程使用它，可以谨慎的是留下一些交换空间，至less让内核适度地倒下，如果出现高峰。 有了紧急调换function，至less可以让你有一定的空间来杀死任何失控的进程。
一个很好的答案在这里包括：
我个人发现一个比一个崩溃的系统更糟糕的系统。 一个崩溃的系统会触发一个备用的备份服务器来更快地接pipe。 而在主动 – 主动（或负载平衡设置）中，坠毁的系统将很快失去旋转。 再次赢得不换系统。
这个答案今天有22个提议，并且是4岁。 你也可以看到其他一些回答交换价值的答案，但没有迹象表明他们正在运行数据库。 他们也没有那么多的赞扬。 :)
虽然他们不公开build议禁用交换鱿鱼家伙说 ：
鱿鱼往往是一个记忆猪。 它使用许多不同的内存，其中一些比其他更容易控制。 内存使用情况非常重要，因为如果Squid进程大小超出了系统的RAM容量，则某些进程块必须临时交换到磁盘。 如果在同一个系统上运行其他需要内存的应用程序，也可能发生交换。 交换导致Squid的性能很快下降。
这就是你不希望发生在你的数据库。
虽然redis 正式推荐交换用户不买 ：
首先禁用交换 – Redis和交换不容易混合，这肯定会导致缓慢。
正如在hortonworks社区中得票最多的答案中所看到的那样：
对于只有分布式服务的从属/工作/数据主机 ，您可能会禁用交换。 使用分布式服务，最好让进程/主机被杀死而不是交换。 杀死该进程或主机不应该影响群集可用性。 换句话说：你想“快失败”不要“慢慢退化”。
[….]
对于主人 ，交换也经常被禁用，虽然它不是来自Hortonworks的规则，我认为会有一些讨论/不同意见。 大师可以像对待其他非Hadoop环境中的主人一样对待。
在主服务器上禁用交换的担心是OOM（内存不足）事件可能会影响群集可用性。 但是即使configuration了swap也会发生这种情况，只需要稍微延长一点。 良好的pipe理员/操作员的做法是监视RAM的可用性，然后在内存不足之前解决任何问题。 从而保持可用性而不影响性能。 那么不需要交换。
我喜欢这个，因为它正在谈论一个Java应用程序，但是它达到了上面提到的关于数据库的许多相同的结论。 此外，它提到了对调优高性能应用程序非常有帮助的监控 。 如果你没有数字来比较一切是基于难以比较的感觉。 为每个可衡量的指标绘制图表 – 应用程序级别的延迟和吞吐量直至CPU，磁盘，内存和networkinggraphics。 这些提供了大量的实际数据，你必须作出决定。
Linux上的Alex有一个有趣的阅读这个问题：“交换与不交换” http://www.alexonlinux.com/swap-vs-no-swap
底线是，没有交换：
这个话题经常popup。 交换只是RAM的扩展，所以让我们买更多的内存，对吧？ 错误。 使用16 GiB交换和512 GiB RAM进行设置非常经济。 让我解释。
如果你知道主要的软件，你就知道它有多less“愚蠢”的内存，相当精确。 什么“蠢”的记忆？ 最初在RAM中显示的各种代码和数据，但将永远不再需要批评。 也就是说，用户所看到的性能永远不会受到影响，因为这些东西在内存中不易获得。
而不是修复软件，你可以给它的交换量 ，但不能超过这个数量 。 是的，让它使用100％的交换。 这才是重点。 不要增加交换，否则你会冒一些重要的东西不小心在那里结束。 logging它，所以人们不会因为看到100％交换使用而感到惊慌。 如果Oracle的数量是16 GiB，我可以从我的经验中得知 ，即使在700 GiB的盒子上也可以使用，而且不会影响性能 。
实际上，您可以获得16 GiB的RAM来完成真正的工作并使您的用户受益。 截至2017年，它将使您的组织成本降低约50美元。 如果您的服务器具有256 GiB RAM，则configuration交换并保存$ 50。 如果你的服务器有10个TiB RAM，你可以configurationswap并保存… $ 50。 看到？ 还是一样。
目前，零交换总是安全的 。 这只需花费50美元就可以了，就是这样。
如果您的组织无法处理100％使用的交换（例如，单独的监控组等），则不要这样做。 如果你让任何人想到这个问题，你已经浪费了50美元的时间。
有些供应商确实没有浪费内存。 而一些供应商对于“愚蠢”的分配数量估计不够自信，所以他们说“零交换”来避免未知的问题，只是为了节省一大笔钱。 没关系！ 我只相信这个供应商，他们支持安装，他们知道他们的东西。