2

ログに次の警告メッセージが表示された空白の画面が表示されます。

A problem was encountered with the process that handled this request, 
causing it to exit. This is likely to cause a new process to be used for
the next request to your application. (Error code 204)

私には他に何も与えられていません。タスクレット (@ndb.tasklet)、非同期データストア ops、および非同期 urlfetches (検索エンジン) を多用しています。appstats によると、たとえば 15 分の処理時間を 15 秒に短縮しています。処理するデータが少ない場合は機能します。さらに処理すると、上記の警告で失敗します。インスタンス タブには、インスタンスが 1 つだけ表示されます。私の直感では、そのインスタンスを過負荷にしています。

余分な負荷をサポートするために追加のインスタンスが自動的に起動すると思いましたが、インスタンスは CPU / メモリの負荷ではなくリクエストにのみ応答するのでしょうか? 3 つの異なるページを起動すると、3 つの異なるインスタンスも起動します。問題は、各リクエストが多くの処理を必要とすることです。

タスク キューを使用してバックエンド インスタンスをターゲットにすることもできますが、タスクがいつ完了して結果を返すかを知る必要があります。残念ながら、タスク キューには、特定のタスクがいつ完了したかを監視する方法がありません。

インスタンス間で処理を明示的に分割するにはどうすればよいですか (また、そうすべきですか)? 別の解決策はありますか？204 エラー メッセージを回避するにはどうすればよいですか?

編集:再帰制限を次のように引き上げました:

sys.setrecursionlimit

これをコメントアウトすると、次のエラーが表示されます。

RuntimeError: maximum recursion depth exceeded
4

1 に答える 1

1

再帰制限により、同期操作と非同期操作が混在していると思われます。get_result() ではなく、async ops と yield のみを使用するようにしてください。または、(実際の) コードを見せてください。

特に、再帰制限を上げると、最終的に C レベルのスタック オーバーフローが発生し、プロセスがカーネルによって不意に強制終了される可能性があります。その場合、ログも失われます。再帰制限を上げる前に、どのような種類のスタック トレースが得られましたか? エントリ数は 1000 まででしたか、それともほんの数十程度でしたか? 後者の場合、同期操作と非同期操作を混在させるという問題に確実に直面しています。

同期操作には 2 つの形式があることに注意してください。どちらもタスクレット内 (およびそれが呼び出すもの) のどこでも回避する必要があります。ent.put_async().get_result() のように、非同期呼び出しに続いて get_result() 呼び出しが行われます。

于 2012-11-29T15:12:24.847 に答える