Brandon, you're a star! Creating a new environment and disabling the profiler solved the problem.
Do you think the profiler gets used by a non-existant web debug pane (to log queries that have been executed?). I'm struggling to think why the ApplicationConfiguration would get created with 'debug=true', and, like you, wonder whether this is a matter for the symfony-devs group or a trac ticket. That you've had the same problem (and managed to create a workaround) gives me the confidence to re-post to the devs group and see what they've got to say - I'm glad it wasn't me missing something obvious! Thanks again, Tony. On Feb 2, 7:59 pm, Brandon Turner <btur...@bltweb.net> wrote: > Tony, > > I tried enabling an application configuration on my long running Symfony > 1.4.1 Doctrine task and got the same behavior you did. > > As far as I can tell the memory "leaks" appear due to > Doctrine_Connection_Profiler being enabled. The > Doctrine_Connection_Profiler (if I understand it correctly) essentially > keeps a copy of every query sent to Doctrine's database connection. > Symfony is probably reusing the Doctrine_Connection for your entire task > (as it should be) and thus the profiler never gets cleared. This build > up of objects eventually causes you to run out of memory. > > The profiler is turned on in line 98 of the Doctrine plugin's > sfDoctrineDatabase.class.php file because: > (a) the database param "profiler" isn't set > - and - > (b) sf_debug is set to true > > sf_debug is hard coded to true, as you pointed out, in sfBaseTask. > Perhaps a Symfony developer could comment on this. > > In the meantime, you could set up a new environment and disable the > profiler in that environment. This can be done in your databases.yml by > adding param: "profiler: false". So your databases.yml file may look like: > > task: > symfony: > param: > profiler: false > > all: > symfony: > class: sfDoctrineDatabase > param: > dsn: <blah blah> > username: <blah blah> > password: <blah blah> > > I can't imagine running tasks in their own environment is what the > Symfony devs intended, but it seems like the only way to disable the > Doctrine profiler. Perhaps we should post on symfony_devs. I've been > experiencing out of memory issues when loading a large amount of > fixtures via doctrine:data-load - which appears to be due to this same > issue. > > Brandon > > On 02/02/2010 11:03 AM, Tony Piper wrote: > > > > > Hello. I've spent a good few hours trying to fix a memory leak in a > > Symfony Task which uses Doctrine to access a table. > > > I'm finding that if I specify an application name (so that the Task > > runs with an sfApplicationConfiguration instance) there is a memory > > leak each time I run the simplest of Doctrine queries. If I run that > > task without specifying an application name (and therefore it runs > > with an sfProjectConfiguration instance), I don't get a leak. > > > I'm guessing the memory leak is not being caused specifically by > > Doctrine - rather I believe the leak is coming from some kind of > > logging, filtering or something else in the Application context > > because in sfBaseTask::createConfiguration the > > sfApplicationConfiguration instance is always created with 'debug' set > > to true. Modifying sfBaseTask::createConfiguration to create the > > instance with 'debug' set to false throws an error about redeclaring > > sfLogger. > > > The trouble is, I can't figure out what's causing the leak because I > > don't know enough about the Symfony internals... > > > It happens regardless of whether my Task environment is 'dev' or > > 'prod'. > > > I would like to have this task run in an ApplicationConfiguration > > context so I can generate routes and use partials (for easy > > maintenance of email templates). > > > I need to fix this memory leak because I need this task to run as a > > daemon. > > > This problem is with symfony 1.4.1 running on both php 5.2.11 (via > > MAMP 1.8.3) and php 5.3.0 (native) on OS X 10.6.2, so it's likely not > > because of php 5.2.x's issue with garbage collection. > > > Can anyone help me fix this please? I can post a simple task which > > demonstrates the problem on any trivial pre-existing database if that > > would help. > > > cheers, > > > Tony. -- You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-us...@googlegroups.com. To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en.
