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 <dragonfyr...@gmail.com> 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 <ross.peop...@gmail.com> 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.
