mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
[Question] Why is memory still increasing by using EM flush ? #5861
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @poolerMF on GitHub (Jan 25, 2018).
Originally assigned to: @Ocramius on GitHub.
example:
result:
and then I refresh page, result:
after X refreshes in a row, result will be:
then ... I'm waiting X second and making another refresh:
why is it using different memory every first time ?
when I'm not making flush, memory is STILL SAME -> 2097152
is it bug of UnitOfWork .. or something with apache ? php ? db ?
I have never ending loop for selecting & creating entities ... after 1 hour apache process is using more than 500MB of memory
@jvasseur commented on GitHub (Jan 25, 2018):
My guess would be that you have some kind of logger active that keep in memory queries executed by
flush.@poolerMF commented on GitHub (Jan 26, 2018):
@jvasseur no I don't have
if I had, memory will be incerased EVERY time ... you see, that memory is not increased every time
I tested it in another NEW project and result is same
@Ocramius commented on GitHub (Jan 26, 2018):
Can you try using https://github.com/Ocramius/DoctrineBatchUtils and see if
the problem still occurs for that one loop?
Do you have any listeners or loggers attached to the connection or the
entitymanager?
On 26 Jan 2018 09:12, "poolerMF" notifications@github.com wrote:
@coudenysj commented on GitHub (Jan 26, 2018):
@poolerMF It is a pretty basic approach, but you could dump the entity manager in a file a couple of times, and use
diffto figure out what's going on: https://blog.jachim.be/2013/01/finding-memory-leaks-in-php-objects/.@poolerMF commented on GitHub (Jan 26, 2018):
I tried to test it in NEW CLEAN project as I wrote ... and result was same
@Ocramius SimpleBatchIteratorAggregate is doing same thing as me in script ... I'm calling flush and clear after 500 iterations ... I tried It with transaction, but result is same
@coudenysj it's not possible to dump EM or UnitOfWork - apache will get out of memory
I need better tool for measuring it ... any ideas ?
@Ocramius commented on GitHub (Jan 26, 2018):
Dumping the keys of the
UnitOfWork#identityMapwould be sufficient - no need to dump the contents.@poolerMF commented on GitHub (Jan 26, 2018):
I tried and identityMap is empty after every EM->clear
I found DebugUnitOfWorkListener .. tried it and result after every flush:
Flush Operation [] - Empty identity map.
but it's OK that identity map is empty, it's normal behaviour after calling EM->clear
@Ocramius commented on GitHub (Jan 26, 2018):
@poolerMF are you running the latest ORM version? Any other properties we can check?
What about the listeners? Anything registered?
@coudenysj commented on GitHub (Jan 28, 2018):
@poolerMF Can you describe your setup a bit more? It is kind of strange that your memory keeps going up when you're doing page refreshes (as that would be new PHP runs every time).
@poolerMF commented on GitHub (Jan 28, 2018):
@coudenysj look at my first post ...
@coudenysj commented on GitHub (Jan 29, 2018):
@poolerMF Can you push the Symfony project to github somewhere? By using Symfony, you have SQL logging, etc... in the Symfony profiler.
@poolerMF commented on GitHub (Jan 29, 2018):
@coudenysj is it enough for you ?
or you can dump memory in every loop (1-10)
@coudenysj commented on GitHub (Jan 29, 2018):
@poolerMF I've add the code in a branch on my fork.
First of all, the assertSame can never be the same, because you declare loop variables (which impact the memory usage).
The reason why the memory is increasing, is the SQL Logger in the tests. If you disabled it (like I did in the setUp), you don't get the extra memory usage.
@poolerMF commented on GitHub (Jan 30, 2018):
@coudenysj I didn't test that code, I made it quickly
finnaly I find out, that memory increasing was maybe becouse of SQL logger ... but still it has weird behaviour if using SQL logger (memory is still same ... it should increase every time)
@Ocramius commented on GitHub (Jan 30, 2018):
Closing here then :)