数据仓库服务器。您如何计算RAM / CPU规格？

我正在尝试为我们计划的数据仓库升级编写数据仓库服务器的规范。

在VMWare主机上运行虚拟服务器时，我们可以根据需要添加或删除资源。过去，我们根据需要逐渐增加了RAM和CPU。随着需求的增加，我们游说了更多的资源。（主要是磁盘和RAM）。

我们要求更多。他们给了我们尽可能少的东西。

但是最近，每当我们谈论资源时，我们都因一开始就没有正确配置机器而受到批评，现在我被告知开发主机已被用尽，没有可用的RAM。

我们是一个小型的地方政府组织，拥有约50个DW常规用户。在正常的日常使用中，它运行良好。我们获得了良好的mdx查询性能，并且我们的报告和仪表板速度很快。用户感到高兴。

但是，我们的ETL流程会整夜运行，并且当同时处理数据集市时，我们开始看到内存不足的迹象。昨晚SSIS失败，并发出有关“内存不足错误”的警告。

我们现有的DW服务器是Win 2008 R2，具有4个CPU和16Gb RAM，运行SQL 2012 Std。我将最大服务器内存设置为12GB，为OS和服务等保留了4GB。我们现有的DW有3个数据集市/ OLAP多维数据集，并且我们还在开发2个。

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

我们的新服务器计划为运行SQL 2016 Enterprise的Win 2012。它将运行SQL，SSIS，SSRS和SSAS。存储不是问题，但是我不确定RAM和CPU。

根据适用于SQL Server 2012的快速通道数据仓库参考指南，对于2插槽计算机，我应该拥有的最小值是128Gb……这似乎有点过高。安装SQL Server 2016的硬件和软件要求建议SQL 2016的内存至少为4Gb。这是完全不一样的！

所以..一个好的起点是什么？32Gb？64Gb？我如何证明自己的起始职位（规格）适合IT？

是否有关于如何计算服务器资源的良好指南？

有没有好的经验法则？

在DW环境中，RAM大小调整的关键要素/指标是什么？

• 数据量？
• 多少个立方体？
• 执行ETL或处理多维数据集所需的时间？
• 过夜的高峰处理负载还是白天最终用户看到的性能？

很好的问题，几年前，我在TechEd上进行了一次名为“构建最快的SQL Server”的会议：

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

在其中，我解释了对于数据仓库，您需要能够提供足够快的数据以供SQL Server使用的存储。Microsoft建立了一系列称为“快速通道数据仓库参考体系结构”的白皮书，其中涉及硬件细节，但基本思想是您的存储需要能够在每个CPU内核中提供200-300MB /秒的顺序读取性能。为了使CPU保持繁忙。

您可以缓存在内存中的数据越多，可用的存储速度就越慢。但是，您的内存少于缓存要处理的事实表所需的内存，因此存储速度变得非常重要。

这是您的后续步骤：

• 观看视频
• 使用CrystalDiskMark测试您的存储（方法如下）
• 使用4个内核时，您需要至少 800MB /秒的顺序读取吞吐量
• 如果没有，请考虑增加内存，直到痛苦消除（并且将整个数据库缓存在RAM中也是不可想象的）

假设您有一个200GB的数据库正在处理，并且您没有足够的存储吞吐量来保持核心繁忙。不仅需要200GB的RAM，而且甚至更多的RAM并不是不可思议的，因为毕竟SSIS和SSAS确实希望在内存中完成其工作，因此您必须拥有可用的引擎数据以及SSIS和SSAS的工作空间。

这也是为什么人们尝试将SSIS和SSAS分离到不同的VM上的原因-他们都同时需要内存。

在Fast Track数据仓库参考指南SQL Server 2012的其实是有点乱日期，特别是如果你移动到SQL Server 2016（真的吗？叫我），不仅在时间上，而且还提供。

在SQL Server 2012（快速通道所基于的版本）中，您只能具有非聚集的列存储索引。这些是与主表不同的结构，因此尽管压缩了数据副本，但仍会产生额外的存储和处理开销。

从SQL Server 2014起，您可以具有群集的列存储索引。这些为汇总/摘要查询提供了巨大的压缩能力并可能提高性能。它们绝对适合事实表，因此您的32GB事实表可能看起来更像是〜8-12GB。YMMV。那会稍微改变景观，不是吗？看着您的桌子（拇指朝上），您也许可以摆脱32GB的空间，但我会为64GB拍摄（这不像您要的是1TB），并为其他服务和增长留出了空间，这样做的理由是您将最大的表保存在内存中，为增长留出空间并为其他服务留出空间。您不必告诉他们有关压缩的信息。调整大小时必须牢记的一件事是，您现在不仅要调整数据大小，还需要调整大小，比如说从现在开始一年之后。另请注意，点查找的性能可能令人恐怖，但是当您迁移到SQL Server 2016时，可以添加其他索引，或者可以始终考虑将列存储索引用于实时操作分析，尽管为此您将需要更多的内存。 :)

顺便说一下，您如何使用CTP，目前在CTP3.3上，它具有您可能想使用的大多数功能，因此您说您没有试用资源，但是可以获得Windows Azure试用，启动虚拟机，创建一些示例数据，免费测试压缩，关键功能和查询的性能等。或者，如果您具有MSDN许可证，则它是内置的。

总而言之，将大小允许最大的表存储在内存中（以及其他内容），或者设置一个简单的试用版（在云中免费提供）以获取您想要的确凿证据。完成后，请记住要释放虚拟机：）

大概在本地开发机器上开发和维护ETL软件包时，您有时会使用与生产中期望的规模相近或更大的测试数据，如果没有，那么您可能会考虑这样做（匿名的真实数据或通过算法生成的测试数据，如果您的真实数据完全敏感）。

如果是这种情况，则可以在各种内存条件下运行该进程并对其进行概要分析，以了解更多的RAM不再产生巨大差异的点-像经验法则和有根据的猜测一样有用，没有基准测试和性能分析可以提供更具体的答案作为奖励，可能会突出明显的瓶颈，而这些瓶颈可能很容易优化。当然，您的开发/测试环境可能与生产环境不完全匹配，因此您可能需要利用经验来解释结果可能如何变化。

如果在数据库所在的同一台计算机上运行SSIS，则一定要确保将SQL Server引擎实例设置为从不声明所有内存。内存不足不仅会导致SSIS中的OOM错误，早在此之前，它还会导致严重的性能问题，因为它将缓冲区缓冲到磁盘上（否则会将缓冲区保留在RAM中）。根据您的过程，需要为SSIS和其他任务预留多少空间会很大，因此再次进行概要分析是衡量此情况的好方法。通常建议您在单独的计算机上运行SSIS，以使其更易于管理，尽管您可能需要考虑网络吞吐量和许可问题。

更新资料

根据您的评论，如果没有足够的资源来执行实际的基准测试，以评估如果分配的RAM太少，性能下降的地方（和/或OOM错误和相关问题开始发生），那么事情就会变得更加容易动摇没有对仓库和ETL流程的深入了解。仓库数据库本身的经验法则：您希望有足够的RAM来容纳所有所有最常用的索引，然后再提供一些以允许较少使用的数据，而又增加一些以允许近期的预期增长/中等未来。

计算此结果可能很容易-sp_spaceUsed不会按索引细分内容，因此您必须自己直接查询sys.allocation_units和朋友。虽然有一些示例可以帮助您入门，但是http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 /看起来像是来自快速搜索的前几项中最好的。

除了运行仓库数据库本身的需求之外，如果要在同一台计算机上运行SSIS，请记住增加SSIS的RAM要求，并确保SQL Server具有适当的RAM限制以确保该内存可实际用于SSIS。

从您列出的总体数据大小来看，我的建议表明，对于数据库引擎和SSIS，我建议的绝对最小值为32Gb，将SQL实例设置为最多使用26个，并且您还在运行在同一台机器上的SSRS和其他服务，明智的最低要求是将来作一些证明，将是64Gb（在削减其他服务和保留之后，当前数据的三分之二应该适合该数据）。显然，引用我的直觉不会使您在与基础架构人员的讨论中走得太远。