0

私が使用している Twisted アプリは、メモリの問題により常に強制終了されていました。プログラムはサイズが大きくなり、OS によってシャットダウンされる前にシステムのメモリをすべて消費しました。再起動して繰り返します。

これは仮想サーバー上にあるため、メモリを 2 倍にしたところ、問題は解決しました。デーモンは約 1.25 GB のメモリで安定しました。

すべてのメモリが何/どこに吸い込まれているのかを知るために、これをどのようにプロファイルするのが最善かについて誰かアドバイスがありますか?

アプリの情報が役立つ場合、私はツイスト リアクターと internet.timer.TimerService を使用して、3 つの「サービス」を介して更新するアイテムのデータベースをポーリングしています。処理するアイテムは twisted.internet.defer.DeferredList にプッシュされ、それらの処理は deferToThread ブロックで行われます。遅延プロセスには、いくつかのブロック操作 (Web ページのフェッチなど) と、多くの HTML 解析 (美しいスープやその他のライブラリ) があります。私は、reactor.threadpool のサイズを 10 にすることを提案しました。各「サービス」は、10 個のトークンを持つ SemaphoreService を使用してスレッド化されます。私は、このデーモンが 3 倍ではなく、約 400MB のメモリで最大になることを本当に期待していました。

4

1 に答える 1

2

This is more of a generic share of thoughts how I debug memory leak/usage problems in my twisted applications. Twisted has a ssh server support, and is something which I add in to almost all of my projects in development. The ssh provides a interactive python interpreter access to the method which has python garbage collector available and a number of helper functions which allow me to a) inspect count of the instances from a same class, b) start and stop inspection of changes of that count over time and c) to get all references of that class. The nice thing with the interactive interpreter is that it allows ad-hoc introspection of offending instances, their relation to other objects and the state of process they are in. This so far has always proven a valuable instrument to pinpoint exact location where I have forgot / unforseen the ref release problems in my projects.

于 2013-01-23T07:57:36.990 に答える