requests.asyncを使用している場所は？

いいえ、すべてのリクエストはかなり単純なrequests.get / requests.postでした、私はまだそこにいくつか見ています

$ lsof | grep localhost | wc -l
110

それらの4/5を除くすべてがフォーマットです

Python    82117 daleharvey  123u    IPv4 0xffffff800da304e0       0t0      TCP localhost:61488->localhost:http (CLOSE_WAIT)

正直なところ、私はこれに少し困惑しています。

私が病気で閉じることができない場合、ハァッ病気はそれを確実に再現するために別のショットを撮ります

私はこれが私に起こっているのを見ましたが、200以上の同時接続で非同期モジュールを使用しているときだけです。

こんにちは、
リクエストとgeventでのモンキーパッチを使用してもまったく同じ問題が発生しました。一部の接続はCLOSE_WAITのままです。
多分geventの問題なので。

ulimit-nの問題である可能性があります。 より高い値で試してください。

「開いているファイルが多すぎます」は、ソケットがCLOSE_WAITにとどまっているために発生したバグの結果です。
したがって、ulimitは、回避策を作成するだけでは修正されません。

@tamielこれを修正するにはどうすればよいですか？

できるだけ早くテストを行い、修正を試みます。

私はそれを調べましたが、httplib.HTTPSConnectionを使用するすべてのライブラリで問題があるようです。

ここに例を投稿しました：

https://gist.github.com/1512329

HTTP接続のみの非同期プールを使用して非常によく似たエラーが発生しました-まだ調査中ですが、プールサイズをasync.mapに渡すと、エラーがすぐに再現されます。

これに対する修正はありますか？ これにより、リクエストはgeventで使用できなくなります。

それはすべてCLOSE_WAITです。 それらを閉じる必要があります。 なぜまだ開いているのかわかりません。

urllib3の問題ですか？ これらを自分で閉じなければならないのは、私が感じる素晴らしいアイデアではありません。

それはもっと一般的な問題です。 ここで会話を続けることができます。

わかりやすく説明するために、httplib2からリクエストに移行しようとしていますが、httplib2ではこの問題は発生していません。 したがって、それは確かに一般的な問題ではありません。

一般的に言って、それは関係者全員に影響を与える非常に深刻な問題だということです。

では、どうすればこれを解決できますか？ 私たちは本当にリクエストと眠りを使いたいです

その答えを知りたいです。

リークは、保留中の応答が消費される前に新しい要求が生成される内部リダイレクト処理が原因であると思われます。 acdha @ 730c0e2e2bef77968a86962f9d5f2bebba4d19ecのテストでは、続行する前に各応答を強制的に消費するだけで、満足のいくものではありませんが効果的な修正が行われます。

これには2つの場所での変更が必要であり、インターフェイスを少しリファクタリングしたいと思いますが、現在続行する時間はありません。

399には、数千のリクエストと低いfd ulimitで、非同期ロードジェネレーター（https://github.com/acdha/webtoolbox/blob/master/bin/http_bench.py​​）でうまく機能する修正があります。

asyncを使用しているときに同じ問題が発生しました-リクエストをチャンクし、レスポンスを削除するか、gc.collectを呼び出すことで回避策を見つけました

私は今日、5つの接続しか許可しないライセンスサーバーに接続しているときにこれに遭遇したと思います。

asyncを使用すると、60秒間一時停止する前に、4つのものしか取得できませんでした。

通常のGETを消費とともに使用すると、40秒以内に約150個のデータを連続してフェッチできました。

この問題を見て以来、まだ応急修理をしていません。

ipythonの使用中にこのエラーが発生し、このメッセージが表示されました。 これは、一度に1つずつリクエストを行うだけですが、asyncを使用すると似たようなものが得られたと思います。

ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.
Traceback (most recent call last):
    File "/Library/Python/2.7/site-packages/IPython/core/ultratb.py", line 756, in structured_traceback
    File "/Library/Python/2.7/site-packages/IPython/core/ultratb.py", line 242, in _fixed_getinnerframes
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 1035, in getinnerframes
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 995, in getframeinfo
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 456, in getsourcefile
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 485, in getmodule
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 469, in getabsfile
    File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 347, in abspath
OSError: [Errno 24] Too many open files

Unfortunately, your original traceback can not be constructed.

奇妙なことに、通常のPythonインタープリターだけを使用すると、「最大再試行エラー」が発生すると思いますが、それはすべて同じドメインでリクエストを実行する際の別の問題だと思いますが、確かではありません。

allow_redirectsがTrueであった最初のプロジェクトでこれに遭遇しました。 これは、prefetch = Trueでも解放されない応答オブジェクトをリークするリダイレクトチェーンが原因であると思われます。 これは私の最初のテストでそれを修正しました：

        [i.raw.release_conn() for i in resp.history]
        resp.raw.release_conn()

うーん..

@acdha設定：

requests.defaults.defaults['allow_redirects'] = False

リクエストを行う前でも同じエラーが発生しますが、これは私の実装のオプションではないと思います。私が行うすべてのリクエストにはリダイレクトが必要になるためです= /

@dalanmiller応答をどのように処理していますか？ 以前は応答フックでasync.mapを使用していましたが、 async.imap単純なループを使用すると、より安定しているように見えます。

for resp in requests.async.imap(reqs, size=8):
    try:
        print resp.status_code, resp.url
    finally:
        [i.raw.release_conn() for i in resp.history]
        resp.raw.release_conn()

@acdha

私はURLリストを介してforループを使用し、設定などを使用してそれぞれに対してrequest.getを実行していました。

for u in urls:
    response_list.append(requests.get(u))

私はあなたのペーストを使ってみましたが、残りの「URLで最大再試行エラーを超えました」が表示されるまで、900の長さのリストで約50のリクエストに対応しています。 同じドメインを繰り返しヒットした場合でも、これはかなり標準的なエラーです。

ねえ、私はURLの膨大なリスト35kをクロールしていて、リクエストの_いくつか_でこれと同じエラーが発生しました。

次のように、10個のチャンクでURLを取得しています。

responses = requests.async.map([requests.async.get(u, params=self.params()) for u in chunk]) # chunk is a list of 10

20kの範囲のどこかで、エラー24が発生し始めました。その後、30kまでは問題ありませんでした。

それを絞り込むために興味がある情報は他にありますか？

requests.asyncはなくなりました。 grequestsへの移行を検討することをお勧めします。

了解、ありがとう。 ドキュメントでこれについて言及するとよいでしょう。

プルリクエストとドキュメントの作成に関しては、一種の初心者ですが、私はそれを突き刺して送信しました。 コメントまたは批判してください:)

https://github.com/kennethreitz/requests/pull/665

わかりました。これは、非同期を使用しなくても、6Kリクエストの後にrequests.getだけで発生します。

私はそれを疑った。

私の場合、正確に1,000個のファイルをダウンロードした後に「開いているファイルが多すぎます」というエラーが発生しました。 私の解決策は、keep-aliveプロパティを無効にして、リクエストをチャンクで取得することでした（ @acdhaはヒントをありがとう）。 lsof -p PID | wc -lは、実行中の接続数が増加していないことを示しています。

rsess = requests.session()
rsess.config['keep-alive'] = False

rs = [grequests.get(l, session=rsess) for l in links]

for s in chunks(rs,100):
    responses = grequests.map(s, size=concurrency)
    for r in responses:
        try:
            print(r.status_code, r.url)
        finally:
            r.raw.release_conn()

[1]チャンク： http ：

urllib3の修正を延期しながら終了します。

@kennethreitz urllib3の発行番号は何ですか？

これが問題のようですhttp://bugs.python.org/issue16298

@silvexisはurllib3のバグに関連している可能性が非常に高いので、誰かが@ piotr-dobrogost：Pと答えてくれたらいいのにと思います。

他の誰かがまだこの問題に直面していますか？

私はそれについての報告を聞いたことがありません。 あなたですか？

これは、フレームワークではなく、ボックス構成の問題です。 OSのカーネル構成を確認してください。 BSDではkern.maxfilesと呼ばれます。 Linuxシステムにはulimitに関するスレッドがあります： http ：
お役に立てば幸いです。Windowsでこのパラメーターを変更する方法がわかりません。

http://stackoverflow.com/questions/18024285/big-requests-issue-get-doesnt-release-reset-tcp-connections-loop-crashes

古いバージョンのリクエストをまだ実行しているという警告がありますが、これを処理するために次の恐ろしいコードが用意されています。

    if self._current_response is not None:
            # Requests doesn't have a clean API to actually close the
            # socket properly. Dig through multiple levels of private APIs
            # to close the socket ourselves. Icky.
            self._current_response.raw.release_conn()
            if self._current_response.raw._fp.fp is not None:
                sock = self._current_response.raw._fp.fp._sock
                try:
                    logger.debug('Forcibly closing socket')
                    sock.shutdown(socket.SHUT_RDWR)
                    sock.close()
                except socket.error:
                    pass

（self._current_responseはリクエストのレスポンスオブジェクトだと思います）

うーん、クロージングのチェーンはどこで壊れていますか？ 我々は持っているResponse.close()メソッド呼び出しrelease_conn()必要とするものようで発生し、 release_conn()仕事に、このために？

@Lukasa私が議論の一部だったurllib3で間違いなく修正されました。 私の見積もりでは保守的な傾向がありますが、1.1.xではなくても1.2.xを要求しているので、そこにあると言えます。

ええ、私はこれが修正されたと思いました。 1.2.3に何かが表示されない限り、これは修正されていると思います。

2.0.2でCLOSE_WAITリークが発生していますが、トピックにリグレッションがないことを確認するための単体テストはありますか？

いいえ、しません。 AFAIKurllib3もそうではありません。 リークを簡単に再現できますか？

月曜日から社内アプリでリクエストを使用しており、今日は1024個のmaxfilesに到達しています。

再起動の2時間後、lsofの指示に従って40個のCLOSE_WAITがあります。

ですから、開発環境で再現できると思います。 連絡を取り合います

@tardypも、どのようにリクエストをインストールしましたか？ すべてのOSパッケージメンテナがurllib3を取り除いていると思います。 それらが最新の状態に保たれておらず、古いバージョンを使用している場合は、代わりにそれが原因である可能性があります。 pipを使用している場合は、この問題にディスカッションを追加する代わりに、新しい問題を開いてこれを追跡してください。

pipを使用してインストールしましたが、python 2.6を使用しています。python2.7で修正が見られました。
このバグ。 古いバージョンのモンキーパッチはありますか？

ピエール

17:33時金、2013年11月29日には、イアンCordascoの[email protected] ：

@tardyp https://github.com/tardypまた、どのようにリクエストをインストールしましたか？ 私
すべてのOSパッケージメンテナがurllib3を削除すると思います。 そうでない場合
それを最新の状態に保ち、古いバージョンを使用している場合、それは
代わりに原因。 pipを使用している場合は、新しい問題を開いてください。
これにディスカッションを追加する代わりに、これを追跡します。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/kennethreitz/requests/issues/239#issuecomment-29526302で表示してください
。

@tardypは、作成しているリクエストにリダイレクトがあるかどうか、geventを使用しているかどうかなど、できるだけ詳細に新しい問題を開いてください。 また、オペレーティングシステムに関する詳細とそれを再現する方法の例は素晴らしいでしょう。

参考までにhttps://github.com/shazow/urllib3/issues/291はバグのために元に戻されました。

これを再開する必要がありますか？
私は同じ問題を抱えています！

@polvoazulこれが2011年に最初に報告されたのと同じ問題であるという方法はないので、再開することは正しいとは思いません。 ただし、現在のリリースのリクエスト（2.4.3）を実行していて、問題を再現できる場合は、新しい問題を開くのが正しいでしょう。

@Lukasa私はあなたの助けが必要です。私はイベントレット+リクエストを使用します。これは常にプロトコルを識別できない非常に多くの靴下を作成します。私のリクエストは2.4.3ですが、イベントレット+リクエストはこの問題を引き起こしますか？

@mygoda申し訳ありませんが、知ることは不可能です。 一度に未処理になる可能性のあるリクエストの数を制限していなければ、それは確かに可能ですが、それはリクエストの範囲外のアーキテクチャ上の問題です。

@Lukasaはあなたに感謝します。私は私の問題は、と似ていると思い、この。私のプロジェクトがあるpyvmomi 。 その接続は長い接続です。 なぜそんなに多くの人がプロトコルソックスを識別できないのか私はいつも混乱しています

現在同じ問題があり、120スレッドを実行すると、100000以上のファイルが開かれますが、現在解決策はありますか？

@mygodaあなたは素晴らしい

@ 1a1a11a _What_ファイルを開いていますか？ これは、この問題を理解するための有用な最初のステップになります。

@ 1a1a11aどのバージョンのリクエストを使用していますか？ Pythonのどのバージョンですか？ どのオペレーティングシステムですか？ 何か情報を入手できますか？

私はリクエスト2.9.1、python 3.4、ubuntu 14.04を使用しています。基本的に、プロキシを使用して30のスレッドを使用してクローラーを作成し、一部のWebサイトをクロールしています。 現在、プロセスごとのファイル制限を655350に調整しました。そうしないと、エラーが報告されます。

「新しい接続の確立に失敗しました：[Errno24]開いているファイルが多すぎます」というエラーがrequests.packages.urllib3.connection.VerifiedHTTPSConnectionから引き続き表示されます。Python3.4、requests 2.11.1、requests-futuresを使用しています。 0.9.7。リクエストに感謝します-futuresは別のライブラリですが、エラーはリクエストから発生しているようです。SSLを介して180kの非同期リクエストを作成しようとしています。これらのリクエストを1000のセグメントに分割したので、将来のすべてのオブジェクトが解決された後でのみ、次の1000に移動します。Ubuntu16.04.2を実行しており、デフォルトのオープンファイル制限は1024です。このエラーの根本的な理由を理解しておくとよいでしょう。リクエストライブラリは作成しますか個々のリクエストごとに開いているファイル？もしそうなら、なぜですか？これはSSL証明書ファイルですか？そしてリクエストライブラリは、将来のオブジェクトが解決されたときにそれらの開いているファイルを自動的に閉じますか？

リクエストは多くのファイルを開きます。 これらのファイルの一部は証明書用に開かれますが、要求ではなくOpenSSLによって開かれるため、それらは維持されません。 さらに、リクエストは、必要に応じて、 .netrcファイル、hostsファイル、およびその他の多くのファイルも開きます。

straceなどのツールを使用して、開いているファイルを特定することをお勧めします。 ファイル記述子が割り当てられる原因となるシステムコールの厳密なリストがあるため、それらを合理的に迅速に列挙できるはずです。 また、問題があるかどうかもわかります。 ただし、はい、HTTPSを介してアクティブに1000の接続を確立している場合、ピーク負荷時に1000を超えるFDを簡単に使用できると思います。

私もこの問題に苦労し、OS Xでopensnoopを使用すると、誰かが同じ問題に遭遇した場合に何が起こっているのかを確認するのに非常に効果的であることがわかりました。

requests.post(url, data=data)をHTTP （HTTPSではない）サーバーに繰り返し呼び出すときにも、このエラーが頻繁に発生します。 Ubuntu 16.04.3、Python 3.5.2で実行すると、2.9.1が要求されます

dataとは何ですか？

数百キロバイトのテキスト

ファイルオブジェクトではありませんか？

いいえ、メモリ内で大きなクエリを作成します。

このコードを複数のスレッドで実行していますか？

いいえ、シングルスレッド、ローカルホストへの投稿

その場合、多くのFDをリークすることはほとんど不可能のようです。同じTCP接続を繰り返し使用するか、積極的に閉じる必要があります。 サーバーが何をしているのかを確認したいですか？

私はこの問題を抱えています。 Python 2.7、リクエスト2.18.4、urllib31.22。
マルチスレッドコードの実行（マルチプロセスではない）。 一度に最大6つのURLに接続し、それぞれの新しいセッションを手動で作成して閉じます。

Python 3.5 、 requests==2.18.4でも同じ問題が発生しています

@mcobzarencoは、応答の基になる接続を（暗黙的に）閉じていると確信していますか？ 単に応答を返すだけでは、接続は閉じられません。 response.contentを読み取るとき、データは実際に読み取られ、その後、ソケットはCLOSE_WAITに留まりません。