問題タブ [objgraph]

Python クライアント サーバー アプリケーションがあり、そのサーバーは約 4 日間実行されています...そのメモリ使用量 (/proc/PID/status -> VmSize で報告) が約 660Mb に達しました。メモリ リークの可能性があるため、objgraphを使用してメモリ使用量 (最初の 20 個のオブジェクト タイプ) を出力しました。

そこには特に「臭い」ものは何もありません。何か不足していますか? おそらくこれは、Pythonが未使用のメモリをすぐに OS に解放しないためでしょうか?
(これは CherryPy+SQLAlchemy アプリケーションです)

スレッド化された応答ハンドラーを生成するサーバー サブクラスがあり、ハンドラーはアプリケーション スレッドを開始します。ObjGraphを使用する場合を除いて、すべてが順調に進んでいます (実行中のアプリケーション スレッドの数が正しいことがわかります (私は負荷テストを行っており、35 個のアプリケーション インスタンスを実行し続けるように調整しています)。

objgraph.typestats()を呼び出すと、(GC に従って) 現在インタープリター内に存在する各オブジェクトのインスタンス数の内訳が提供されます。メモリ リークの出力を見ると、700 個のロガー インスタンスが見つかりました。これは、サーバーによって生成された応答ハンドラーの総数です。

アプリケーション スレッドが run() メソッドを終了するときに logger.removehandler(memoryhandler) と logger.removehandler(filehandler) を呼び出して、ロガー インスタンスへの参照が残っていないことを確認しました。また、ロガー インスタンスはアプリケーション スレッド内で完全に分離されています。 （それへの外部参照はありません）。これらのロガー インスタンスを排除する最後の手段として、run() の最後のステートメントは del self.logger です。

init() でロガーを取得するために、適切な大きさの乱数を指定して名前を付け、ファイル アクセスで区別できるようにします。ログ ファイル名の一部として同じ大きな数を使用して、アプリケーション ログの衝突を回避します。

要するに、GC によって追跡される 700 のロガー インスタンスがありますが、アクティブなスレッドは 35 しかありません。これらのロガーを強制終了するにはどうすればよいですか? より面倒なエンジニアのソリューションは、ロガーのプールを作成し、アプリケーション スレッドの存続期間中 1 つだけを取得することですが、GC が単純にこれを自動的に処理する必要がある場合に、維持するコードがさらに作成されます。

objgraphを使用して、次のようなオブジェクトの束を見つけました。

Python のガベージ コレクターはこのようなサイクルを処理しますか、それともリークしますか?

ループの少し広いビュー:

最近objgraphドキュメントを読んで、次のコードについて混乱しました

「非常に明確で見つけやすい「リーク」」であることを示しています。これにはメモリリークがありますか？それはdict _cacheですか？

objgraph を使用して Coopr パッケージのメモリ リークをデバッグしようとしています: https://gist.github.com/3855150

オブジェクトに固定されてい_SetContainerますが、そのオブジェクトがメモリに保持されている理由がわかりません。の結果は次のobjgraph.show_refsとおりです。

循環参照を見つける方法と、ガベージ コレクターに_SetContainerインスタンスを収集させる方法を教えてください。

以前は、クラス自体に自己参照があるのではないかと考えていました (上の画像の右側のクラスのすぐ下にあるタプル)。しかし、objgraph は常に、継承されたクラスを常に自己参照タプルを持つものとして表示します。ここで非常に単純なテスト ケースを確認できます。

私はpandas.DataFrameマルチスレッドコード（実際にはDataFrame呼び出されたのカスタムサブクラスSound）で使用しています。プログラムのメモリ使用量が徐々に10分を超えて増加し、最終的にコンピュータメモリの約100％に達してクラッシュするため、メモリリークが発生していることに気付きました。

objgraphを使用してこのリークを追跡しようとしましたが、インスタンスの数は常に増えてMyDataFrameいるはずですが、そうではないことがわかりました。メソッド内のすべてのスレッドがrunインスタンスを作成し、計算を行い、結果をファイルに保存します。終了します...したがって、参照は保持しないでください。

を使用objgraphすると、メモリ内のすべてのデータフレームに同様の参照グラフがあることがわかりました。

それが正常かどうかはわかりません...これが私のオブジェクトをメモリに保持しているようです。アイデア、アドバイス、洞察はありますか？

私は実際に私のpythongtkアプリ内で私のメモリの問題を修正しようとしています。

Pythonでのメモリ使用量に関する多くの記事を読みましたが、すべてを理解することはできません。ここで私を助けていただければ幸いです。

したがって、アプリケーションを起動して設定ウィンドウを開くと、32368KBのmem使用量になります。

設定ウィンドウを閉じると、memの使用量も32368KBになります。

設定ウィンドウを開いたり閉じたりするコード例を次に示します。

main.py

ここで、iveはobjgraphを使用して生きている参照を分析しようとしました。それが結果です：

設定ウィンドウを開く

設定ウィンドウを閉じた後

誰かがmemを解放する方法を手伝ってもらえますか？

メモリ リークを見つけるために、一部の Python コードでオブジェクトの依存関係を視覚的に検査する必要があります。objgraph を使用しようとしていますが、その依存関係の 1 つである xdot が gobject を必要とし、osx の入手先が見つからないため、問題が発生しています。これは私が得ているものです:

osx でのこのエラーの修正はありますか? または、osx で適切に動作する objgraph の代替手段はありますか?