64位還是32位Linux系統？
我有一台具有 4GB 記憶體的伺服器。在它上面，我安裝了 32 位 Slackware Linux 12.1。當然，它並沒有使用全部 4GB 的 RAM。我很快想將 RAM 增加到 8GB，並且正在尋找一種方法讓系統使用它。該系統用作數據庫伺服器，白天處於高負載狀態。
AFAICT，我有兩個選擇：保留 32 位並重建核心並失去一些性能。或者使用 64 位並重新安裝所有內容。查看 64 位版本的 Slackware，我可以執行 -current 或 Slamd64。
現在，關於問題：
- 我應該繼續使用 32 位還是使用 64 位？
- 如果我使用 64 位，我應該使用 -current 還是 Slamd64？
PS我希望從實際在生產中使用任何這些配置的人那裡得到答案，而不僅僅是複制/粘貼我可以通過Google找到的東西。
大多數現代 32 位 CPU 支持 PAE，這允許它們處理超過 4GB 的物理記憶體，儘管單個程序一次只能看到 4GB。核心將佔用一些該地址空間。 這篇 Stackoverflow 文章討論了 PAE 的工作原理。
許多作業系統（包括 Linux 和 MS Windows）提供了一個 API，允許您在程序的虛擬地址空間內外操作 MMU 和頁面覆蓋。此工具允許您為磁碟緩衝區使用額外的記憶體。但是，據我所知，唯一直接支持此功能的 DBMS 平台是 MS SQL Server。
額外的記憶體將提高您的數據庫讀取性能（這可能會提高您的整體吞吐量），但寫入性能將受到 I/O 的限制。如果您的數據庫記憶體命中率較低（例如低於 95%），那麼額外的記憶體可能會提高您的整體吞吐量。否則，您可能需要查看磁碟子系統（參見下面的 1）。
假設您需要或可以從更多記憶體中受益，最好的方法是遷移到 64 位平台。現代 Xeon 或 Opteron 伺服器最多可安裝 32-144GB，具體取決於型號。這可能是您的最佳選擇。
- SAN 適用於事務性應用程序。對於大容量應用程序，您應該在 DB 日誌上進行直寫式記憶體，但您可能能夠在數據卷上使用回寫式記憶體。這將為您提供良好的日誌讀取器性能，因為隨機數據寫入可以被控制器的電池支持記憶體吸收，並且控制器可以優化磁碟寫入以提高吞吐量。
但是，這種安排具有可能導致數據量不一致（損壞）的故障模式。在日誌卷上使用直寫可以緩解這種情況（因為日誌不易受到這些故障模式的影響）。實際上，這將您限制為還原/前滾恢復模式，因此只有在您可以容忍（例如）4 小時的恢復視窗時它才會起作用。