このページでは、よく発生する問題に対する解決策とガイダンスを提供します。このガイドは今後も拡充され、より幅広いシナリオを扱うトラブルシューティングトピックが追加されていきます。
Weave のトラブルシューティングに関する知見をコミュニティと共有しませんか?このガイドの一番下にある Edit this page をクリックして、プルリクエストを送信することで直接貢献できます。
Trace ページの読み込みが遅い場合は、表示する行数を減らして読み込み時間を短縮してください。デフォルト値は 50 です。行数は UI から変更することも、クエリパラメータを使って指定することもできます。
Traces ページ右下にある Per page コントロールを使って、表示する行数を調整します。既定値の 50 に加えて、10、25、100 に設定することもできます。
手動で調整したい場合は、クエリ URL 内の pageSize クエリパラメータを、上限である 100 未満の値に変更できます。
Weave では、同じクエリを繰り返し実行する場合や、利用できるネットワーク帯域幅が限られている環境でのパフォーマンスを向上させるために、サーバーレスポンスのキャッシュ機能を提供しています。現在はデフォルトで無効になっていますが、今後のリリースではこの機能がデフォルトで有効になる予定です。
サーバーからのレスポンスのキャッシュは次のような場合に特に有効です:
- 同じクエリを頻繁に実行する場合
- ネットワーク帯域幅が限られている場合
- 高レイテンシな環境で作業している場合
- オフライン環境で開発していて、後で使うためにレスポンスをキャッシュしておきたい場合
この機能は、データセットに対して繰り返し評価を実行する際に特に便利で、run 間でデータセットをキャッシュして再利用できるようにします。
キャッシュを有効にするには、次の環境変数を設定します。
# サーバーレスポンスのキャッシュを有効化する
export WEAVE_USE_SERVER_CACHE=true
# キャッシュサイズの上限を設定する(デフォルトは1GB)
export WEAVE_SERVER_CACHE_SIZE_LIMIT=1000000000
# キャッシュディレクトリを設定する(省略可能。デフォルトは一時ディレクトリ)
export WEAVE_SERVER_CACHE_DIR=/path/to/cache
技術的には、この機能ではサーバーに対する冪等なリクエストをキャッシュします。具体的には、次のリクエストがキャッシュ対象です:
obj_read
table_query
table_query_stats
refs_read_batch
file_content_read
キャッシュサイズは WEAVE_SERVER_CACHE_SIZE_LIMIT(バイト単位)で制御されます。実際に使用されるディスク容量は次の3つの要素で構成されます:
- 固定サイズの 32KB のチェックサムファイル
- 実行中のクライアントごとに最大約 4MB の Write-Ahead Log (WAL) ファイル(プログラム終了時に自動的に削除されます)
- メインのデータベースファイル(サイズは少なくとも 32KB、最大で
WEAVE_SERVER_CACHE_SIZE_LIMIT)
合計ディスク使用量は次のとおりです:
- 実行中 >= 32KB + 約 4MB + キャッシュサイズ
- 終了後 >= 32KB + キャッシュサイズ
たとえば、キャッシュサイズの上限を 5MB に設定した場合:
- 実行中: 最大約 9MB
- 終了後: 最大約 5MB
Weave UI では、大きなトレースデータが一部だけ表示されてしまうことがあります。この問題は、デフォルトのトレース出力が、Weave がシリアライズ方法を知らない生のカスタム Python オブジェクトであることが原因です。
大きなトレースデータが途中で切り捨てられないようにするには、文字列を値とする辞書を定義して、すべてのトレースデータを返すようにします。
import weave
class MyObj:
def __init__(self, x: int):
self.x = x
def __repr__(self):
return f"MyObj(x={self.x})"
def to_dict(self):
return {"x": self.x}
@weave.op()
def make_my_obj():
x = "s" * 10_000
return MyObj(x)
大規模なデータセットで評価を実行する際のパフォーマンスを向上させるには、次の 2 つの手法を併用してください。
大規模なデータセットで評価を実行する際、データセットがバックグラウンドスレッドでアップロードされている間、プログラムの実行が終了するまでに長い時間がかかることがあります。これは一般的に、バックグラウンドのクリーンアップが完了する前にメインスレッドの実行が終了してしまった場合に発生します。client.flush() を呼び出すと、すべてのバックグラウンドタスクがメインスレッドで処理されるようになり、メインスレッド実行中に並行して処理されることが保証されます。これは、ユーザーコードの処理がサーバーへのデータアップロード完了より先に終わってしまう場合に、パフォーマンスの改善につながる可能性があります。
例:
client = weave.init("fast-upload")
# ... 評価のセットアップ
result = evaluation.Evaluate(dataset_id="my_dataset_id")
client.flush()
クライアントの並列度は実行環境に応じて自動的に決定されますが、次の環境変数を使って手動で設定することもできます:
WEAVE_CLIENT_PARALLELISM: 並列処理に利用可能なスレッド数です。この値を増やすと、並列処理に利用できるスレッド数が増え、データセットのアップロードのようなバックグラウンドタスクのパフォーマンスが向上する可能性があります。
これは、weave.init() の settings 引数を使用してコードから設定することもできます:
client = weave.init("fast-upload", settings={"client_parallelism": 100})
[Errno 24]: Too many open files
このエラーは、開いているファイル数がオペレーティングシステムで設定された上限を超えた場合に発生します。Weave では、大きな画像データセットを扱っている場合に発生することがあります。Weave は画像処理に PIL を使用しており、プログラムの実行中はファイルディスクリプタを開いたままにします。
この問題を解決するには、ulimit を使用して同時に開けるファイル数のシステム上限を 65,536 に増やしてください。
Weave は、アプリケーションのパフォーマンスへの影響を最小限に抑えるため、バックグラウンドスレッドでトレースデータをアップロードします。しかし、マルチプロセス処理やタスクキューシステム、あるいは Celery のようなワーカープロセスを使用している場合、ワーカープロセスがバックグラウンドスレッドによるトレースのアップロード完了前に終了すると、トレースデータは失われます。
ワーカープロセスでのデータ損失を防ぐには、ワーカータスクが完了する前に client.flush() または client.finish() を呼び出し、バックグラウンドアップロードが完了することを保証する必要があります。
これらのメソッドは目的が異なります:
weave.flush(): シンプルで出力のないフラッシュ処理。Weave をワーカープロセスや CI 環境に統合している場合に推奨されます。
weave.finish(): 進行状況バーやステータスコールバックによる進捗フィードバックを含みます。対話的なスクリプトやノートブックに推奨されます。
どちらのメソッドも、すべてのバックグラウンドアップロードが完了するまでブロックするため、ワーカープロセスが終了する際にトレースデータが失われないことを保証します。
次の例は client.finish() の使用方法を示します:
from celery import Celery
import weave
app = Celery('tasks')
@app.task
def process_task(input_data):
weave.init("your-team-name/your-project-name")
try:
# トレースを作成するタスクロジック
result = your_processing_function(input_data)
# タスク完了前にすべてのトレースをアップロードする
weave.finish()
return result
finally:
pass
with 文のコンテキストマネージャーを使用して、終了時に自動的に weave.finish() を呼び出すこともできます。
with weave.init("your-team-name/your-project-name") as client:
result = your_processing_function(input_data)
return result
weave.flush() を使用すると、アプリケーションのパフォーマンスをさらに向上させることもできます。詳細は Flushing を参照してください。