We have almost the same middleware on all our projects, it brings the same memory improvement. My guess is that the number of roots the php garbage collector waits is too high for most of the situations

Can you share the impact on CPU?
Usually RAM is much cheaper than CPU

Can you share the impact on CPU?

Usually RAM is much cheaper than CPU

We haven't seen any noticeable difference in the CPU load graphs but our worker servers aren't under heavy load. It takes around 1ms each time we call gc_collect_cycles().

We have almost the same middleware on all our projects, it brings the same memory improvement. My guess is that the number of roots the php garbage collector waits is too high for most of the situations

Yes, that was my conclusion as well. And it is my understanding that PHP will adjust that threshold higher or lower each time gc runs depending on how much was cleaned up. If not much was cleaned up, then it will wait longer. For some reason in my case, the threshold gets extended higher and higher and it takes longer and longer for gc to run on its own.

And it is my understanding that PHP will adjust that threshold higher or lower each time gc runs depending on how much was cleaned up

PHP run GC when the number of object is > 10K (it's configurable, but only during compile time)

And it is my understanding that PHP will adjust that threshold higher or lower each time gc runs depending on how much was cleaned up

PHP run GC when the number of object is > 10K (it's configurable, but only during compile time)

👍 and the threshold was getting extended to 20k, then 30k, etc. each time the automatic gc would run.

We discussed that on Slack and I investigated the way the GC works in PHP.

Manual runs of the GC (triggered by the gc_collect_cycles() function don't adjust the threshold at all.
Automatic runs are adjusting the threshold based on the number of collected cycles: if less than 100, the threshold gets increased by 10000 (it starts at 10001) otherwise it gets decreased by 10000 if higher than the initial one.

But this means that if an automatic GC run cannot collect objects (because you have lots of alive objects at that time), it will increase the threshold and that threshold won't ever decrease again if those objects are cleaned by the manual run.

I added a call to gc_collect_cycles() in my application after each message is handled,

I have applied this PR (along with an echo statement to tell me when that line is run) to my dev stack, and started my 5 workers (We have over 1000 workers in production),

Without running any messages, just sitting there with a worker started, the gc_collect_cycles is running over and over and over again - continuously every few seconds (evidenced by logging out to the terminal)

This is not "after each message is handled" like you stated, its near continuous... and obviously if there are more than worker on the same server, that "continuous" is x the n number of workers also.

If you needed it "after each message is handled" surely then it should be listened with WorkerMessageHandledEvent?

Or am I missing something?

@PhilETaylor initially, it was inside the foreach ($envelopes as $envelope) { loop, but in the conversation here #52253 (comment), we discussed moving it outside of the foreach and that was done in this commit 06b0713. We are missing some additional logic around the gc_collect_cycles() call now to only run it when the receivers return envelopes. I will work on another commit to address this.

Edit: Try this commit 0084c45

@jwage Thanks - the 0084c45 fixes the "continuous" calling. I'm deploying this to "production" now, if you dont hear from me, it didn't break haha.

@jwage Thanks - the 0084c45 fixes the "continuous" calling. I'm deploying this to "production" now, if you dont hear from me, it didn't break haha.

@PhilETaylor 😮 you live on the bleeding edge :) :)

@jwage nothing like running a SaaS with 1000s of paying users on decent code :) Symfony makes me powerful
Current status:

edit: Nothing broke :-) but no huge decrease in memory for me either... dip is the deployment

@PhilETaylor it is my understanding that if your code doesn't have any cyclic references, then the gc_collect_cycles() won't have to do anything because the objects will be destroyed immediately when the refcount === 0. So if your code doesn't have any cyclic references, then you won't see any benefit. Did you see any difference in your cpu/load graphs?

The CPU and Load graphs have their normal spike during deployment but other than that the loads before and after are pretty consistent with each other with no major decrease and no major increase

The CPU and Load graphs have their normal spike during deployment but other than that the loads before and after are pretty consistent with each other with no major decrease and no major increase

Thanks. I am not expecting a drop, but there was some concern that it could increase cpu usage since we're calling gc more often than we were before. Thanks for testing!

Thank you @jwage.