更多的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％。当前的DB大​​小目前约为10 GB 26 GB，并且以每月250 MB的速度增长。

• 当前运行在与Web服务器共享的单个四核Xeon盒上的SQL Server 2008 R2 Standard（12 GB Ram，RAID 1中的2 x 10k 300GB SAS驱动器）上，希望迁移到SQL Server 2012 Standard。

• 数据库可以为大约100-150个并发用户提供一些后台调度任务。阅读这篇文章，我认为12个内核严重过头了！

我将整个应用程序部署到链接到SQL Azure DB的Azure云服务（2个小实例）。尽管在测试时性能是合理的（几乎为零负载），但由于我已经读了太多的不可预测性，所以我失去了在生产中使用的勇气。使用横向扩展方法可能会更好，但是只有10 GB的数据库，我现在可以避免扩展并节省一些现金。

我最初忽略了许可成本，却没有意识到SQL Server 2012许可是基于内核数量的。我有一个带有SQL Server 2012 Standard许可证的BizSpark MSDN订阅，因此我需要了解开箱即用的几个内核。

从不起眼的经验来看，但我认为值得分享，SQL数据库（此处为Sybase和SQL Server）的主要瓶颈是存储。

但是，我认为有人在做出任何错误假设之前先对他们的设置进行基准测试是公平的。以我为例，CPU使用率从未高过足以证明在不久的将来升级CPU的合理性。相反，我已从单驱动器升级到RAID 1，然后又升级到RAID 10，并将RAM从8GB升级到16GB。

所有这些RAID升级有助于将以前的等待时间减少2到6倍。我怀疑升级到SSD会更好。如果您考虑一下，所有这些都可以减少到（理论上）带宽。您的[（RAM速度+ RAM大小+内存控制器）到CPU的链接]组合具有带宽限制，当应始终缓存数据，特定的（RAID）存储设备具有带宽限制时，这将是读取操作中最重要的因素（在缺少缓存时影响读取，在刷新时或与许多客户端写入大量数据时影响写入。

尽可能标准化所有这些限制（将它们拉近以免浪费资源），并尽可能地提高它们（在需要时进行升级，并且仅在需要时，如果系统不会浪费资源，则不要浪费时间）无法使用它们，因为还有其他瓶颈。最后，最严重的瓶颈将是特定配置中性能最差（带宽最少）的服务器子系统。

我还可以补充一点，在升级过程中，我为数据库文件和数据库日志文件创建了单独的RAID配置。原因是数据库日志文件往往需要大量写入。日志文件用于从崩溃中恢复数据库，并且在将任何数据写入数据库文件之前，在提交事务后，该日志文件始终会立即写入日志文件。

某些数据库复制服务器也使用日志文件，但是大多数复制不是立即完成，而是经常进行，因此对读取性能的影响最小。至少我是这样认为的。在进行此升级时，我做了最少的基准测试，因此，我建议任何人在考虑升级CPU之前，先对其不同的配置进行基准测试，然后先升级其存储，然后再升级RAM和网络链接。

在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上搜索）。这就是为什么我选择Intel DC（DataCenter）系列SSD。

在第一部分中可能找不到您想要的答案，但是：您是否考虑过将其推向云端？AWS可以让您满足上述大多数需求，并扩展购买能力，而无需同时处理硬件。

第二部分-硬件确实取决于任务。当我能够进行自定义CLR集成时，我倾向于倾向于使用更多的CPU，因为这样我就可以针对问题的真正并行解决方案进行优化。尽管在大多数情况下，如果最好有一套基于集合的解决方案，我会发现RAM和硬盘驱动器的速度是最大的瓶颈，而第二个似乎就是您的情况。（上面的SSD想法会有所帮助）

如果没有来自服务器的任何实际统计信息，我建议您考虑使用一些缓存解决方案来降低写入量（除非您使用写入内容进行某种日志记录或需要历史记录的东西）并将更多的钱投入硬盘驱动器中比CPU的。SQL Server非常擅长并行处理查询（如果为它们编写的话），但是如果您写得很繁琐，那么硬盘驱动器就是真正的瓶颈。