高压下的 SSAS 表格模型性能问题答案

【问题标题】：SSAS Tabular model performance problem under high pressure高压下的 SSAS 表格模型性能问题
【发布时间】：2020-10-05 19:31:16
【问题描述】：

在我们公司，我们有“周一办公室”，这意味着每个办公室/商店/部门（大约 2000 多个不同的用户）都应该生成他们的报告，尤其是商店（与表格 1500 兼容级别连接的 SSRS）。我们在 3+ 小时范围内（CPU 100% - 多核）面临着非常高的资源使用率，并且会话队列正在增长并且永远不会刷新。由于超载，在非高峰时段需要 2 分钟的报告可能需要一个多小时。我们有本地机器。本周余下的问题没有发生（工作量降低 10 倍，峰值 CPU 使用率低于 30%）。

很遗憾，从业务角度来看，我们无法将负载分散到一周的剩余时间。我们也无法影响在给定时间（全天的负载分布）有多少用户将运行报告。

我们已经尝试过的：

将报表中的查询从旧 MDX 重写为 Dax（始终使用 Dax Studio 中的 Serving Timing 检查单个查询的性能）
重写措施以降低成本
调整我们的模型（例如，更改为消耗较少的数据类型，删除未使用的列）
我们无法将此模型迁移到 Azure。
我们无法在这台机器上进行任何硬件更改。

也许我们可以更改一些服务器属性？模型属性？连接属性？如果资源不足，我们可以为哪些报表/查询操作表格应该保留缓存吗？例如，对于我们知道会产生许多类似查询的一组商店报告（例如，只有商店编号会改变）有什么建议吗？

【问题讨论】：

标签： ssas tabular ssas-tabular

【解决方案1】：

如果您要报告前一周的数据，是否可以自动化 ssrs 以在周日晚上输出报告？

【讨论】：

这是一个很好的提示。事实上，在大多数情况下，商店都会生成过去一周的报告。不幸的是，我不能在我的情况下使用它。商店也在周日营业（必须包含在报告中），这一天我们运行 FULL (TABULAR) 流程，晚上启动我们的每日 ETL 流程，补充当天的数据。它在午夜后几分钟开始，到 +/- 6:00 - 7:00 结束。星期一早上我没有足够的时间进行自动生成和调度。