For anyone interested - yes, that did solve my problem too.
Thanks, dragonfire13!
On 10/18/2011 4:28 PM, Petrucio wrote:
Yes, I've seen your post earlier but haven't had time to test it,
indeed it looks like they are the same problem.
I'll test it later tonight, and let you know if it solves my problem
too.
Thanks everyone for the inputs.
On Oct 18, 1:01 pm, Dragonfyre13<[email protected]> wrote:
Could your issue be related to
this:http://groups.google.com/group/web2py/browse_thread/thread/c855778275...
You should be able to use (with some small difficulty in the
interface) heapy to trace where you are using memory. Where I traced
it down to was db._timings. That attribute seems safe to reset
("db._timings = []") whenever you do a commit, which is how I'm
freeing the memory now. Dropped memory growth by leaps and bounds.
On Oct 18, 8:55 am, Ross Peoples<[email protected]> wrote:
Not sure what effect it will have, but I believe the only way to really free
memory in Python is to use something like this:
rows = db(...).select(...)
del rows
This won't immediately free the memory, but might make it free faster than
dereferencing it. Alternatively, you can call gc.collect() to force
dereferenced objects to be freed, but this is generally bad practice. There
are only a few cases where you should actually use this, and your *might* be
one. So try del or gc.collect() and see if that helps any. Just keep in mind
that Python (or any managed memory language) makes it very difficult to
manage memory manually.
