0

クラッシュするようには見えない耐久性のある関数がありますが、最初の呼び出しの後、同じ関数を実行し続けます。この最初の呼び出しの後、ブレークポイントを設定しようとしても効果がありません。

[2017/11/30 16:16:21] 機能開始 (Id=972ee93c-ab61-4834-937c-207e8953821d)
[30/11/2017 16:16:21] 'CompileFeatureObservations' を実行しています (理由 =''、Id=972ee93c-ab61-4834-937c-207e8953821d)
[30/11/2017 16:16:21] 機能のコンパイルを開始します。
[30/11/2017 16:16:21] 関数が完了しました (成功、ID=972ee93c-ab61-4834-937c-207e8953821d、期間=58ms)
[30/11/2017 16:16:21] 'CompileFeatureObservations' を実行しました (成功、Id=972ee93c-ab61-4834-937c-207e8953821d)
[30/11/2017 16:16:21] b540b650019244719a7f3a61e45735f4: 関数 'CompileFeatureObservations (アクティビティ)'、バージョン '' が完了しました。ContinuedAsNew: False。IsReplay: False。出力: (62123 バイト)。状態：完成。ハブ名: DurableFunctionsHub。アプリ名: 。スロット名: 。拡張バージョン: 1.0.0.0。

影響があるように見える唯一の要因は、65kb の制限を下回っていますが、リクエスト ペイロードのサイズです。

ドキュメントで説明されているように、ファンアウト/ファンイン パターンを使用しています。タスク配列のサイズが ~100 になると、動作が停止し、無限サイクルに入るように見えます。

ファンアウトの制限を超えたのではないでしょうか? 関数の「インスタンス」の数を制御する方法はありますか?

従量制プランを利用しています。

この動作を停止する唯一の方法は、ローカル ストレージ エミュレーターを停止し、基になる localdb を削除して再初期化することです。

さらにトラブルシューティングを行うための提案はありますか?

4

1 に答える 1

3

問題は関数の大量の出力であると確信しています。これは、https ://github.com/Azure/azure-functions-durable-extension/issues/79 で言及されている既知の問題です。

ここで誤解を招くのは、次のログ ステートメントです。

[30/11/2017 16:16:21] b540b650019244719a7f3a61e45735f4: Function 'CompileFeatureObservations (Activity)', version '' completed. ContinuedAsNew: False. IsReplay: False. Output: (62123 bytes). State: Completed.

出力は約 60 KB であると主張していますが、UTF-8 エンコーディングを想定しているため、ここで報告されている数値は実際には正しくありません。実際には、Azure Storage は UTF-32 エンコードを使用するため、実際のサイズはおそらくこれよりもはるかに大きくなります。これを修正する必要があることに注意してください。beta2 アップデートでは、これを正しく報告し、例外をスローします。その後、任意の大きな戻り値をサポートする予定です。

質問の他の部分に答えるために、ファンアウトの程度は問題ではありません。それは単に戻り値のサイズです。これを縮小できれば、問題は解決するはずです。

于 2017-11-30T18:24:56.867 に答える