QFD*_*Dev 14 performance sql-server configuration hardware
我是一家小公司的一员，所以像往常一样负责许多不同的角色。最新的是为我们的 .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（RAID 1 中的 12 GB Ram、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 订阅，因此我需要阅读开箱即用的内核数量。
Pau*_*ole 10
从谦虚但我认为值得分享的经验来说，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，因为这是另一件产生巨大差异的事情（只需谷歌一下）。这就是我选择 Intel DC (DataCenter) 系列 SSD 的原因。