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

Toolkit の使用速度が低下することがあります。速度が低下する理由はさまざまです。サーバ速度やインターネット接続などのクライアント側インフラストラクチャの問題、Toolkit や ShotGrid が高いパフォーマンスで実行されるように設定されていない設定ベースの問題、さらに最適化を行う余地があるコード上の問題などがあります。

次に、チェック項目のクイックリストを示します。これらのチェック項目については、以下で詳細に説明します。

アプリ、エンジン、フレームワーク、コア、ShotGrid Desktop が最新であることを確認します。
一般的な用途のときに、デバッグログが無効になっていることを確認します。
必要なフォルダのみを作成し、フォルダ数を制限して、実際に必要な場合に限りフォルダが作成されるようにします。スキーマにフォルダを追加しすぎると、速度が低下します。
サーバにユーザキャッシュを保存する、速度が低下することがあります。ユーザの ShotGrid キャッシュをリダイレクトするには、ローカルドライブ上の場所を指定するように ShotGrid_HOME の環境変数を設定します。
アーティストが必要としていないコンテンツを除外するように、作業ファイルおよびローダーアプリを設定します。ステータスを基準とするフィルタを実行して、エンティティリストを短くし、アーティストの現在のタスクに関連するエントリが表示されるようにします。
カスタムフックの有無を調べて、追加のオーバーヘッドがないか確認します。

次に、適切な方法と、速度が低下する一般的なシナリオを示します。このリストは、まだすべてを網羅するものではありません。新しいパターンが見つかったときに、適宜追加されます。このガイドを参照しても、現在発生している問題の根本的な原因が見つからない場合は、サポートチケットをお送りください。担当チームがサポートいたします。

一般的なお勧めの方法
ソフトウェアの起動速度が遅い
[File Open]、[File Save]、Loader アプリのいずれかで速度が低下する場合
フォルダ作成速度が低下する
- I/O 使用量を制御する
- フォルダを登録する

一般的なお勧めの方法

キャッシュの場所

ShotGrid Toolkit は、データをユーザのホームディレクトリにキャッシュします。このキャッシュには、さまざまな SQLite データベース、およびキャッシュされたアプリと設定を含めることができます。通常、ユーザのホームディレクトリはマシンのローカルハードドライブに保存されますが、スタジオでは、ネットワーク上のストレージにこれらをリダイレクトすることが一般的に行われています。この方法の場合、パフォーマンスが低下することがあります。特に大きな影響を受けるのが、ブラウザの統合やフォルダの作成/検索に使用される SQLite データベースです。

ユーザディレクトリがサーバ上の場所に保存されている場合は、ShotGrid_HOME の環境変数を使用して、ShotGrid Toolkit のキャッシュのパスを再設定することをお勧めします。ShotGrid_HOME 環境変数は、データおよびその他の項目の高速検索に使用されるバンドルキャッシュ、サムネイル、SQLite データベースなど、Toolkit がさまざまなデータをキャッシュする場所を設定する際に使用されます。

デバッグ

ShotGrid Toolkit でデバッグログを有効にして、さまざまなプロセスから詳細な出力を取得することができます。このようにすると、問題を診断するときに非常に便利です。ただし、デバッグ設定は、通常の日常的な用途のときは有効にならないように設計されています。ログの出力量が増えると、パフォーマンスが大幅に低下することがあります。

パフォーマンスの問題が発生した場合、特に、特定のマシンやユーザに限定された問題が発生する場合は、最初にデバッグログが無効になっていることを確認してください。

一元管理設定と分散設定

Toolkit の詳細設定は、一元管理設定と分散設定の 2 つの方法で行うことができます。主な違いは、一元管理設定は通常、スタジオのネットワークストレージに配置されていて、すべてのユーザがアクセスできることです。一方、分散設定は一般にクラウド内に保存されていて、ユーザ単位でローカルにキャッシュされます。

この 2 つの方法の違いはパフォーマンス以外にもありますが、パフォーマンスに関しては長所と短所の両面があります。次の表に、純粋にパフォーマンスの観点から見た長所と短所を示します。

	利点	欠点
一元管理設定	- 初期設定プロセスが完了すると、必要なすべてのものが既にダウンロードされていて、すべてのユーザが使用できる状態になっています。	- 一元管理設定は通常、ネットワークストレージに保存されるため、Toolkit の一般的な用途のときにパフォーマンスが低下することがあります。
	- 将来の更新は、一元管理された場所に 1 回ダウンロードするだけで済みます。	- Toolkit の設定には多数の小さなファイルが含まれています。多数の小さなファイルにメタデータ操作を行うと、処理速度が大幅に低下し、サーバの負荷が増大することがあります。また、Toolkit を使用する読み取り操作と、サーバの一般的な用途における読み取り操作の負荷が増大すると、設定をすばやく読み取ることができなくなって、Toolkit のパフォーマンスが低下することがあります。
分散設定	- キャッシュされたアプリ、エンジン、フレームワーク、およびコアは、他のローカルにキャッシュされた設定と共有できるような方法で保存されます。つまり、複数のプロジェクトを今後ロードするときに、これらが同じ依存関係を共有していれば、キャッシュ速度が上がる可能性があります。	- 分散設定はユーザ単位でローカルにキャッシュする必要があります。この操作を行うには、通常、設定、および必要なすべてのアプリ、エンジン、フレームワーク、コアをダウンロードします。
	- これらはローカルハードドライブ上のユーザキャッシュに保存されるため、通常はサーバ速度よりもパフォーマンスが向上します。つまり、最初のキャッシュ以降のパフォーマンスは一元管理設定よりも高くなります。	- このプロセスはシーンの背後でシームレスに行われますが、これらをダウンロードする初期コストがかかります。
		- 新しいバージョンの依存関係を指定するように設定を更新するたびに、設定と新しい依存関係の両方をキャッシュする必要があります。

手短に言えば、ストレージは低速だが妥当な速度のインターネット接続を使用している場合は、分散設定が最適な設定になる可能性がありますが、サーバストレージのパフォーマンスが高く、インターネットのパフォーマンスが低い場合は、一元管理設定が適している可能性があります。

分散設定を使用している場合、ユーザはキャッシュ内にまだ保存されていないデータのみダウンロードする必要があります。ユーザがデータをダウンロードすると、他のユーザもそのデータを利用できるようになります。このようにするには、各マシンの共有場所を指定するように、ShotGrid_BUNDLE_CACHE_PATH の環境変数を設定します。

ソフトウェアの起動速度が遅い

Maya、Nuke、Houdini などのソフトウェアを起動するときに、ShotGrid を使用しない場合に比べて起動時間が長くなることがあります。ShotGrid を使用しない場合に比べて起動時間が長くなるのは通常のことですが、これらの時間が許容できないレベルまで増大することがあります(ソフトウェアによって異なりますが、通常は起動時間が 1 分未満であると予測しています)。ソフトウェアの起動には多くのプロセスが関係しているため、この問題を診断するのは面倒なことがあります。

診断

最初に行う必要があるのは、この問題が発生する場合の条件を特定することです。

ShotGrid を使用しないで起動したときに低速になりますか? - 明らかなことかもしれませんが、ShotGrid を使用して起動した場合のみ問題が発生することを確認することが重要です。
起動方法に関係なく低速ですか? つまり、SG Desktop から起動した場合と、ブラウザ統合を使用して SG サイトから起動した場合で違いはありますか? - ShotGrid サイトから起動したときに低速になり、SG Desktop から起動したときに低速にならない場合は、ブラウザ統合に問題があるか、ディスク上にフォルダを作成するときに問題が発生している可能性があります。プロジェクト以外のコンテキストから起動した場合は、ディスク上に作成されるフォルダ数が増える可能性があるため、時間がかかることがあります。また、ソフトウェアが起動されるたびに、必要なフォルダの有無を確認することも重要です。
すべてのプロジェクトで発生しますか? - 問題が発生しないプロジェクトがある場合は、設定方法に固有の問題である可能性があります。
1 日の特定の時点で発生しますか? - 1 日の特定の時点で発生する場合は、1 日の特定の時間帯にサーバ使用量が増大しているなど、インフラストラクチャに対する要求が増加している可能性があります。
使用しているすべてのマシン/OS で発生しますか? - 特定のマシンの速度が低下する場合、問題の原因は Toolkit の外部にある可能性があります。ただし、最初の手順として、このマシンに Toolkit のキャッシュを作成することをお勧めします。ソフトウェアおよび Python パッケージごとに異なるバージョンの OS が付属していて、特定のバンドルでパフォーマンスの問題が発生することがあります。特に、Windows で Samba (SMB)共有を使用している場合に、パフォーマンスの問題が発生するケースが見られます。このような問題の修正プログラムはありませんが、これを使用する場合にこの問題を認識することが大事です。この問題が特定の OS、Python パッケージ、またはソフトウェアバージョンに限定されていると判断される場合は、サポートチームに問い合わせてさらに調査するよう依頼してください。
すべてのユーザで発生しますか? - 上記と同様に、同じマシンを使用している別のユーザでは、この問題が発生しないことがあります。この場合は、まずユーザのローカル ShotGrid キャッシュをクリアします。また、通常のプロダクションでの用途に対してデバッグログが有効になっていないことを確認してください。パフォーマンスが低下しなくなります。
起動速度の低下は特定のアプリ/ソフトウェアに特有のものですか、それともすべてのアプリ/ソフトウェアで起動速度が異常に低下しますか? - 特定のソフトウェアの起動速度が低下する場合は、設定に問題がある可能性があります。起動の前後に実行されるようにカスタムフックが設定されていて、パフォーマンス低下の原因となっている可能性があるかどうかを確認することをお勧めします。起動時に使用される一般的なフックは before_app_launch.py、app_launch.py、およびコアフックの engine_init.py です。ときどき、新しいバージョンのソフトウェアがリリースされ、Toolkit の統合の起動速度が突然大幅に低下することもあります。このような場合は、サポートに問い合わせて、この問題が認識されているかどうか、および既知の修正プログラムがあるかどうかを確認する必要があります。使用しているソフトウェア(パッチ/サービスパックが適用可能な場合は、これらを含む)のバージョン番号、および実行している Toolkit エンジンとコアのバージョンをお知らせください。

問題が発生するタイミング(起動前または起動後)

上記の手順を行っても原因を絞り込むことができなかった場合は、次に、起動プロセスのどの段階で速度が低下するのかを確認します。Toolkit を介してソフトウェアを起動している場合は、一般に起動プロセスを 2 段階のプロセスにまとめることができます。

最初の手順では、いくつかの初期操作を実行します。たとえば、ソフトウェアの起動に必要な情報を収集したり、コンテキストからフォルダを自動的に作成し、その後でソフトウェアを実際に起動したりします。次に、起動プロセスの 2 番目の手順が行われ、ソフトウェアの起動後に Toolkit の統合が起動されます。

通常は、ログを調べなくても、プロセスの最初の手順と 2 番目の手順のどちらでパフォーマンスの問題が発生しているのかを確認できます。

そのためには、ソフトウェアのスプラッシュ画面を観察して、この画面の起動時間が長いかを確認します。スプラッシュ画面の起動時間が長い場合は、問題が最初の手順で発生している可能性があります。
また、ソフトウェアの起動時間が比較的短いにもかかわらず、初期化が終了して ShotGrid メニューが表示された後に速度が低下することがあります。この場合は、2 番目の手順で問題が発生しています。

この情報を把握しておくと、この次の作業でログを確認する際に役立ちます。

ログを調べる

起動の最初の手順または 2 番目の手順のどちらで問題が発生しているのかを確認したら、調査対象のログを特定することができます。ログはエンジンごとに分かれているため、問題が起動前の段階で発生している可能性がある場合は、SG Desktop から起動しているのか、それとも SG サイトから起動しているのかに応じて、tk-desktop.log または tk-ShotGrid.log を調べる必要があります。

次に、デバッグログを有効にする必要があります。

デバッグログを有効にしたら、既存のログをクリアして、起動プロセスを再現する必要があります。ログ内のタイムスタンプを使用して、時間が急に変化している行を確認します。

たとえば、フォルダの作成中に、時間が 5 秒間突然変化している行がいくつかあります。

2019-05-01 11:27:56,835 [82801 DEBUG sgtk.core.path_cache] Path cache syncing not necessary - local folders already up to date!
2019-05-01 11:28:01,847 [82801 INFO sgtk.env.asset.tk-shotgun.tk-shotgun-folders] 1 Asset processed - Processed 66 folders on disk.

時間が急に変化している場所を特定したら、そのログの行を調べると、その段階で何が起こっていたのかを把握することができます。たとえば、フォルダの作成中や、ShotGrid の接続の取得中に問題が発生していることがあります。

ただし、ログを参照するのは面倒な作業であり、内容に意味があるとは限らないため、サポートに問い合わせて、この作業のサポートを依頼することができます。

ソフトウェアの起動速度が低下する一般的な原因

インターネットの速度低下	Toolkit のほぼあらゆる使用状況において ShotGrid サイトに接続して通信する必要がありますが、インターネットの速度が低下すると、この動作が影響を受けます。この場合は通常、ソフトウェアの起動だけでなく、他の状況においても、速度に関する問題が発生します。ただし、接続速度が低下するのではなく、接続が不安定になる場合は、起動時にパフォーマンスの問題が生じる可能性があります(大量の ShotGrid 通信がプロセスを通して行われるためです)。
サーバアクセス速度の低下	この問題は確実に起動時間に影響します。一元管理設定を使用している(設定が中央サーバに保存されている)場合は、設定ファイルを読み取るときに大量の I/O が発生することがあります。特に、ソフトウェアを起動すると、起動時の状況に応じてフォルダが作成されます。つまり、フォルダが作成されているかどうかが確認され、作成されていなければ作成されます。
フォルダの作成	上記のように、フォルダ作成が速度低下の一般的な原因になることがあります。詳細については、以下のフォルダ作成時のパフォーマンスに関するトラブルシューティングを参照してください。

[File Open]、[File Save]、Loader アプリのいずれかで速度が低下する場合

最初に、問題となっているアプリの速度が低下する状況を絞り込んで、特定します。

アプリを起動するときに速度が低下しますか、それともタブ間で移動するときに低下しますか?
- アプリは現在、極端に多くの情報を表示するように設定されている可能性があります。[マイタスク] (My Tasks)タブやその他のタブは、リスト内の不要なエンティティ除外するように設定できます。たとえば、[保留中] (On Hold) (hld)や[最終] (Final) (fin)などの特定のステータスを持つタスクを除外できます。このようにすると、パフォーマンスが向上するだけでなく、アーティストは自分が必要としている情報のみを表示することができます。Loader アプリと Workfiles アプリの両方を除外できます。Workfiles には現在、フィルタに関する特定のドキュメントセクションが用意されていませんが、階層設定中にフィルタを適用することができます。
- File Open アプリの階層を、この階層が展開されるまでサブ項目のロードを遅らせるように設定することもできます。これが既定の設定になっていますが、古い設定を使用している場合は、この設定を使用するように移行することができます。
- デバッグログが有効になっていないことを確認します。デバッグログが有効になっていると、追加の I/O が大量に発生するため、速度が低下することがあります。これらのアプリには、大量のデバッグ出力が含まれています。
ファイルを開く、保存する、または新規作成するときに速度が低下しますか?
- シーンの操作やアクションのフックを引き継いで処理したかどうか、およびこれらの関数の前後に速度低下の原因となるカスタム動作が行われているかどうかを確認します。
- ファイルを作成するときや、保存するときに、Workfiles はこのコンテキストに必要なすべてのフォルダが作成されていることを確認します。パフォーマンスの問題が発生する一般的な原因は、フォルダの作成です。

フォルダ作成速度が低下する

フォルダの作成は多くの要素で構成されていて、問題が発生したときに処理速度が低下する原因となることがあります。

フォルダの作成では、次の処理が行われます。

ローカルパスキャッシュを同期する
設定のスキーマを読み取る
状況に応じて作成する必要があるパスのリストを生成する
ローカルに保存されたパスレジストリと比較してパスを確認する
SG サイトとローカルな場所の両方に新しいパスが登録されていない場合は、登録を試みる
フォルダの登録の有無に関係なく、このフォルダがディスク上に実際にあるかどうかを確認し、存在しない場合は作成する

つまり、フォルダを作成すると、ディスクの I/O 使用量が大幅に増えるとともに、ローカルデータベースへの書き込みと SG サイトとの通信が必要になります。

I/O 使用量を制御する

多数の小規模な読み取り/書き込み操作を処理するときに、ストレージの速度や効率が低下することがあるため、インフラストラクチャの効率化に役立つ手順を行うと、フォルダ作成の処理時間を短縮できます。ただし、できるだけ負荷を軽減するために Toolkit 設定側で試行できる手順があります。

最初に行うのは、この状況、および作業中の環境にとって重要なフォルダのみが作成されるように制限することです。たとえば、Maya でタスクやショットを操作している場合は、特定のショットおよびソフトウェアのフォルダのみを確認して、作成することが理想的です。

基本的に、作品を保存およびパブリッシュするのに最低限必要なフォルダを作成するようにします。

親フォルダを使用して作成する

スキーマフォルダに適用できる create_with_parent設定があります。これを true に設定すると、フォルダが親フォルダであるときにそのフォルダが作成されるようになります。この設定を true に設定するときは、多数のフォルダが確認および作成されるという状況にならないように注意してください。

例

シーケンス/ショットのフォルダ階層がある場合に、親のシーケンスを使用して作成するようにショットフォルダを設定すると、シーケンスフォルダを作成するときはいつでも関連するすべてのショットが確認され、これらのフォルダが作成されるようになります。

状況によってはこの方法が便利なことがありますが、多数のフォルダの確認と作成が一度に行われることがあります。このシナリオで、タスクまたはショットの作業ファイル内に新しいファイルを作成すると、ショットの親となるシーケンスフォルダが作成され、作業中のショットだけでなく、この子となるすべてのショットフォルダが作成されます

作成の遅延

defer_creation 設定により、特定のエンジンが実行されている場合に限ってフォルダが作成されるように制限することで、フォルダの作成時期を調整することができます。カスタム名を使用し、sgtk API を使用してこの名前のフォルダが作成されるようにすることもできます。

例

場合によっては、一連のフォルダの作成時期をパブリッシュ段階に限定する必要があります。この場合は、カスタム名を maya_publish という遅延キーワードに設定し、その後で API を使用してこのキーワードをエンジン名として持つフォルダを作成することができます。スキーマ内のフォルダは次のようになります。

# the type of dynamic content
type: "static"
# defer creation and only create this folder when Photoshop starts
defer_creation: "publish"

その後、次のようなスクリプトを使用してフォルダを作成します。

sgtk.create_filesystem_structure(entity["type"], entity["id"], engine="publish")

拡張された例

フォルダを遅延することにした場合、プロジェクトのルートに動的でないフォルダが複数あれば、通常はこれらを 1 回のみ作成する必要があります。たとえば、「editorial」および「reference」フォルダが既定の設定のスキーマのルートに配置されている場合は、通常、プロジェクトの開始時にこれらのフォルダを 1 回だけ作成しなければならないことがありますが、既定では、フォルダ作成を行うたびにこれらのフォルダの有無が確認されます。

この動作を制限するには、これらのフォルダの yml ファイルを作成して遅延キーワードを設定し、フォルダの作成が特定のエンジンで実行された場合、またはキーワードが渡された場合のみ、これらのフォルダが作成されるようにします。遅延キーワードを tk-shell に設定して、tank folders のような tank コマンドを使用してフォルダ作成を実行することができます。

これは、これらのフォルダ作成が tank コマンドを介して実行された場合に限り実行されることを意味します。tank コマンドは、プロジェクトを初めて設定するときに Toolkit 管理者が実行することができます。また、上の例のようなカスタムキーワードを使用してフォルダ作成を実行する、小規模なスクリプトを記述することもできます

フォルダを登録する

フォルダ作成プロセス中にフォルダが登録されるため、後でコンテキストを調べる際に登録されたパスを使用することができます。上記のように、この処理中に、レジストリが保存されている一元的な場所である ShotGrid サイトと通信する必要があります。ただし、ツールによる高速検索を有効にするために、これらのレジストリもローカルにキャッシュされます。

SQLite データベース

ローカルなパスキャッシュは SQLite データベースを使用してデータを保存します。ネットワーク上のストレージにデータベースが保存されている場合は、データベースに対する読み取りおよび書き込みのパフォーマンスが大幅に低下することがあります。

初期同期

プロジェクトに多数のフォルダが登録されている場合は(進行中のプロジェクトに新しいユーザが参加する場合など)、状況に応じて、ローカルキャッシュをゼロから生成しなければならないことがあります。この処理には非常に長い時間がかかることがあるため、このようなプロジェクトにはこの処理が 1 回だけ行われるように効率化されました。

以降の同期では、ローカルキャッシュとサイトのレジストリの間の差分のみが取得されます。ユーザがプロジェクトを操作する頻度が少なく、セッションの合間に多数のフォルダが作成されている場合は、すべてのデータをキャッシュする間の待ち時間が非常に長くなることがあります。

この場合にユーザが使用してきた方法の 1 つは、ローカルキャッシュの最新と見なされるバージョンをユーザのマシンに転送することでした。

この更新プロセスは、コアフック cache_location.py を使用して自動的に実行できます。このフックを使用してキャッシュの場所を設定できますが、場所を変更しなくても、このフックを使用して path_cache.db ファイルの特定のバージョンを一元管理された場所からユーザの既定の場所にコピーして、負担のかかる完全同期を不要にすることができます。

一元的に保存されたパスキャッシュを定期的に更新するには、他のユーザのキャッシュから手動でコピーすることができますが、通常はスクリプトを使用して定期的に転送します。