Web-和 DB-Server：高時鐘頻率和更少的核心與更少的時鐘頻率和許多核心
我目前正在考慮為我的託管項目建立一個新的基礎設施。基本上它將是託管託管，重點關注基於 Django 的應用程序。當然，所有這些都將是基於 Linux 的，PostgreSQL 作為 DB，nginx 或 Apache 作為 Web 伺服器以及 GUnicorn 等。
現在我正在尋找伺服器系統出租的市場，很難找到符合預算和所有標準的東西。所以我想就以下問題徵求意見。
我能找到的所有優質產品都可以使用單個高端 XEON E3-12xx（Quads @ >= 3.2Ghz）或多核 Opterons（6000 或更早版本，8 核或更多 @ 2.00 - 2.40 GHz）。從 I/O POV 來看，兩者通常都有帶電池的 HW-RAID10、足夠的 RAM 以滿足我的需求（24-32 GiB ECC-RAM）和 1 Gbit/s 上行鏈路。我發現的一個報價也相當不錯，但它基於兩個 E5620 XEON，恕我直言，該系統的價格與其他系統相同。
現在我被撕裂了。在我見過的每一個合成基準測試中，XEON 的表現都優於 Opterons——強調合成。但我堅信，當涉及到伺服器的工作時，許多核心確實提供了很大的好處，其中有更多的並行工作（例如更便宜的上下文切換）。但是由於每個核心 1 Ghz 或更多的差異，我不再那麼確定，因為在我的情況下，我正在比較不同的微架構（XEON 與 Opteron）以及不同的代。
所以我想問社區：對於一個以應用程序為中心的 Web 伺服器，它還必須處理數據庫負載，以更低的速率獲得更多的核心還是以更高的速率減少核心？
郵件系統是另一回事。理想情況下，我希望在三個不同的伺服器上擁有郵件、數據庫和網路。但這不在預算之內。因此，根據我為 Web 伺服器獲得的系統，郵件系統也可能最終在該系統上……我知道這將是次優的。我擔心來自郵件系統的所有小寫操作會對數據庫和 Web 性能產生多大影響。以 32 GiB 的 RAM 為例，在不久的將來，數據庫將完全適合 RAM，直到服務大幅增長（如果有的話）。
一種可能的（或多或少最佳的）方案：Web 和 DB 在 8 核 Opteron 62xx @ 2 Ghz 盒子上（其他一切如上）和郵件系統在較小的 E3-1230 上。但我再次對 Opteron 的表現感到非常擔心。:(
艱難的決定。再次，我會很感激我能得到的任何建議/幫助。
非常感謝提前…
更新（11/08/11 @ 1518 GMT）：基本上我將 Sandy Bridge E3-12x0 XEON 與 Magny-Cours/Zurich/Interlagos Opterons 進行比較。不幸的是，我無法使用基於 Ivy Bridge 的專用伺服器。根據 apache 基準測試和 cpubenchmark.net 的結果，E3-1270v1 似乎是一個真正的主力，甚至會勝過雙 E5620 和大多數 Opterons，這有點令人難以置信。當然，這些測試中的大多數仍然是合成的，並且還有其他瓶頸需要考慮。但現階段我想為未來打下堅實的基礎，所以我不會太容易被 CPU 束縛。
我的直覺一直是為 web/db 伺服器提供更多的核心和/或處理器，而不是以犧牲核心/處理器的數量為代價來提高時鐘頻率。因此，以 E3-1270 為例，查看 4C 設置感覺是錯誤的做法。
順便說一句，託管將是我為客戶提供的產品，因此它不是我可以基準測試的單一產品。基本上它幾乎總是基於 Django 的應用程序，主要是具有自定義功能或自定義項目的 CMS 系統。
現在我真的在考慮一個不錯的 E3-1270 系統作為 Web 和 DB-Server 的組合，以及一個 E3-1220 作為郵件系統。兩者都具有快速 RAID 和自然充足的 RAM。雖然真正的4C很快會在生產環境中出現問題，但我還是很擔心。:( 但是，如果我得到一個基於 Opteron 6274 的系統，我將不得不在該系統上執行郵件系統，這不是很理想。此外，根據 cpubenchmark.net，它並沒有快太多……但是再次：綜合基準。:(
基本上我在問自己：例如 Opteron 6274 或 2x 6128 在現實世界的場景中會勝過 E3-1270 還是 E3-1270 仍然會贏？對於堅實的基礎，這是正確的決定嗎？
同樣，如果有人對我有任何好的建議和/或建議，非常感謝，因為我現在陷入了大腦中的回饋循環。:)
**更新（12/08/11 @ 1835 GMT）**感謝大家的幫助。現在我正在研究一種完全不同的方法：在 Heroku 或 Google AppEngine 上託管我客戶的項目等，從而提前避免大部分麻煩。;) 對於郵件系統，一個 E3-12x0 就足夠了，所以我會用一個組合的 web/app/db 伺服器來省去自己的所有麻煩，畢竟它最終不會非常可擴展。如果這在沒有任何重大限制的情況下可行，我將不得不做一些進一步的調查……但我充滿希望。:)
您的問題不僅僅是核心和性能。
- 您的伺服器需要支持多少並髮使用者？
- 您是否只有一台伺服器且沒有冗餘？您的應用程序可接受的停機時間是多少？
- 您是否為此應用程序對您的開發機器進行了任何基準測試以在一定程度上推斷性能？
如果您不期望有太多流量，您可能會太擔心。如果您想將所有應用程序放在單個伺服器上，如果硬體出現問題，您將面臨完全中斷的風險。看看您是否可以購買 2x 較低的機器並分配負載。為了性能，您可以使用任務集將核心專用於 PostgreSQL 程序，以便管理數據庫性能。
如果您管理好您的磁碟，那麼您也可以獲得更好的性能。例如，為 pg_xlog 設置 RAID 1 中的 2 個磁碟。
長答案是，對您的應用程序進行基準測試，如果您無法承受停機時間，請考慮冗餘。此外，將成本與雲解決方案進行比較，如果您的應用程序可以擴展，這將有所幫助。