トラブルシューティング

このページでは、Cloud Profiler の問題を解決する方法について説明します。

Google Cloud プロジェクト構成のエラー

このセクションでは、発生する可能性がある構成に関する問題と、各問題の修正方法のヒントを示します。

Cloud Profiler API が無効

Google Cloud プロジェクトで Profiler API が有効になっていない場合は、次のエラーが発生します。

failed to create a profile, will retry: rpc error: code = PermissionDenied
desc = Cloud Profiler API has not been used in project 012345 before or it is disabled.

この問題を解決するには、 Google Cloud プロジェクトで Profiler API を有効にしておく必要があります。

1. Enable the required API.

   Enable the API

2. [API が有効です] が表示されている場合、API はすでに有効になっています。そうでない場合は、[有効にする] ボタンをクリックします。

呼び出し元に権限がない

Google Cloud プロジェクトにプロファイリング データを書き込む権限がない場合は、次のエラーが発生します。

failed to create a profile, will retry: rpc error: code = PermissionDenied
desc = The caller does not have permission.

この問題を解決するには、そのプロジェクトに対する追加の権限を付与するよう管理者に依頼してください。必要な権限とロールの詳細なリストについては、アクセス制御をご覧ください。

Node.js でのエラー

このセクションでは、Node.js プロファイリング エージェントの使用時に発生する可能性のある問題と、各修正方法のヒントを示します。

Node.js でアプリケーションが正常に終了しない

Node.js のプロファイリング エージェントが原因でプログラムが通常どおり終了しません。プログラムのすべてのタスクが完了してからプログラムが終了するまでに、最大で 1 時間ほどかかります。

この問題を解決するには、SIGINT シグナルを発行します（たとえば Ctrl-C を使用します）。SIGINT シグナルを発行すると、プロセスは正常に終了します。

Python でのエラー

このセクションでは、Python プロファイリング エージェントの使用時に発生する可能性のある問題と、各修正方法のヒントを示します。

Python での NotImplementedError 例外

Linux 以外の環境でアプリケーションを実行すると、start 関数の実行時に次の例外がスローされます。

NotImplementedError

この問題を解決するには、Linux 環境でアプリケーションを実行します。

Python での ValueError 例外

以下の例外は、関数の引数が無効な場合、環境変数と引数から必要な情報が特定できない場合、または CPU 時間プロファイリングと経過時間プロファイリングの両方が無効になっている場合に、start の間にスローされます。

ValueError

この問題を解決するには、以下のすべてを確認します。

• サービス名とバージョンが、サービス名とバージョンの引数で定義されている要件を満たしていることを確認します。
• 経過時間プロファイリングが有効になっている場合は、start がメインスレッドから呼び出されるようにします。
• サポートされているバージョンの Python を使用し、CPU プロファイリングまたは経過時間プロファイリングが有効になっていることを確認します。詳細については、start 関数をご覧ください。
• Google Cloudの外部で実行している場合は、project_id パラメータが start に指定されていることを確認します。詳細については、start 関数をご覧ください。

Python でのリソースを一時的に利用できないエラー

Profiler を有効にした後、エラーログには次のエントリが含まれます。

BlockingIOError: [Errno 11] Resource temporarily unavailable
Exception ignored when trying to write to the signal wakeup fd

このメッセージは、アプリケーションがシグナルの wakeup ファイル記述子 signal.set_wakeup_fd で登録されたときに表示されます。デフォルトでは、ファイル記述子のバッファに空き容量がなくなると、stderr に警告が記録されます。

Cloud Profiler がプロファイルを収集すると、高い頻度でシグナルがトリガーされ、シグナル ファイル記述子の空き容量がなくなる場合があります。GitHub の問題については、App Engine での BlockingIOError をご覧ください。

この問題を解決するには、以下のいずれかを行います。

• シグナルが失われても、アプリケーションを安全に実行できる場合は、Cloud Profiler を使用できます。Python 3.7 以降を使用しており、警告メッセージを無効にする必要がある場合は、warn_on_full_buffer=False をパラメータとして signal.set_wakeup_fd に渡します。

• シグナルが失われ、アプリケーションを安全に実行できない場合は、Cloud Profiler の使用を停止することをおすすめします。使用し続けると、シグナル番号がなくなり、エラーログのエントリが過剰になる可能性があります。

すべてのプロファイルが不明

プロファイルが表示されない場合は、一般的に次の 2 つの理由が考えられます。

• プロファイルの収集のためにサービスを実行するのに十分な時間がない。
• 認証を行うようにサービスが構成されていない。

実行時間が短い現象に関連する問題を解決するには、サービスが 3 分以上継続して実行されるようにします。

認証に関連する問題を解決するには、プロファイリング エージェントで Google Cloud プロジェクトにデータを書き込めるようにします。

• サービスが Google Cloudで実行されている場合は、Compute Engine にコンテナをデプロイする場合を除き、自動的に認証が行われます。Compute Engine にコンテナをデプロイする場合は、Profiler エージェントの start コマンドでGoogle Cloud プロジェクト ID を指定する必要があります。手順については、エージェントを Google Cloud プロジェクトにリンクするをご覧ください。

• サービスが Google Cloudの外部で実行されている場合は、サービス アカウントを作成し、Profiler エージェントをGoogle Cloud プロジェクトにリンクする必要があります。詳細については、 Google Cloudの外部で実行されているアプリケーションのプロファイリングをご覧ください。

  注: サービス アカウントに roles/cloudprofiler.agent の IAM ロールが付与されていることを確認します。このロールを付与する方法については、 Google Cloudの外部で実行されているアプリケーションのプロファイリングをご覧ください。

特定の種類のプロファイルが不明

このセクションでは、プロファイルが収集されない（1 つ以上のプロファイル タイプが対象）特定の構成を示します。最初のセクションには一般的な内容が記載されていて、残りのセクションには特定の言語に関する問題が記載されています。

全般情報

特定のプロファイル タイプを表示し、そのタイプのプロファイルがない場合は、次の点を確認します。

• プロファイル タイプがアプリケーションの言語でサポートされていることを確認します。詳細については、利用可能なプロファイリングの種類をご覧ください。

• 収集するプロファイル タイプの変更後に新しいサービス バージョンを使用していることを確認してください。新しいサービス バージョンを指定しない場合は、既存のデプロイメントが使用され、新しく有効にしたプロファイル タイプのデータをプロファイリング エージェントで転送できません。デプロイメントの詳細については、プロファイルの収集をご覧ください。

• プロファイル タイプが有効になっていることを確認します。一部のプロファイル タイプはデフォルトで無効になっています。詳細については、各言語のページをご覧ください。

  • Go アプリケーションのプロファイリング
  • Java アプリケーションのプロファイリング
  • Node.js アプリケーションのプロファイリング
  • Python アプリケーションのプロファイリング

このページの残りのセクションでは、1 つのプロファイル タイプのデータが収集されない言語に固有の構成について説明します。

Go: c-archives の CPU 時間プロファイルは収集されません

-buildmode フラグを c-archive または c-shared に設定して Go アプリケーションをビルドする場合、デフォルトでは CPU 時間プロファイリングは無効です。ヒープ、競合、スレッドのプロファイルが収集されます。詳しくは、GitHub の問題 #993: Profiler が c-archive で Go コードの CPU データを収集しないをご覧ください。

この問題を解決するには、サービスが profiler.Start を呼び出す前での CPU 時間プロファイルの収集を有効にして、signal.Notify(make(chan os.Signal), syscall.SIGPROF) の呼び出しを追加します。signal.Notify の詳細については、func Notify をご覧ください。

Java: 複数のプロファイラが有効になっている場合、ヒープ プロファイルが収集されない

Java アプリケーションで複数のヒープ プロファイラが有効になっており、プロファイルがありません。

Java ヒープ サンプラーは、ソロ エージェント機能として有効になっています。このため、一度に使用できる Profiler は 1 つだけになります。複数のヒープ プロファイラをサポートするよう Java を拡張するために、バグがオープンされています。バグの詳細については、ヒープ サンプリング メカニズム用にマルチエージェント サポートを追加するをご覧ください。

この問題を解決するには、1 つの Profiler を有効にします。

Python: uWSGI を使用する場合、CPU 時間プロファイルなし、経過時間プロファイルなし

uWSGI が複数のワーカーを使用してリクエストを処理する場合、デフォルトの動作では、プライマリ（master）プロセスでのみアプリケーションの初期化が行われます。フォークしたプロセスでは、初期化シーケンスは行われません。

アプリケーションの初期化シーケンスでプロファイリング エージェントを構成する（たとえば、Django アプリケーションの AppConfig.ready() メソッドでプロファイリング エージェントを構成する）と、フォークしたプロセスではプロファイリング エージェントは構成されません。

この問題を解決するには、すべてのワーカー プロセスで、lazy-apps フラグを true に設定してアプリケーションの初期化を行います。

Python: uWSGI を使用する場合、CPU 時間プロファイルはあるものの、経過時間プロファイルなし

経過時間プロファイラは Python シグナル モジュールに依存します。Python インタープリタのコンパイルでスレッド サポートを有効にすると、デフォルトの構成では、フォークしたプロセスのカスタム シグナル処理が無効になります。

この問題を解決するには、uWSGI アプリケーションで py-call-osafterfork フラグを true に設定してカスタム シグナル処理を有効にします。

Python: フォークされたプロセスにプロファイルがない

プロファイリング エージェントは、エージェントを起動したプロセスのみをプロファイリングできます。

アプリケーションでプロセスをフォークする場合や、フォーク プロセスからプロファイルを収集する場合に、この問題を解決するには、フォーク後にエージェントを初期化します。