Thank you for the replies,
Just to be sure I understand you, are you suggesting doing something like
the following instead?
>>default.py
def entry_point()
db = get_db()
# use database
>>db.py
from gluon.packages.dal.pydal import DAL, Field
def get_db()
db =
On Friday, February 3, 2017 at 4:05:55 PM UTC-5, MarkEdson AtWork wrote:
>
> I found a similar issue with a db.py module with code like this in it...
>
> from gluon.packages.dal.pydal import DAL, Field
> db = DAL("sqlite://storage.sqlite")
> db.define_table(
> "test",
>
On Monday, February 6, 2017 at 9:00:21 AM UTC-8, MarkEdson AtWork wrote:
>
> I should also mention that I recently updated my code to use multiple
> controllers.
>
> On Monday, February 6, 2017 at 7:53:20 AM UTC-8, MarkEdson AtWork wrote:
>>
>> Update,
>> I ran the sample code I placed in this
I should also mention that I recently updated my code to use multiple
controllers.
On Monday, February 6, 2017 at 7:53:20 AM UTC-8, MarkEdson AtWork wrote:
>
> Update,
> I ran the sample code I placed in this post over the weekend and it ended
> up consuming 1.8GB before python stopped
Update,
I ran the sample code I placed in this post over the weekend and it ended
up consuming 1.8GB before python stopped functioning.
I am running pyDAL (17.1) with a stable web2py release.
Is this the built-in Rocket server issue I have run into?
On Friday, December 24, 2010 at 4:16:24 PM
I found a similar issue with a db.py module with code like this in it...
from gluon.packages.dal.pydal import DAL, Field
db = DAL("sqlite://storage.sqlite")
db.define_table(
"test",
Field("myid", default=DEFAULT_VALUE, length=15),
Field("name",
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think you are right. It is highly probable that my app is leaking
somehow. I do not cache dal objects directly and I use finite set of
indentifiers for cached objects, but it is possible that some of my
objects reference dal objects in an unwanted
I monitored my own app running under Rocket in development mode with Ubuntu
System Monitor and the RSS memory size started at about 26 MB. After pushing
every link in the interface it had grown to 38.5 MB and then stopped at that
size. It has been running for over a day now with no further
I used this tool to track down memory leaks in a Python gstreamer program I
wrote
http://mg.pov.lt/objgraph/
provides object graphs of the heap. Also the web page contains good docs on
tracking down memory problems. It produces PNG files if graphviz is
available or from the command line use
Thanks for the all replies!
I do not directly cache DAL objects, but yes, caching may be behind
the leak
through some references between objects. Maybe I'll examine it with
objgraph,
and I agree, it would be nice to have the function at hand in the
admin interface.
Cherrypy anyserver brings no
So you do use caching? Is it RAM caching or disk caching? If RAM
caching, it could be that running under Cherokee and uWSGI is deleting
the environment that web2py is run in after a certain number of
requests. This would reduce the usefulness of a RAM cache but would
also produce the results
Are we sure it is not a cache issue? Caching selects or actions with
arguments eats memory.
On Dec 24, 6:26 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Dec 24, 2010, at 4:20 PM, Thadeus Burgess wrote:
This is due to the built in rocket server (it is not ment for production).
If you
Thadeus,
You seem to have more knowledge about this problem. Can you file a
bug report? Did you know that Rocket was recently updated fixing
several bugs (and creating one that has already be addressed). I'm
not denying the possibility, but let's be a good open source
community.
David,
If
There is an easy way to check this: run web2py with any other web
server using the new web2py/anyserver.py script.
On Dec 24, 10:12 pm, Timbo tfarr...@owassobible.org wrote:
Thadeus,
You seem to have more knowledge about this problem. Can you file a
bug report? Did you know that Rocket
14 matches
Mail list logo
