一般的なパフォーマンスの問題のトラブルシューティング

6 分

個々の最適化手法は価値がありますが、実際のパフォーマンスの問題が 1 つのカテゴリにきちんと収まることはほとんどありません。遅いレポートには、DAX の問題、カーディナリティの問題、ビジュアルデザインの問題が一度に発生する可能性があります。体系的なトラブルシューティングアプローチは、問題を効率的に見つけて修正するのに役立ちます。

体系的な診断ワークフローに従う

レポートが遅い場合は、次の 3 段階のアプローチを使用します。

ビジュアル、DAX、またはデータですか? パフォーマンスアナライザーを開き、キャッシュをクリアして、すべてのビジュアルを更新します。 DAX クエリ、ビジュアル表示、およびその他のタイミングメトリックを比較して、時間が費やされた場所を決定します。
根本原因を特定します。 低速な DAX クエリをコピーし、DAX クエリビューで実行します。クエリの速度が速くてもビジュアルが遅い場合、問題はレンダリングです。クエリがどこでも遅い場合、問題はメジャーまたはデータモデルです。
修正して確認します。 適切な修正プログラムを適用し、パフォーマンスアナライザーをもう一度実行して、パフォーマンスが向上したことを確認します。修正が機能したと想定しないでください。それを測定してください。

このワークフロー (症状→診断→修正→検証) により、間違った問題に時間を費やすことがなくなり、変更が実際に役立つかどうかを確認できます。

ベストプラクティスアナライザーを実行して一般的な問題をキャッチする

ベストプラクティスアナライザー (BPA) は、パフォーマンス、DAX 式、エラー防止、およびメンテナンスに対応する 60 を超えるルールのセットに対してセマンティックモデルをチェックします。 BPA は、すべての列とメジャーを手動で検査する代わりに、モデル全体をスキャンし、未使用の列、高カーディナリティキー、不足している説明、非効率的な DAX パターンなどの問題にフラグを設定します。

Microsoft Fabricでは、BPA は、Power BI サービスのセマンティックモデルから直接開くことができるサンプルノートブックを通じて利用できます。セマンティックモデルを選択し、[ ホーム ] リボンまたは [モデルの正常性 ] ドロップダウンから BPA ノートブックを選択します。ノートブックはセマンティックリンクを使用してモデルに対して実行され、分類された推奨事項が返されます。コンパニオン Memory Analyzer ノートブックには、テーブル、列、リレーションシップのストレージ統計が表示されます。

BPA は、パフォーマンスの問題が発生する前の予防的なチェックとして最も役立ちます。モデルを構築または大幅に変更した後に実行し、結果を使用して、このモジュールで前に説明した最適化手法をガイドします。

Note

Fabricにアクセスできない場合は、テーブルエディター (サードパーティの外部ツール) に、Power BI デスクトップモデルまたは XMLA エンドポイントを介して発行されたモデルに対して同じルールセットをローカルで実行する BPA 機能が含まれています。

複雑なビジュアルに対処する

多すぎるデータを要求するビジュアルは、一般的なパフォーマンスの問題です。レポートページ上の各ビジュアルはセマンティックモデルに個別の DAX クエリを送信し、多くのメジャー、データポイント、またはクロスフィルター依存関係を持つビジュアルは複雑なクエリを生成します。

視覚的なパフォーマンスに関する一般的な問題:

1 つのビジュアルで指標が多すぎます。 20のメジャーを持つテーブルビジュアルは、大規模で複雑なクエリを生成します。指標の数を減らすか、情報を複数のビジュアルに分割します。
データポイントが多すぎます。 個々のポイントが 100,000 個の散布図または 50,000 行のテーブルは、レンダリングに時間がかかります。上位 N 個のフィルターを適用して、返される行を制限します。
1 ページのビジュアルが多すぎます。 各ビジュアルは、クエリを個別に送信します。 30 個のビジュアルを含むページは、読み込み時にモデルに 30 回クエリを実行します。ドリルスルーページとツールヒントを使用して、すべてを 1 ページに詰め込むのではなく、ページ間で情報を配布します。

ヒント

一般的なガイドラインとして、レポートページごとに 8 つ以下のビジュアルを目指します。それ以上に読み込み時間が長くなり、レポートの使用が困難になります。

不適切に設計されたリレーションシップを修正する

リレーションシップの設計は、エンジンがテーブル間のフィルター伝達を解決する方法に影響します。注意すべき問題:

あいまいなリレーションシップパス。 2 つのテーブル間の複数のアクティブなパスは、エンジンが使用するパスを決定することを強制します。これにより、予期しない結果とパフォーマンスのオーバーヘッドが発生する可能性があります。代替パスが必要な場合は、メジャーで単一のアクティブなリレーションシップと USERELATIONSHIP を使用します。
双方向のクロスフィルター処理。 双方向リレーションシップは両方向にフィルターを伝達するため、クエリ評価の複雑さが増します。多対多リレーションシップなど、必要な場合にのみ双方向フィルター処理を使用します。
高カーディナリティのリレーションシップ列 数百万もの一意の値 (GUID など) を持つ列のリレーションシップは、カーディナリティの低い列のリレーションシップよりも走査に時間がかかります。可能であれば、代わりに整数サロゲートキーを使用します。

フィルターコンテキストの問題を解決する

コストの高いフィルター伝達では、メジャーロジック自体が単純な場合でもクエリが遅くなる可能性があります。次のパターンに注意してください。

大きなテーブルの REMOVEFILTERS または ALL。 これらの関数はフィルターコンテキストを削除します。つまり、エンジンは制限なしでテーブル全体を評価する必要があります。これらを意図的に使用し、必要なスコープでのみ使用します。
大規模なブリッジテーブルを持つ多対多リレーションシップ。 各クエリは、ブリッジテーブルを介してマッピングを解決します。データが大きい場合、このプロセスはコストがかかります。別のモデリングアプローチ (ロールプレイングディメンションや統合テーブルなど) のパフォーマンスが向上するかどうかを検討します。

DirectQuery のパフォーマンスのトラブルシューティング

セマンティックモデルで DirectQuery ストレージモードが使用されている場合、DAX エンジンではなく外部データソースからパフォーマンスが低下する可能性があります。 DirectQuery 固有の問題は次のとおりです。

クエリの折りたたみエラー。 Power Queryは、変換をデータソースにプッシュバックしようとします (クエリフォールディング)。変換がフォールドできない場合は、Power BI生データをダウンロードし、ローカルで処理します。この方法は、はるかに遅くなります。 Power Queryのネイティブクエリを確認して、折りたたみを確認します。
ソースクエリが遅い。 クエリフォールディングが機能する場合でも、インデックスの欠如、大きなテーブルスキャン、またはリソースの競合による遅延が原因で、ソースデータベースでクエリの実行が遅くなる可能性があります。データベース管理者と協力して、ソースのパフォーマンスを最適化します。
ラウンドトリップレイテンシ. 各ビジュアル操作は、データソースにクエリを送信し、応答を待機します。ネットワーク待ち時間とソース応答時間は、特に多くのビジュアルを含むページでは顕著に加算されます。概要データのインポートと詳細データ用の DirectQuery を使用した混合ストレージモードを検討してください。

DAX Studio を使用してより詳細な診断を行う

パフォーマンスアナライザーと DAX クエリビューは、ほとんどのトラブルシューティングシナリオを処理します。エンジンレベルの詳細 (数式エンジンやストレージエンジンでクエリがボトルネックになっているかどうかなど) が必要な場合は、DAX Studio によってギャップが埋められます。パフォーマンスアナライザーから低速の DAX クエリをコピーし、DAX Studio に貼り付け、 サーバーのタイミング で時間が費やされた正確な場所を確認できるようにします。 クエリプラン ビューでは、タイミングデータだけでは表示されない非効率的な操作も表示される場合があります。

Note

SQL Server Profiler は、セッション中にすべての DAX クエリと DirectQuery SQL クエリの完全なトレースをキャプチャするためのもう 1 つのオプションです。 Power BI Desktop が実行されているローカルの Analysis Services インスタンスに接続します。プロファイラーはセッション全体の分析に役立ちますが、ほとんどのビジュアルレベルのトラブルシューティングでは、パフォーマンスアナライザーと DAX Studio の方が実用的です。

トラブルシューティングチェックリストを作成する

低速レポートを調査する場合は、次のチェックを順番に実行します。

キャッシュをクリアし、パフォーマンスアナライザーを実行します。最も遅いビジュアルとそのボトルネックのカテゴリを特定します。
DAX クエリ時間が長い場合は、DAX クエリビューまたは DAX Studio でクエリをコピーして分析します。大きなテーブル、イテレーター、繰り返しのサブ式に対する FILTER などの高価なパターンを探します。
ビジュアルの表示時間が長い場合は、メジャー、データポイントの数を減らすか、フィルターを適用してビジュアルを簡略化します。
キー列のカーディナリティを確認します。不要なカーディナリティの高い列を削除または減らします。
DirectQuery モデルの場合は、クエリの折りたたみとソースのパフォーマンスを確認します。
各変更の後、もう一度測定して改善を確認します。

この構造化されたアプローチにより、最も影響の大きい問題に最初に対処し、針を動かさない変更に時間を費やさないようにすることができます。

フィードバック

このページはお役に立ちましたか?