テクテク日記

テクテク=テクノロジー&一歩ずつ(テクテク)

Power BIと物理メモリ②

前回は物理メモリ及びページングに関する概念を解説しました。今回はページングされているメモリの特定方法について見ていきたいと思います。

タスクマネジャーの使用

メモリを確認する方法はいくつかありますが、最も簡単な方法はタスクマネジャーを起動することです。

Ctrl + Shift + Esc

でタスクマネジャーを起動し、「詳細」をクリックして展開。

「オプション」 > 「常に手前に表示」

これでタスクマネジャーは常に手前に表示されるようになるため、Power BI Desktopを立ち上げた状態でもメモリの確認がしやすくなりました。続いてメモリの部分で並び替えを行うと、メモリが高いアプリケーションの順に並び替えをしてくれます。

Power BI実行ファイルの確認

ここで各プロセスについて確認してみます。Power BI Desktopが立ち上がった状態でファイル名が入っているプロセスを右クリック > 「プロパティ」。こちらはアプリケーションの実行用ファイルとなっています。

Power Queryエンジンの確認

続けてMashup Evaluation Container(Power Queryエンジン)を見ると、下図のように一個だけ出現しています。Power BI Desktopを新規で立ち上げた場合、出てこない可能性もありますが、Power Queryエディタを開くと当該プロセスが見えるようになります。

念のため、データモデル全体を更新した場合、下図のように複数のMashup Evaluation Containerが出現します。

なお、一度に読み込むクエリが多い場合、下図のように非常に多くのプロセスが出現しますが、重要なことはプロセスの数よりもメモリ総量であり、1つのメモリが数百MBで連続している場合、元のクエリを見直すか、メモリ増設等の検討を始めると良いでしょう。

ここでの留意点は以下の通り。

  • Power QueryのクエリはMashup Evaluation Containerと呼ばれる別のプロセスで実行され、このプロセスで使用できるメモリ量には制限がある

  • 同時評価の最大数はマシン上の論理 CPU コア数と同じであり、最小が1、最大がマシン上の論理 CPU コア数となる

    Desktopの同時評価コア数 - Power BI | Microsoft Docs

  • 同時評価別に使用される最大メモリは規定の割り当てでは432MB(最小1MB、256MB以上を推奨)であり、マシーンのRAMの90%より高く設定しないことがベストプラクティス(=あまり高く設定しすぎると逆にパフォーマンスが落ちる可能性あり)

    DesktopのRAM割り当て - Power BI | Microsoft Docs

  • RAMの割り当てはレジストリーを変更することになるが、設定された結果はPower BI Desktopでしか機能しません(=Power BI Serviceでは機能しないため、Service側で更新設定をしても更新のパフォーマンスが改善されない)
  • Power Queryエディタにあるデータのプレビューに使用されるキャッシュはメモリ上にバッファされ、クエリがクリックされた場合に結果を素早く表示してくれる。ただし、大きなデータセットの場合、処理が負担となり、「バックグランドでのプレビューのダウンロード」をOFFにしたほうが良い(下図)

このあたりはテクニカルな話になってきますので、興味ある方はぜひChrisさんのブログから確認してみてください。

最後の箇条書きについて、Power BI Desktopから「ファイル」>「オプションと設定」>「オプション」より、下図の通りに設定します。

ご参考までに、Excelの場合でもデータを更新すると同じプロセスが出現します。

メモリ・CPUプロセスの確認

データを更新すればMashup Evaluation Containerが増えることを確認できましたが、メモリについては全く変化がないように見受けられます。データ量が少ない(18MB)というのが原因だと思いますが、すでにメモリにデータが読み込まれていることも関係している可能性があります。

一方、CPUの動きをみると、処理が入るため一瞬だけスパイクとなっていることが確認できます。

WebView2の確認

WebView2ですが、Webコンテンツの表示、UI・ビジュアルのレンダリング等を機能させるためのプロセスとなります。こちらもプロセスを右クリック > 「プロパティ」で確認できます。

なお、右クリック > 「詳細の表示」をクリックした場合、右側にある「詳細」タブに飛ばされ、アプリケーションではなく、プロセスだけのウィンドウが出現します。「詳細」タブにあるプロセス名を見たほうが実行オブジェクトを確認できて便利ですが、対象オブジェクトを探すのが難しくなります。

Analysis Servicesの確認

最後にAnalysis Servicesの確認を行います。

Analysis Serviceの詳細名称はmsmdsrv.exeであり、覚えておくとよいでしょう。

コミットサイズとメモリ(アクティブな...)

いよいよページングを特定することになりますが、タスクマネジャーの詳細タブでは以下の項目を見ていきます。「詳細」タブより、下記①~⑥の手順でこれらの項目を表示していきます。

  • コミットサイズ
    バーチャルメモリを含む、プロセスに必要なメモリ

  • メモリ(アクティブ…)
    上限があり、規定のメモリを超過した場合、ページングを行う

  • ページング
    コミットサイズとメモリ(アクティブ...)の差

メモリ(アクティブ…)の正式名称は「メモリ(アクティブなプライベート ワーキング セット)」ですが、非常に長ったらしいので、ここではメモリ(アクティブ…)として表現します。

上記説明の通り、コミットサイズはそのプロセスを走らせるために必要なメモリで、バーチャルメモリを含みます。一方、メモリ(アクティブ...)は上限が設定されているメモリ(Mashup Evaluation Containerの例)と認識していただくと分かりやすいかと思います。

以下、Chrisさんのブログから引用したチャート(クエリ開始後の経過時間とコミット・ワーキングセットのサイズ)ですが、こちらを見れば仕組みが理解しやすいかと思います。

Chris Webb's BI Blog: Monitoring Power Query Memory Usage With Query Diagnostics In Power BI Chris Webb's BI Blog

※ ここでは「上限がある」と説明をしましたが、全てのプロセスでそのようなキャップがあるかどうか確認していませんので、あくまで説明用としてお考えください

ここでPower BIの各プロセスに必要なメモリを比べてみます。

これが意味するところは「必要メモリがほぼRAMでカバーされている(ページングがほぼ発生していない)」と想定することができます。それもそのはず、デモに使用したPCは先日購入した32GBのハイスペック・ノートPCとなっているからです。

しかし、これは言い換えれば、

スペックの低いPCはRAM不足になりがちであり、ページングの発生によりPower BI Desktopのパフォーマンスが著しく遅くなってしまう可能性がある

ことを意味しています。Power BI Desktopでストレスなくデータモデルを作り、最高のパフォーマンスが期待できるレポートを構築するには、やはりスペックの高いPCで作業することが良いでしょう。

別のアプリ(Snagit)を見てみましょう。Snagitは有名なキャプチャソフトですが、このツールを見ると、かなり大きなページングが発生しているように見えます。

ツールが違うので何とも言えないですが、アプリを使っていない場合、使用しなくてもよいメモリは意図的に解放する等、Windowsが最適化してくれているのかもしれません。ただ、これをPower BIに置き換えた場合、例えば以下のケースではRAMの増強等を行う必然性が高まってきます。

  • Power BI Desktopを使うにあたり、コミットサイズとメモリ(アクティブ…)との間に大きな隔たりがあった場合 (例: 数GB等)、メモリ増強が推奨される
  • 複数のアプリを多く立ち上げており、他のアプリを使った後、Power BI Desktopに戻ると、メモリ不足に陥ってしまう場合
  • メモリ(アクティブ…)がゼロで、コミットサイズが1〜2GBの時、スペックの低いマシーンでは常にページングが発生している可能性がある
  • WebView2でコミットサイズとメモリ(アクティブ…)との間に数百MBの乖離が発生している場合(レポートを見るのにレンダリング時間が長い可能性大)

これらはPower BI Desktopの作業パフォーマンスを悪化させ、使い勝手を悪くしてしまうリスクが高い。なお、これら以外には例えば以下のケースでもメモリ不足によるパフォーマンス低下が心配されます。

  • 重い作業が必要なPower Queryクエリ
    Power Queryで行う並び替え、グループ化、ピボット化/ピボット解除等はメモリに全て読み込んで作業を行うため、RAM使用量が上昇する
  • 非効率なモデリングDAX式で作ったメジャー
    列フィルターではなくテーブルフィルターを使った場合、Iterator関数(例:SUMX、FILTER等)の中でContext Transitionを意図せず発生させた場合等、ビジュアルを表示させるのに多大な時間がかかってしまう
  • 多すぎるビジュアル
    個別のビジュアルのパフォーマンスが早くとも、大量のビジュアルを同じページに配置した場合、レンダリングタイムといった更新待ちが発生し、結果として全てのビジュアルを表示するまでに時間がかかってしまう

これらの項目はRAMが充分である場合、Power BI Desktopで結果が素早く表示できる可能性もありますが、Power BI Serviceへレポートを発行してから、レポート表示・操作のパフォーマンスが思わしくない可能性があります。

まとめ

RAM(メモリ)とPower BIの関係について見てきましたが、物理メモリとバーチャルメモリについての理解をしておくことは重要です。Power BIの全てのプロセスをRAMで全て処理できれば良いですが、そうでない場合、ページングが発生し、パフォーマンスの低下が懸念されます。

これに対する解決法としてコミットサイズとメモリ(アクティブ...)をよく確認し、

  • メモリの増強
  • スペックの高いマシーンに買い替える
  • モデリング及びDAX式の最適化
  • Power QueryであればMashup Evaluation Containerで使用できる最大RAMを変更
  • 他に使用しているアプリケーションを閉じる

等が挙げられますが、自分のニーズ・予算に合わせると良いでしょう。また、Power BI Desktopだけでテストするのではなく、Power BI Serviceに発行したレポートもテストすることが肝要です。これにより、快適なレポート閲覧環境が構築できる可能性が高くなります。