(findOneBy) Allowed memory size of 2345643 bytes exhausted #5571

New Issue

2026-01-22T15:11:36+01:00

admin commented

2026-01-22 15:11:36 +01:00

Originally created by @imsheng on GitHub (Jun 8, 2017).

Originally assigned to: @Ocramius on GitHub.

        while (true) {
            $flow = $this->getDoctrine()->getRepository('FlowBundle:Flow')->find($id);
            unset($flow);
        }

execute this code, memory will be growing, and finally exceeded the limit.
I need to do a crawler and cycle run.

Originally created by @imsheng on GitHub (Jun 8, 2017). Originally assigned to: @Ocramius on GitHub. ``` while (true) { $flow = $this->getDoctrine()->getRepository('FlowBundle:Flow')->find($id); unset($flow); } ``` execute this code, memory will be growing, and finally exceeded the limit. I need to do a crawler and cycle run.

admin added the Invalid label 2026-01-22 15:11:36 +01:00

admin closed this issue

2026-01-22 15:11:36 +01:00

admin commented

2026-01-22 15:11:37 +01:00

@Ocramius commented on GitHub (Jun 8, 2017):

Any DB fetch will cause entities to be stored in the UnitOfWork as "managed instances. You will need to call EntityManager#clear() to avoid running out of memory.

See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/batch-processing.html
See https://github.com/Ocramius/DoctrineBatchUtils

@Ocramius commented on GitHub (Jun 8, 2017): Any DB fetch will cause entities to be stored in the `UnitOfWork` as "managed instances. You will need to call `EntityManager#clear()` to avoid running out of memory. See http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/batch-processing.html See https://github.com/Ocramius/DoctrineBatchUtils

admin commented

2026-01-22 15:11:38 +01:00

@drewek-smf commented on GitHub (Nov 15, 2017):

Sorry for re-opening this. I have a quite similar affect as described by imsheng, using Doctrine ORM 2.5.12 with Symfony 3.3.10.

I'm importing records from (eventually large) input files, these are related to records which potentially -
but not necessarily - exist in db. During development, these records do not exist. This is why the importer declines all records, therefore it does never call flush() on the Entity Manager. A find() tries to load the parent record, but as no Entity is returned, it't impossible to call detach() and it does not make sense to call clear (at least it does not help). In the end, I get the memory-exhausted-error.

I will now try to fix this by loading the primary keys as array, to see if they exist, and then use Proxies to assign the parent record to an imported one. Maybe this will help, but it's interesting nevertheless, where this issue comes from, and how it can be fixed.

@drewek-smf commented on GitHub (Nov 15, 2017): Sorry for re-opening this. I have a quite similar affect as described by imsheng, using Doctrine ORM 2.5.12 with Symfony 3.3.10. I'm importing records from (eventually large) input files, these are related to records which potentially - but not necessarily - exist in db. During development, these records do not exist. This is why the importer declines all records, therefore it does never call flush() on the Entity Manager. A find() tries to load the parent record, but as no Entity is returned, it't impossible to call detach() and it does not make sense to call clear (at least it does not help). In the end, I get the memory-exhausted-error. I will now try to fix this by loading the primary keys as array, to see if they exist, and then use Proxies to assign the parent record to an imported one. Maybe this will help, but it's interesting nevertheless, where this issue comes from, and how it can be fixed.

admin commented

2026-01-22 15:11:38 +01:00

@drewek-smf commented on GitHub (Nov 15, 2017):

Oops... Well, you know, sometimes it helps to complain, just for fate giving you the solution right afterwards. I am sorry, my issue above is not at all related to Doctrine. Hard to believe, but it is instead related to a routine which writes debug-logs for missing parent records. Due to a mis-configuration, the logger internally used the so called fingers_crossed handler, which holds all messages in memory until some error occurs, an then writes them delayed. And I was so sure that Doctrine is to blame... :-) Sorry again.

@drewek-smf commented on GitHub (Nov 15, 2017): Oops... Well, you know, sometimes it helps to complain, just for fate giving you the solution right afterwards. I am sorry, my issue above is not at all related to Doctrine. Hard to believe, but it is instead related to a routine which writes debug-logs for missing parent records. Due to a mis-configuration, the logger internally used the so called fingers_crossed handler, which holds all messages in memory until some error occurs, an then writes them delayed. And I was so sure that Doctrine is to blame... :-) Sorry again.

admin referenced this issue

2026-01-22 16:04:58 +01:00

[PR #5571] #1168 Add support for array parameters on the SQLFilter #9649

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5571