DDC-1682: EntityManager::clear() not working as expected. #2114

Closed
opened 2026-01-22 13:41:25 +01:00 by admin · 18 comments
Owner

Originally created by @doctrinebot on GitHub (Mar 5, 2012).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user gcaseres:

I've been reading Doctrine2 Batch Processing documentation.
I've a simplified the code and made a sample where I'm using a Repository inside the loop:

for ($i=1; $i<=10000; <ins></ins>$i) {
     $user = $this->_em->getRepository('some user class')->find($i);
     $this->_em->clear();

     //Clear variables to ensure garbage collections     
     unset($user);
     $user = null;

}

I expect that this script will consume some constant memory in all iterations, but what happens is that every iteration raises memory consumption (more iterations, more memory).... i think that the clear method has some sort of memory leak.

In my production environment (with complex script), i reach a memory limit exception even with 600MB limit... but if I clear the EntityManager on every iteration, shouldn't memory be freed?

Sorry for my bad english.

Originally created by @doctrinebot on GitHub (Mar 5, 2012). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user gcaseres: I've been reading Doctrine2 Batch Processing documentation. I've a simplified the code and made a sample where I'm using a Repository inside the loop: ``` for ($i=1; $i<=10000; <ins></ins>$i) { $user = $this->_em->getRepository('some user class')->find($i); $this->_em->clear(); //Clear variables to ensure garbage collections unset($user); $user = null; } ``` I expect that this script will consume some constant memory in all iterations, but what happens is that every iteration raises memory consumption (more iterations, more memory).... i think that the clear method has some sort of memory leak. In my production environment (with complex script), i reach a memory limit exception even with 600MB limit... but if I clear the EntityManager on every iteration, shouldn't memory be freed? Sorry for my bad english.
admin added the Bug label 2026-01-22 13:41:25 +01:00
admin closed this issue 2026-01-22 13:41:26 +01:00
Author
Owner

@doctrinebot commented on GitHub (Mar 6, 2012):

Comment created by @beberlei:

You are probably running symfony2 in debug mode? Is the SQL logger enabled? This is probably not a Doctrine problem but something in your code / Symfony that keeps increasing the memory.

@doctrinebot commented on GitHub (Mar 6, 2012): Comment created by @beberlei: You are probably running symfony2 in debug mode? Is the SQL logger enabled? This is probably not a Doctrine problem but something in your code / Symfony that keeps increasing the memory.
Author
Owner

@doctrinebot commented on GitHub (Mar 6, 2012):

Comment created by gcaseres:

I've executed the script in debug and prod mode, but I had the same problem in both modes.
I don't think it's a Symfony problem because I had measured memory consumption only before, after and inside the for loop (no symfony methods involved).
About my code, I'm using simple clases with no business code, only simple Doctrine mappings (and standard repository).
Have you tested a similar code? I don't understand why memory consumption continues raising if I'm "destroying" the objects.
I tried with gc_enable and gc_collect_cycles but no success... every iteration increases memory consumption like if the previous loaded objects weren't destroyed... maybe the repository is instancing other objects in every find call that are not destroyed?

@doctrinebot commented on GitHub (Mar 6, 2012): Comment created by gcaseres: I've executed the script in debug and prod mode, but I had the same problem in both modes. I don't think it's a Symfony problem because I had measured memory consumption only before, after and inside the for loop (no symfony methods involved). About my code, I'm using simple clases with no business code, only simple Doctrine mappings (and standard repository). Have you tested a similar code? I don't understand why memory consumption continues raising if I'm "destroying" the objects. I tried with gc_enable and gc_collect_cycles but no success... every iteration increases memory consumption like if the previous loaded objects weren't destroyed... maybe the repository is instancing other objects in every find call that are not destroyed?
Author
Owner

@doctrinebot commented on GitHub (Mar 6, 2012):

Comment created by @beberlei:

are you using lifecycle listeners? access global state or something?

@doctrinebot commented on GitHub (Mar 6, 2012): Comment created by @beberlei: are you using lifecycle listeners? access global state or something?
Author
Owner

@doctrinebot commented on GitHub (Mar 11, 2012):

Comment created by @beberlei:

Can you generate an xdebug trace for some of the $i's ? say 100 and 1000 with xdebug_start_trace("/tmp/loop".$i); and xdebug_stop_trace(); and upload them? Maybe you can compare yourself, where in the loop the memory increases and if clear even empties it or not.

@doctrinebot commented on GitHub (Mar 11, 2012): Comment created by @beberlei: Can you generate an xdebug trace for some of the $i's ? say 100 and 1000 with xdebug_start_trace("/tmp/loop".$i); and xdebug_stop_trace(); and upload them? Maybe you can compare yourself, where in the loop the memory increases and if clear even empties it or not.
Author
Owner

@doctrinebot commented on GitHub (Apr 1, 2012):

Comment created by @ocramius:

Any news about this one? There's been more than one case where the Symfony data collector (for debug) caused problems like this one... Imo this is not a ORM issue.

@doctrinebot commented on GitHub (Apr 1, 2012): Comment created by @ocramius: Any news about this one? There's been more than one case where the Symfony data collector (for debug) caused problems like this one... Imo this is not a ORM issue.
Author
Owner

@doctrinebot commented on GitHub (May 27, 2012):

Comment created by @beberlei:

No feedback given.

@doctrinebot commented on GitHub (May 27, 2012): Comment created by @beberlei: No feedback given.
Author
Owner

@doctrinebot commented on GitHub (May 27, 2012):

Issue was closed with resolution "Incomplete"

@doctrinebot commented on GitHub (May 27, 2012): Issue was closed with resolution "Incomplete"
Author
Owner

@doctrinebot commented on GitHub (Aug 28, 2012):

Comment created by mvrhov:

I've been debugging a similar issue today. And Yes, the culprit is the Symfony's data collector. Running the command with --no-debug worked like a charm.

@doctrinebot commented on GitHub (Aug 28, 2012): Comment created by mvrhov: I've been debugging a similar issue today. And Yes, the culprit is the Symfony's data collector. Running the command with --no-debug worked like a charm.
Author
Owner

@doctrinebot commented on GitHub (Apr 15, 2013):

Comment created by pourquoi:

same issue here with 2.2.3, php 5.4 & symfony 2.1
have a symfony command running as deamon with --no-debug and no listeners

while(true) {
$q = $this->em->createQueryBuilder()->select()...->getQuery();
$results = $q->getResult(AbstractQuery::HYDRATE_ARRAY); // commenting this line resolve the memory leak
$this->em->clear();
gc_collect_cycles(); // with or without does not change the issue
}

the consecutive traces shows that memory does not reduce after clear()

@doctrinebot commented on GitHub (Apr 15, 2013): Comment created by pourquoi: same issue here with 2.2.3, php 5.4 & symfony 2.1 have a symfony command running as deamon with --no-debug and no listeners while(true) { $q = $this->em->createQueryBuilder()->select()...->getQuery(); $results = $q->getResult(AbstractQuery::HYDRATE_ARRAY); // commenting this line resolve the memory leak $this->em->clear(); gc_collect_cycles(); // with or without does not change the issue } the consecutive traces shows that memory does not reduce after clear()
Author
Owner

@doctrinebot commented on GitHub (Apr 15, 2013):

Comment created by @ocramius:

[~pourquoi] please check this in insulation (without Symfony2 if possible)

@doctrinebot commented on GitHub (Apr 15, 2013): Comment created by @ocramius: [~pourquoi] please check this in insulation (without Symfony2 if possible)
Author
Owner

@doctrinebot commented on GitHub (Apr 15, 2013):

Comment created by @beberlei:

this may be array hydrator related, not sure that may not cause problems.

@doctrinebot commented on GitHub (Apr 15, 2013): Comment created by @beberlei: this may be array hydrator related, not sure that may not cause problems.
Author
Owner

@doctrinebot commented on GitHub (Apr 16, 2013):

Comment created by pourquoi:

without symfony:

<?php

use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

$loader = require*once __DIR_*.'/../app/autoload.php';
$loader->add('Acme\\CoreBundle', *_DIR_*.'/../src/Acme/CoreBundle/');

$isDevMode = true;
$config = Setup::createAnnotationMetadataConfiguration(array(*_DIR_*."/../src/Acme/CoreBundle/Entity"), $isDevMode, null, null, false);

$conn = array(
    'driver' => 'pdo_mysql',
    'host' => 'localhost',
    'dbname' => 'dbname',
    'user' => 'root',
    'password' => ''
);

$em = EntityManager::create($conn, $config);

$d = new \DateTime();

while(true) {
    echo memory*get_usage() . PHP*EOL;
    $qb = $em->createQueryBuilder()
        ->select('c')
        ->from('Acme\\CoreBundle\\Entity\\Consultation', 'c')
        ->where('c.date > :date')->setParameter(':date', $d)
        ->orderBy('c.date', 'ASC');

    $q = $qb->getQuery();

    $results = $q->getResult();

    foreach($results as $c) {
        echo $c->getDate()->format('H:i:s') . PHP_EOL;
    }

    $q->free();

    $em->clear();

    gc*collect*cycles();

    echo memory*get_usage() . PHP_EOL . PHP*EOL;
}

output:

7978568
7978568

7978568
7978568

7978568
11:51:27
11474520

11474520
11473368

11473368
11473368

11473368
11473368

11473368
11473368

Am I missing something?

@doctrinebot commented on GitHub (Apr 16, 2013): Comment created by pourquoi: without symfony: ``` <?php use Doctrine\ORM\Tools\Setup; use Doctrine\ORM\EntityManager; $loader = require*once __DIR_*.'/../app/autoload.php'; $loader->add('Acme\\CoreBundle', *_DIR_*.'/../src/Acme/CoreBundle/'); $isDevMode = true; $config = Setup::createAnnotationMetadataConfiguration(array(*_DIR_*."/../src/Acme/CoreBundle/Entity"), $isDevMode, null, null, false); $conn = array( 'driver' => 'pdo_mysql', 'host' => 'localhost', 'dbname' => 'dbname', 'user' => 'root', 'password' => '' ); $em = EntityManager::create($conn, $config); $d = new \DateTime(); while(true) { echo memory*get_usage() . PHP*EOL; $qb = $em->createQueryBuilder() ->select('c') ->from('Acme\\CoreBundle\\Entity\\Consultation', 'c') ->where('c.date > :date')->setParameter(':date', $d) ->orderBy('c.date', 'ASC'); $q = $qb->getQuery(); $results = $q->getResult(); foreach($results as $c) { echo $c->getDate()->format('H:i:s') . PHP_EOL; } $q->free(); $em->clear(); gc*collect*cycles(); echo memory*get_usage() . PHP_EOL . PHP*EOL; } ``` output: ``` 7978568 7978568 7978568 7978568 7978568 11:51:27 11474520 11474520 11473368 11473368 11473368 11473368 11473368 11473368 11473368 ``` Am I missing something?
Author
Owner

@doctrinebot commented on GitHub (Apr 16, 2013):

Comment created by @ocramius:

Memory usage here seems quite constant (the change from 7978568 to 11474520 may well be because of metadata and hydrators). The output doesn't seem to be conforming your snippet though.

@doctrinebot commented on GitHub (Apr 16, 2013): Comment created by @ocramius: Memory usage here seems quite constant (the change from 7978568 to 11474520 may well be because of metadata and hydrators). The output doesn't seem to be conforming your snippet though.
Author
Owner

@doctrinebot commented on GitHub (Apr 16, 2013):

Comment created by pourquoi:

yes sorry the above output is for:

foreach($results as $c) {
    echo $c->getDate()->format('H:i:s') . PHP_EOL;
    $d = $c->getDate();
}

with

foreach($results as $c) {
    echo $c->getDate()->format('H:i:s') . PHP_EOL;
}

the output is:

3489864
12:22:27
13502680

13502680
12:22:27
13515496

13515496
12:22:27
13528328

13528328
12:22:27
13541144

13541144
12:22:27
13553976

....


74513560
12:22:27
74526520

74526520
12:22:27
74539520

74539520
12:22:27
74552560

and goes on

@doctrinebot commented on GitHub (Apr 16, 2013): Comment created by pourquoi: yes sorry the above output is for: ``` foreach($results as $c) { echo $c->getDate()->format('H:i:s') . PHP_EOL; $d = $c->getDate(); } ``` with ``` foreach($results as $c) { echo $c->getDate()->format('H:i:s') . PHP_EOL; } ``` the output is: ``` 3489864 12:22:27 13502680 13502680 12:22:27 13515496 13515496 12:22:27 13528328 13528328 12:22:27 13541144 13541144 12:22:27 13553976 .... 74513560 12:22:27 74526520 74526520 12:22:27 74539520 74539520 12:22:27 74552560 ``` and goes on
Author
Owner

@doctrinebot commented on GitHub (Apr 17, 2013):

Comment created by stof:

Do you have bidirectional relations in your user entity ? If yes, you will still have some references to the object after clearing the EntityManager (in the related object, itself reference by the user)

@doctrinebot commented on GitHub (Apr 17, 2013): Comment created by stof: Do you have bidirectional relations in your user entity ? If yes, you will still have some references to the object after clearing the EntityManager (in the related object, itself reference by the user)
Author
Owner

@doctrinebot commented on GitHub (Jun 25, 2014):

Comment created by brunolemos:

Fixed it by doing the following:

$this
->_em
->getConnection()
->getConfiguration()
->setSQLLogger(null);

@doctrinebot commented on GitHub (Jun 25, 2014): Comment created by brunolemos: Fixed it by doing the following: $this ->_em ->getConnection() ->getConfiguration() ->setSQLLogger(null);
Author
Owner

@darius-v commented on GitHub (Sep 10, 2024):

$this
->_em
->getConnection()
->getConfiguration()
->setSQLLogger(null);

does not help for me, memory usage keeps increasing

@darius-v commented on GitHub (Sep 10, 2024): ``` $this ->_em ->getConnection() ->getConfiguration() ->setSQLLogger(null); ``` does not help for me, memory usage keeps increasing
Author
Owner

@derrabus commented on GitHub (Sep 10, 2024):

@darius-v This issue has been closed for over ten years. If you're looking for support, try our discussions board instead.

@derrabus commented on GitHub (Sep 10, 2024): @darius-v This issue has been closed for over ten years. If you're looking for support, try our discussions board instead.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2114