Re: [web2py] Memory leak - followup
what if you do this?
class Blah():
def __init__(self):
self.nick = db.person[1].nick
def blah_f():
return Blah()
p = cache.ram('blahblah', blah_f,time_expire=30)
2011/1/2 David Zejda :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Finally I had enough time to find out, where is the main root of my
> memory leak.
>
> Consider two scenarios:
>
> 1. start web2py server
>
> 2. execute controller function with contents:
>
> def blah():
> return Storage(dict(nick=db.person[1].nick))
>
> p = cache.ram('blahblah',blah,time_expire=30)
>
> 3. guppy stats:
>
> Partition of a set of 119902 objects. Total size = 17240104 bytes.
> Index Count % Size % Cumulative % Kind (class / dict of class)
> 0 64658 54 5946560 34 5946560 34 str
> 1 24649 21 2172768 13 8119328 47 tuple
> 2 624 1 2091648 12 10210976 59 dict of gluon.dal.Field
> 3 706 1 888112 5 11099088 64 dict (no owner)
> 4 282 0 876912 5 11976000 69 dict of module
> 5 6701 6 804120 5 12780120 74 types.CodeType
> 6 6359 5 763080 4 13543200 79 function
> 7 652 1 571680 3 14114880 82 type
> 8 652 1 501280 3 14616160 85 dict of type
> 9 451 0 454984 3 15071144 87 dict of class
> <342 more rows. Type e.g. '_.more' to view.>
>
>
> 1. start web2py server
>
> 2. execute controller function with contents (nick is plain string):
>
> class Blah():
> def __init__(self):
> self.nick = db.person[1].nick
>
> p = cache.ram('blahblah',Blah,time_expire=30)
>
> 3. guppy stats:
>
> Partition of a set of 13 objects. Total size = 21017568 bytes.
> Index Count % Size % Cumulative % Kind (class / dict of class)
> 0 69722 53 6343688 30 6343688 30 str
> 1 1248 1 4183296 20 10526984 50 dict of gluon.dal.Field
> 2 26193 20 2334008 11 12860992 61 tuple
> 3 756 1 987360 5 13848352 66 dict (no owner)
> 4 282 0 876912 4 14725264 70 dict of module
> 5 7056 5 846720 4 15571984 74 types.CodeType
> 6 6686 5 802320 4 16374304 78 function
> 7 654 0 573440 3 16947744 81 type
> 8 654 0 501840 2 17449584 83 dict of type
> 9 459 0 471048 2 17920632 85 dict of class
> <356 more rows. Type e.g. '_.more' to view.>
>
> Please, look at dict of gluon.dal.Field. In the second scenario the
> count is doubled, which means that db model remains in the memory twice,
> which is bad.
>
> I did not try the same with simplier model, so I do not have idea
> whether it matters.
>
> In my case it will not be too difficult to replace my own classes with
> dicts or Storages, but maybe the findings will help somebody else facing
> similar leak..
>
> Nice year to all :)
> David
>
> - --
> 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
>
> iEYEARECAAYFAk0gqW4ACgkQ3oCkkciamVH0JACfWPEaSQX+7/OqeGeWNhtJr4/R
> JzwAn3Z17zjKv93dxjDTuM2KorzI6LB/
> =OKMq
> -END PGP SIGNATURE-
>
[web2py] Memory leak - followup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Finally I had enough time to find out, where is the main root of my
memory leak.
Consider two scenarios:
1. start web2py server
2. execute controller function with contents:
def blah():
return Storage(dict(nick=db.person[1].nick))
p = cache.ram('blahblah',blah,time_expire=30)
3. guppy stats:
Partition of a set of 119902 objects. Total size = 17240104 bytes.
Index Count % Size % Cumulative % Kind (class / dict of class)
0 64658 54 5946560 34 5946560 34 str
1 24649 21 2172768 13 8119328 47 tuple
2624 1 2091648 12 10210976 59 dict of gluon.dal.Field
3706 1 888112 5 11099088 64 dict (no owner)
4282 0 876912 5 11976000 69 dict of module
5 6701 6 804120 5 12780120 74 types.CodeType
6 6359 5 763080 4 13543200 79 function
7652 1 571680 3 14114880 82 type
8652 1 501280 3 14616160 85 dict of type
9451 0 454984 3 15071144 87 dict of class
<342 more rows. Type e.g. '_.more' to view.>
1. start web2py server
2. execute controller function with contents (nick is plain string):
class Blah():
def __init__(self):
self.nick = db.person[1].nick
p = cache.ram('blahblah',Blah,time_expire=30)
3. guppy stats:
Partition of a set of 13 objects. Total size = 21017568 bytes.
Index Count % Size % Cumulative % Kind (class / dict of class)
0 69722 53 6343688 30 6343688 30 str
1 1248 1 4183296 20 10526984 50 dict of gluon.dal.Field
2 26193 20 2334008 11 12860992 61 tuple
3756 1 987360 5 13848352 66 dict (no owner)
4282 0 876912 4 14725264 70 dict of module
5 7056 5 846720 4 15571984 74 types.CodeType
6 6686 5 802320 4 16374304 78 function
7654 0 573440 3 16947744 81 type
8654 0 501840 2 17449584 83 dict of type
9459 0 471048 2 17920632 85 dict of class
<356 more rows. Type e.g. '_.more' to view.>
Please, look at dict of gluon.dal.Field. In the second scenario the
count is doubled, which means that db model remains in the memory twice,
which is bad.
I did not try the same with simplier model, so I do not have idea
whether it matters.
In my case it will not be too difficult to replace my own classes with
dicts or Storages, but maybe the findings will help somebody else facing
similar leak..
Nice year to all :)
David
- --
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
iEYEARECAAYFAk0gqW4ACgkQ3oCkkciamVH0JACfWPEaSQX+7/OqeGeWNhtJr4/R
JzwAn3Z17zjKv93dxjDTuM2KorzI6LB/
=OKMq
-END PGP SIGNATURE-
