Web 和 DB 服务器：高时钟频率和较少内核与较低时钟频率和许多内核

Question

我目前正在考虑为我的托管项目建立一个新的基础设施。基本上它将被托管托管，重点关注基于 Django 的应用程序。当然，所有这些都将基于 Linux，使用 PostgreSQL 作为数据库，使用 nginx 或 Apache 作为 Web 服务器以及 Gunicorn 等。

现在我正在寻找可以租用的服务器系统市场，很难买到符合预算和所有标准的东西。所以想请教以下问题。

我能找到的所有好产品要么使用单个高端 XEON E3-12xx（Quads @ >= 3.2Ghz）或多核 Opteron（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 或更多，我不再那么确定，因为就我而言，我正在比较不同的微架构（至强与皓龙）和不同代。

所以我想问社区：对于以应用程序为中心的 Web 服务器，它必须以较低的速率使用更多的内核还是以较高的速率使用更少的内核，并且还必须处理数据库负载？

邮件系统是另一回事。理想情况下，我希望在三个不同的服务器上拥有邮件、数据库和网络。但这不在预算之内。因此，根据我为 Web 服务器获得的系统，邮件系统也有可能最终出现在该系统上……我知道这不是最佳选择。我在这里担心来自邮件系统的所有小写操作会对 DB 和 Web 性能产生多大影响。以 32 GiB 的 RAM 为例，在不久的将来，数据库将完全适合 RAM，直到服务显着增长（如果有的话）。

一种可能的（或多或少是最佳的）场景：例如，8 核 Opteron 62xx @ 2 Ghz 机器上的 Web 和 DB（其他一切同上）以及较小的 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 服务器来避免所有的麻烦，毕竟它最终不会非常可扩展。如果没有任何重大限制，我将不得不做一些进一步的调查......但我充满希望。:)

Answer 1

这是一个复杂的主题，但不要忘记这里的另一个元素 - 您还可以比较不同代的硬件。这不仅仅是一个纯粹的 GHZ 比较，您可以很好地比较过时的 opterons（只有 8 个内核？ - 是 2x4，与今天相比，这是一个非常慢的内核）与沙桥/常春藤桥级至强。我会选择至强，只是为了代际问题。

（是的，我有相同的 - 1 个四核现代至强和一个带有 2 个 4 核插槽的双 opteron，至强的整体性能杀死了较大的机器，这很快就会被重新用作 SAN 系统。

Answer 2

您的问题不仅仅是内核和性能。

• 您的服务器需要支持多少并发用户？
• 您是否只有一台服务器且没有冗余？您的应用程序可接受的停机时间是多少？
• 您是否对此应用程序的开发机器进行了任何基准测试以稍微推断性能？

如果您不期望有太多流量，您可能会太担心。如果您想将所有应用程序放在单个服务器上，如果硬件出现问题，您可能会面临完全中断的风险。看看您是否可以使用 2 倍低的机器并分配负载。为了提高性能，您可以使用任务集将核心专用于 PostgreSQL 进程，以便管理数据库性能。

如果您管理好您的磁盘，那么您也可以获得更好的性能。例如，为 pg_xlog 设置 RAID 1 中的 2 个磁盘。

长答案是，对您的应用程序进行基准测试，如果您无法承受停机时间，请考虑冗余。此外，将成本与云解决方案进行比较，如果您的应用程序可以扩展，这将有所帮助。