我可以在沒有交換的情況下執行 Oracle 伺服器嗎？
Oracle 官方文件說，對於 RAM 超過 16GiB 的機器，我們需要分配 16GiB 的交換空間。
我們的伺服器是 RHEL 7，擁有 256GiB 的 RAM。
DBA 不想看到系統交換，因此他們希望我們非常積極地監控 16GiB 的交換。
我建議我們將 RAM 翻倍至 512GiB（費用已批准），並禁用交換。然而，這違背了 Oracle 建議的 16GiB 交換空間，即使我們將 RAM 翻倍。
老實說，我不明白擁有 3% 的交換空間有什麼意義，或者為什麼如果我添加的 RAM 比交換空間多，我們必須保留交換空間。
那麼，有什麼好的論據可以用來證明在沒有交換的情況下執行 Oracle 是合理的嗎？
PS我提到RAM翻倍的唯一原因是為了證明我很難爭論的論點的荒謬性。我真正要尋找的是證明禁用交換是合理的論據。
禁用交換是一個好主意，如果
- 您的軟體可以優雅地處理記憶體不足的情況或限制自身以避免 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 和交換不容易混合，這肯定會導致緩慢。
Hadoop
對於只有分佈式服務的**從屬/工作/數據主機，您可能會禁用交換。**對於分佈式服務，最好讓程序/主機被殺死而不是交換。殺死該程序或主機不應影響集群可用性。換一種說法：你想“快速失敗”而不是“慢慢退化”。
$$ …. $$ 對於master，交換也經常被禁用，儘管這不是 Hortonworks 的固定規則，我認為會有一些討論/分歧。可以像對待其他非 Hadoop 環境中的 master 一樣對待 master。
禁用 master 上的交換的擔心是 OOM（記憶體不足）事件可能會影響集群可用性。但是即使配置了交換，這仍然會發生，只是需要稍長一些。良好的管理員/操作員做法是監控 RAM 可用性，然後在記憶體不足之前解決任何問題。從而在不影響性能的情況下保持可用性。那時不需要交換。
我喜歡這個，因為它談論的是一個 Java 應用程序，但它得出了很多與上面提到的關於數據庫相同的結論。此外，它還提到了對調整高性能應用程序非常有幫助的**監控。**如果您沒有數字可以比較，那麼一切都是基於難以比較的感覺。為每個可衡量的指標製作圖表 - 應用程序級延遲和吞吐量，直至 CPU、磁碟、記憶體和網路圖表。這些提供了您必須做出決策的大量真實數據。