問題の説明
サービスは、Python言語を使用して、変更MGRマスターノードクラスタかどうかを検出するためのサービスです。
各クラスタの場合、メインスレッドは、子供を検出するために、スレッドが子スレッドを作成します。頻繁に子スレッドの作成と破棄。
上の行の後に、機能リリースは、多くの場合があるので、このように、サービスを再起動する期間を開始し、何の問題も見つかりませんでした。
火曜日は約一週間リリースサービスの前に2週間後、もはや公表されません。週末には、突然、警報システムの負荷が高い場合には、調査の後、それはメモリがほとんど消耗していることがわかった、とサービスは、巨大なメモリが解放されませんによって占有されました。
調査プロセス
最終的にメモリを使い切るところですが、それを解放しませんでした、サービスはメモリリークで、決定されていますか？
これは私が今までPythonのメモリリークを満たしていない、非常に厄介な問題です。
まず、オンライン検索Pythonのメモリリークの問題。オブジェクトが一度使用された場合、一般的に学び、Pythonのガベージコレクションは、参照カウントに基づいており、つまり、参照カウントは1だけインクリメントされます。オブジェクトの参照カウントが0の場合、メモリはオフに回復されます。
一般的な状況は、2つの方法でメモリリークにつながります：
- （1）オブジェクトは、グローバル変数、グローバル変数、比較的長いライフサイクルを使用していたので、メモリが解放されていません。
- （2）循環参照オブジェクトがどのように__del__を定義します。
インターネットは、その特定の使用参照テキストとobjgraph、グッピー、pympler、後にそのようなリンクのようなメモリリークを、トラブルシューティングのためのさまざまなツールを提供します。
これらのツールを使用するのに長い時間を読んで、感じたり、コードを見てみなければならないが、オブジェクトが存在するの使用を終了していないが、ケースが引用されています。
まず、位置トラブルシューティングメモリリークがメインスレッドまたはサブスレッドです。見ることによって及び「頻繁に作成し、サブスレッドを終了」が見つかり、両方のケースでは、メモリ消費量の違いがないと「子スレッドが実装されました」。このようにして、場所はメインスレッドであるメモリリークにナビゲートすることができます。
続いて、辞書から子スレッドマネージャオブジェクトディクショナリに、あなたは子スレッドを作成するたびに見つけ、スレッドがサブマネージャオブジェクトになり、メインスレッドコードを表示するが、とき、子スレッドが終了ではなく、削除されました。原因は、頻繁に作成し、子スレッドを破壊するので、辞書は、メモリリークが発生、ますます大きくなります。
ソリューション
問題の原因を見つけるには、その後、簡単に解決策を処理します。子スレッドが終了するが、タイムリーな子スレッドマネージャオブジェクトが辞書から削除された場合、占有メモリを解放します。
参照
Pythonのデバッグメモリリークの問題
GCを使用して、objgraph循環参照とPythonのメモリリークを殺します！
Pythonのメモリの最適化：プロフィール、スロット、コンパクト辞書