修復 Power BI 和 Fabric 中的“資源管理”內存錯誤

“資源管理”錯誤

許多 Power BI 和 Fabric 用戶在數據集刷新期間遇到“資源管理”錯誤。此操作會失敗，並且錯誤消息常常令人困惑。您可能會看到與此類似的內容：


"Data source error: Resource Governing: This operation was cancelled because there wasn't enough memory...

More details: consumed memory 805 MB, memory limit 134 MB, database size before command execution 2937 MB."

迫在眉睫的問題是：如果限制只有 134 MB，該操作如何消耗 805 MB？為什麼F32容量可以用，F8小容量卻出故障？

答案是“134 MB”限制並不是總容量。這是加載 2.9 GB 模型後剩餘的極少量內存*餘量*。發生該錯誤的原因是刷新操作無法適應那麼小的剩餘空間。

可視化內存限制

F8 容量（最大 3 GB 內存）

刷新操作 (805 MB)

無法適應 134 MB 的淨空

根本原因：2x 內存規則

完整的語義模型刷新大約需要最終模型大小的兩倍內存。這是因為系統必須將“舊”模型保留在內存中以服務用戶查詢，同時構建“新”模型。

所需刷新內存 ≈（最終模型大小）x 2

建議閱讀：TCO 計算器：Power BI Embedded 與 Microsoft Fabric 成本分析

示例：（2.9 GB 型號）x 2 = 5.8 GB 所需內存

選擇合適的面料 SKU

此 5.8 GB 要求解釋了 F8 SKU 失敗的原因。從官方的內存限制來看，F8（3GB）和F16（5GB）對於這次全面刷新來說都太小了。 F32（10 GB）有足夠的內存，這就是它成功的原因。

交互式 SKU 尺寸確定器

使用此工具查找您的型號*全面刷新*的最低 SKU。

您的語義模型大小：5.0GB

所需的刷新內存：5.8GB

全面刷新的最低 SKU：F32

模塊 1：立即模型優化

在實施長期修復之前，您通常可以通過優化模型來獲得穩定性。這些步驟減少了基本內存佔用，使系統更容易處理所有操作（包括刷新）。

1.添加聚合表

如果您的模型查詢大型事實表，請通過 Direct Lake 或 DirectQuery 添加聚合表（匯總表）。這使得 Power BI 能夠從一個很小的匯總表中回答高級問題（例如“按月銷售”），只需訪問大量事實表即可獲取詳細信息。這會減少查詢內存。

2. 減少模型基數

基數（列中唯一值的數量）是內存使用的主要驅動因素。積極攻擊它：

• 刪除未使用的列：如果報表不使用列，請將其從模型中刪除。
• 正確的數據類型：不要對數字使用“文本”類型。確保盡可能使用整數。
• 禁用自動日期/時間：Power BI 的“自動日期/時間”功能為*每個*日期列創建隱藏表，從而使模型膨脹。關閉此功能並使用單個共享日期維度。
• 修剪高粒度密鑰：避免引入高基數密鑰，例如事務 ID 或基於文本的 GUID，除非關係絕對必要。

3. 控制刷新並發

不要安排所有數據集刷新同時運行（例如午夜）。錯開刷新窗口。同時運行多個大型刷新是耗盡容量內存並導致“資源管理”錯誤的最快方法。

優化目標：降低刷新和查詢操作期間的峰值內存使用量。這可以使您當前的 F32 容量保持健康，並為安全測試較小的 F16 容量創造必要的空間。

永久修復：增量刷新

依賴大規模的全面刷新成本高昂且效率低下。正確的長期解決方案是配置**增量刷新**。這僅處理新的或更改的數據，從而顯著減少日常操作所需的內存和時間。

全面刷新策略

每天晚上，系統需要 6 GB 內存來重新加載全部 2.9 GB 數據。

週一
星期二
週三
……

成本：*永久*需要大量昂貴的 F32 容量。

增量刷新策略

運行一次大型 F32 刷新*一次*。然後，每天的刷新量很小，並且在廉價的 F8 上運行。

第一的
星期二
週三
……

成本：支付一次 F32，然後縮減至 F8 以實現每日節省。

“加量和縮減”策略

1. 在 Power BI Desktop 中配置增量刷新。
2. 將您的結構容量擴展到所需的 SKU（例如 F32）。
3. 發布模型並執行*第一次*完整數據刷新。
4. 初始刷新完成後，*縮小*您的容量（例如，至 F8 或 F16）。
5. 安排每日的小規模增量刷新，以在更小、更便宜的容量上運行。

大型語義模型 (LSM) 的作用

對於任何超過 1 GB 的數據集，都需要啟用大型語義模型 (LSM) 格式。此功能改變了數據存儲和加載的方式。 LSM 不是將整個模型加載到內存中，而是使用按需分頁來僅加載查詢所需的數據。

雖然 LSM 對於性能和大型模型至關重要，但它不會更改“完全刷新”的 2 倍內存規則。您必須啟用 LSM *並*使用增量刷新策略才能獲得最佳結果。

模塊 2：結構化 SKU 測試計劃

實施優化和增量刷新後，您必須驗證正確的容量。不要猜測；使用結構化測試。您的目標是找到滿足您的性能和可靠性需求的“最小”SKU。

1. 第 1 步：F32 基準（您當前的 SKU）

   在進行任何更改之前，請使用“監控工具包”（請參閱​​下一節）捕獲 24 小時基線。運行 2-3 次類似生產的刷新和受控的查詢突發。記錄CPU峰值、內存峰值和刷新時長。這是你的“真相來源”。

2. 步驟 2：測試 F16（非高峰）

   在低流量窗口期間，將工作區切換至 F16。重新運行完全相同的工作負載（刷新和查詢突發）。密切監視指標應用程序是否存在“資源管理”錯誤或嚴重限制。

3. 第 3 步：分析 F16 結果

   更新是否在您的服務級別協議 (SLA) 範圍內完成？有失敗的經歷嗎？報表查詢性能是否可以接受？如果是的話，F16可能是縮小規模的候選者。

4. 步驟 4：測試 F64（可選淨空測試）

   如果您的 F32 基線顯示 CPU 或內存非常高（例如，>80% 峰值），請暫時測試 F64。這可以幫助您評估更大的容量是否可以顯著提高刷新速度或查詢並發性，這可能是值得的。

專業人士的監控工具包

你無法修復你無法衡量的東西。使用適合工作的正確工具。

基本的

中間的

先進的

面料指標應用程序

這是微軟提供的標準工具。這是監控總容量單位 (CU) 消耗、檢查限制以及查看如何將平滑應用於成本的最佳方式。

Azure 監視器日誌

Metrics 應用程序不適合跟踪*峰值內存*。為此，您必須使用 Azure Monitor 日誌。通過查詢“AzureDiagnostics”表，您可以找到您的容量和特定操作的真實“ActiveMemory”消耗。

SQL Server 探查器/DAX Studio

為了進行最深層次的分析，您可以將 SQL Server Profiler 或 DAX Studio 等工具連接到容量的 XMLA 端點。這允許您跟踪刷新期間消耗內存的特定 DAX 查詢、MDX 查詢和引擎操作。

第 3 單元：做出數據驅動的決策

測試後，使用監控數據作為單一事實來源。正確的 SKU 不在於感覺，而在於感覺。這是關於證據的。您的“最終 SKU”是滿足以下所有標準的 SKU：

最終 SKU 決策標準

• 刷新期間沒有“資源管理”錯誤。

• 刷新在目標窗口 (SLA) 內完成。

• 報告頁面呈現時間是可以接受的（例如，
  

• 容量指標顯示低或無限制/故障。

基於此證據，您可以自信地決定縮小規模至 F16、保留 F32，或升級至 F64。

相關策略：Fabric 與 Databricks

解決 Power BI 內存問題通常是第一步。接下來是優化您的數據工程 (DE) 工作負載。許多團隊考慮從 Azure Databricks 遷移到 Fabric 以創建統一平台。

這是一個需要權衡的戰略決策。 Databricks 是一個適合繁重 Spark 作業的成熟平台。 Fabric 提供統一的環境、無縫的 Power BI 集成（如 Direct Lake）和單一計費模型。

最好的方法是測試和基準測試。將一些代表性的 Databricks 筆記本遷移到 Fabric Workflows 中。比較運行時間、Metrics App 中的 CU 成本以及操作簡單性。這些數據（而不僅僅是假設）應該指導您的決策。