2

WAN 経由で複数の XMLRPC クライアントからの要求を処理しています。このことは、たとえば、1 日 (場合によっては 2 日) の間うまく機能し、その後 socket.py でフリーズします。

data = self._sock.recv(self._rbufsize)

_sock.timeout は -1、_sock.gettimeout は None

メイン スレッド (XMLRPC 呼び出しを受信するだけ) で特別なことを行うことはなく、DB と通信する別の 2 つのスレッドがあります。これらのスレッドは両方とも正常に動作し、このブロックを存続します (WinPdb で確認しました)。クライアントは 1KB を超えない長さのリクエストを送信しており、特別なコンテンツはありません。辞書にあるきれいな文字列だけです。2 回のブロックの間に、何万ものリクエストを問題なく処理しています。ファイアウォールがオフになっている、同じマシンに奇妙なソフトウェアがないなど...

Windows XP と Python 2.6.4 を使用しています。2.6.4 との違いを確認しました。および 2.6.5 であり、重要なことは何も見つかりませんでした (または、私が間違っているのでしょうか?)。2.7 バージョンは、MySqlDB のバイナリが見つからないため、オプションではありません。

インターネット接続が不十分なクライアントによって時々発生する唯一のことは、ソケットが壊れることです。これは 5 ～ 10 分ごとに発生しています (2 秒ごとにサーバーにアクセスするクライアントは 5 つだけです)。

私はこの問題にかなりの時間を費やしてきましたが、今、何をすべきかについての考えを失い始めています。ヒントや考えをいただければ幸いです。

4

2 に答える 2

1

OS の TCP/IP スタック (おそらく最上位の Python レイヤーで発生する可能性がありますが、その可能性は低い) で正確に何が起こって、これが引き起こされるのかは謎です。実用的な回避策として、リクエスト間に予想される遅延よりも長いタイムアウトを設定し (2 秒ごとにリクエストが予想される場合は 10 秒で十分です)、発生した場合は閉じてから再度開きます。(試行錯誤によって通常のトラフィックを中断することなく、フリーズを回避するために必要な遅延を調整します)。問題を理解せずに修正をハックするのは気が進まないことはわかっていますが、実際のサーバー システムを作成、展開、運用する世界では、そのようなことについて実用的であることは必要な生存特性です。将来のメンテナのために、回避策を正確にコメントしてください!

于 2010-07-17T16:00:05.270 に答える
0

迅速な対応に感謝します。それを受け取った直後に、タイムアウトを 10 秒に増やしました。現在、すべて問題なく実行されていますが、もちろん、ある種の確認を得るにはさらに 1 日か 2 日待つ必要がありますが、5 日後にのみ確認して結果を返すことができます。140K のリクエストはすでにうまくいっていることがわかりました。このリクエストで非常に苦労したので、少なくともあと 200K 待ちます。

（システムをダウンさせずに）タイムアウトの自動適応について提案していたことも合理的に聞こえます。小さなクラス (AutoTimeoutCalibrator など) を作成し、serial.py に直接埋め込むのが正しい方法でしょうか?

はい - 現実的であることは、背後にある本当の理由を突き止めようとして、さらに 10 日間無駄にしない唯一の方法です。

また結果報告しますのでよろしくお願いします。（申し訳ありませんが、何らかの理由であなたの投稿への返信として投稿できませんでした）

于 2010-07-18T10:18:53.380 に答える