Copy of globals being stored in RAM when caching objects
David Zejda
Hash: SHA1
Hi :)
If you cache an object declared in controller/model, it causes that copy
of the whole environment is being stored in RAM.
This is continuation of discussion started here:
http://groups.google.com/group/web2py/browse_thread/thread/460bcad5a29a59e6
and related to the issue:
https://code.google.com/p/web2py/issues/detail?id=146
There are two odd things on the issue:
1. Excessive usage of memory
2. The cached objects are bound somehow to the copy of entire
environment (including db, but also session, request, and all other
global objects). It leads to unanticipated behaviour of the object
picked back from cache. This kind of issues is hard to track.
I encountered the second aspect months ago already and had to
accommodate my classes. Related thread:
http://www.mail-archive.com/web...@googlegroups.com/msg34333.html
David
mdipierro wrote:
> I changed the title because it is not technically a leak.
>
> A leak is when memory is allocated but not referenced and therefore
> the amount of memory grows with time.
>
> In this case - when cache.ram is used to cache an object - reloading
> the url does not cause additional memory loss which means the cached
> object is referencing the environment of the previous request.
>
> This is a problem because it is using more memory than required when
> caching objects (not when caching strings, or other simpler types) but
> the mount of memory used does not grows with time and with number of
> http request, it only grows with number of cached objects.
>
> On Jan 4, 2:57 pm, Michele Comitini <michele.comit...@gmail.com>
> wrote:
>> David,
>>
>> please open a ticket here also:
>>
>> https://code.google.com/p/web2py/issues/entry
>>
>> 2011/1/4 mdipierro <mdipie...@cs.depaul.edu>:
>>
>>> This is odd. I can reproduce the problem. What is even stranger is
>>> that if I call blahstuff once the count doubles from 24 to 48 but if I
>>> blahstuff more than once (even if with lower cache time) it does not
>>> increase the counter more than 48.
>>> I also tried caching a lambda:repr(Blah()) as opposed to Blah and the
>>> problem does not occur.
>>> Looks like when caching an instance it keep a copy in cache of the
>>> entire environment, which includes db.
>>> I do not understand why that happens since there is not reference from
>>> the cache.py code to the environment nor any reference from the Blah
>>> class.
>>> Let' move this discussion to web2py-developers. If you are not already
>>> there, please join.
>>> Massimo
>>> On Jan 4, 12:10 pm, David Zejda <d...@atlas.cz> wrote:
>>
- --
David Zejda, Open-IT cz
web development & services
http://www.o-it.info
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAk0jvAgACgkQ3oCkkciamVGZpACcCy9KbjMHKjxgAGvhUOJdpjUj
LUgAn20mTNsRvzwd4Hqigia6ezOd44dg
=ybTq
-----END PGP SIGNATURE-----
Massimo Di Pierro
Is the problem still present in trunk?
> --
> mail from:GoogleGroups "web2py-developers" mailing list
> make speech: web2py-d...@googlegroups.com
> unsubscribe: web2py-develop...@googlegroups.com
> details : http://groups.google.com/group/web2py-developers
> the project: http://code.google.com/p/web2py/
> official : http://www.web2py.com/
David Zejda
Hash: SHA1
Hi :)
The problem is still present in trunk version.
I also commented Ron's recommendations here:
https://code.google.com/p/web2py/issues/detail?id=146
Thanks for the effort!
David
Massimo Di Pierro wrote:
> This issue may be related to the gc.collect() issue.
> Is the problem still present in trunk?
- --
David Zejda, Open-IT cz
web development & services
http://www.o-it.info
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAk0wEhEACgkQ3oCkkciamVH6hgCeNWPVtamOqv4wJgwDvh17UZP5
3fsAoLfHC8oGAdBW3QtZ5A69dLNXQ1bi
=sujR
-----END PGP SIGNATURE-----