更多 CPU 核心與更快的磁碟
我是一家小公司的一員，所以像往常一樣擔任許多不同的角色。其中最新的是為我們的 .NET Web 應用程序採購專用的 SQL Server 盒子。我們引用了雙 Xeon E5-2620（六核）2.00 GHz CPU 配置（總共 12 個核心），具有 32 GB 的 RAM。這使我們的磁碟陣列預算有限，它基本上由 RAID 1 配置中的兩個 2.5" SAS 300 GB 驅動器 (15k RPM) 組成。
我知道磁碟設置對於 SQL Server 來說不是最佳的，我真的很想推動 RAID 10，這樣我們就可以將數據庫、日誌文件和 tempdb 放在它們自己的驅動器上。為了使這與我們的預算兼容，我是否應該考慮減少 CPU 核心的數量？或者我會得到更好的銀行來保持核心並使用更少的驅動器，也許在雙 RAID 1 設置中使用 4 個？
以下是一些額外的統計數據
- SQL Server 數據庫傾向於大量讀寫，可能分別為 80% 和 20%。目前的數據庫大小約為10 GB 26 GB，每月以 250 MB 的速度增長。
- 目前在與 Web 伺服器共享的單個四核 Xeon 盒上執行 SQL Server 2008 R2 Standard（12 GB Ram，RAID 1 中的 2 個 10k 300GB SAS 驅動器），希望遷移到 SQL Server 2012 Standard。
- 數據庫為大約 100-150 個並髮使用者提供一些後台調度任務。讀到這裡，我認為 12 核是嚴重的矯枉過正！
我將整個應用程序部署到與 SQL Azure DB 連結的 Azure 雲服務（2 個小實例）。儘管在測試時性能是合理的（幾乎為零負載），但由於我讀了很多關於不可預測性，我失去了在生產中使用的勇氣。使用橫向擴展方法可能效果更好，但僅使用 10 GB 的數據庫，我現在就可以擴展並節省一些現金。
我最初忽略了許可成本，並沒有意識到 SQL Server 2012 許可是基於核心數量的。我有一個帶有 SQL Server 2012 標准許可證的 BizSpark MSDN 訂閱，所以我需要閱讀開箱即用的核心數量。
從不起眼但我認為值得分享的經驗來說，SQL 數據庫（這裡是 Sybase 和 SQL 伺服器）的主要瓶頸是儲存。
但我認為在做出任何錯誤假設之前首先對他們的設置進行基準測試是公平的。就我而言，CPU 使用率從未上升到足以證明在任何時候升級 CPU 都是合理的。相反，我已經從單個驅動器升級到 RAID 1，然後升級到 RAID 10 + 從 8GB 到 16GB 的 RAM。
所有這些 RAID 升級都有助於將之前的等待時間減少 2 到 6 倍。我懷疑升級到 SSD 會更好。如果你仔細想想，它都可以減少到（理論上的）頻寬。您的
$$ (RAM Speed + RAM Size + Memory controller) link to CPU $$組合具有頻寬限制，當您的數據應始終被記憶體時，這將是讀取操作中最重要的因素，您的特定 (RAID) 儲存有頻寬限制（影響記憶體失去時的讀取和刷新時的寫入或許多客戶端寫入大量數據合併）。 盡可能規範所有這些限制（使它們更接近，這樣您就不會浪費資源）並儘可能提高它們（在需要時升級，僅在需要時升級，如果系統不會讓資源浪費’無法使用它們，因為存在其他瓶頸）。最後，您最糟糕的瓶頸將是您的特定配置中性能最差（頻寬最少）的伺服器子系統。
我還可以補充一點，在升級過程中，我為數據庫文件和數據庫日誌文件創建了單獨的 RAID 配置。原因是數據庫日誌文件往往是寫密集型的。日誌文件用於從崩潰中恢復數據庫，並且在任何數據寫入數據庫文件之前，它總是在事務送出時立即寫入。
一些數據庫複製伺服器也使用日誌文件，但大多數複製不是立即完成而是經常完成，因此這裡對讀取性能的影響很小。至少我是這麼認為的。在進行此升級時，我已經做了最低限度的基準測試，所以我建議任何人首先對他們的不同配置進行基準測試，並首先升級他們的儲存，然後是 RAM 和網路連結，然後再考慮升級他們的 CPU。
在超過 5 台伺服器上進行了更廣泛的升級後，我回來分享我的經驗。我絕對仍然主張先升級儲存，然後是 RAM，然後是 CPU。原因是系統中儲存、RAM 和 CPU 之間的頻寬差異，按從低到高的順序排列。所以我將一堆伺服器從 RAID10 和雙 RAID1 升級到 SSD。
出於成本考慮（我還有 20 台伺服器要升級），我這樣做的方式是將數據庫數據和對象文件移動到 SSD（是的，RAID0 中只有一個 SSD）並將事務日誌和 tempdb 移動到 4xHDD RAID10配置。我也在 SSD 上使用 tempdb 進行了測試，結果很好（實際上，結果非常好，有時查詢速度提高了 15 倍以上，產生一些報告需要幾秒鐘而不是過去幾分鐘），但後來將 tempdb 移動到磁碟 RAID10，因為SSD 的密集寫入磨損問題。
所以現在基本上我觀察到每個最長查詢的響應時間快了 10-15 倍。SSD 非常適合快速將數據讀入 RAM，因為 SQL Server 在請求數據之前不會將數據帶入 RAM，當然數據首先需要載入到 RAM 中以由 CPU 處理（稍後，在 L1、L2、L3 記憶體中） ，因此 SSD 有助於大大減少初始等待時間。SSD 還有助於減少交換時間……清除 RAM 並載入新數據，尤其是當您的數據庫大於 RAM 時。
總而言之，我們非常高興，並且在緩慢的遷移過程中執行了幾個月以允許伺服器執行，這樣我就可以在將所有伺服器切換到此配置之前收集磨損級別資訊。這只是 SQL Server Express！:D - 只需確保您的 SSD 可以提供恆定的 IOPS，因為這是另一件產生巨大差異的事情（只需Google它）。這就是我選擇英特爾 DC (DataCenter) 系列 SSD 的原因。