php/symfony/doctrine memory leak?

两盒软妹~` 提交于 2019-11-27 03:25:50
Jordan Feldstein

Tried doing

$cupo->save();
$cupo->free();
$cupo = null;

(But substituting my code) And I'm still getting memory overflows. Any other ideas, SO?

Update:

I created a new environment in my databases.yml, that looks like:

all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn: 'mysql:host=localhost;dbname=.......'
      username: .....
      password: .....
      profiler: false

The profiler: false entry disables doctrine's query logging, that normally keeps a copy of every query you make. It didn't stop the memory leakage, but I was able to get about twice as far through my data importing as I was without it.

Update 2

I added

Doctrine_Manager::connection()->setAttribute(Doctrine_Core::ATTR_AUTO_FREE_QUERY_OBJECTS, true ); 

before running my queries, and changed

$cupo = null;

to

unset($cupo);

And now my script has been churning away happily. I'm pretty sure it will finish without running out of RAM this time.

Update 3

Yup. That's the winning combo.

I have just did "daemonized" script with symfony 1.4 and setting the following stopped the memory hogging:

sfConfig::set('sf_debug', false);
Delon

For a symfony task, I also faced to this issue and done following things. It worked for me.

  • Disable debug mode. Add following before db connection initialize

    sfConfig::set('sf_debug', false);
    
  • Set auto query object free attribute for db connection

    $connection->setAttribute(Doctrine_Core::ATTR_AUTO_FREE_QUERY_OBJECTS, true );
    
  • Free all object after use

    $object_name->free()
    
  • Unset all arrays after use unset($array_name)

  • Check all doctrine queries used on task. Free all queries after use. $q->free() (This is a good practice for any time of query using.)

That's all. Hope it may help someone.

Doctrine leaks and there's not much you can do about it. Make sure you use $q->free() whenever applicable to minimize the effect. Doctrine is not meant for maintenance scripts. The only way to work around this problem is to break you script to parts which will perform part of the task. One way to do that is to add a start parameter to your script and after a certain amount of objects had been processed, the script redirects to itself with a higher start value. This works well for me although it makes writing maintenance scripts more cumbersome.

Try to unset($cupo); after every saving. This should be help. An other thing is to split the script and do some batch processing.

Try to break circular reference which usually cause memory leaks with

$cupo->save();

$cupo->free(); //this call

as described in Doctrine manual.

manuel

For me , I've just initialized the task like that:

// initialize the database connection
$databaseManager = new sfDatabaseManager($this->configuration);
$connection = $databaseManager->getDatabase($options['connection'])->getConnection();
$config = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', true);
sfContext::createInstance($config);

(WITH PROD CONFIG)
and use free() after a save() on doctrine's object

the memory is stable at 25Mo

memory_get_usage=26.884071350098Mo

with php 5.3 on debian squeeze

Periodically close and re-open the connection - not sure why but it seems PDO is retaining references.

What is working for me is calling the free method like this:

$cupo->save();
$cupo->free(true); // free also the related components
unset($cupo);
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!