PHP Memory VS RoadRunner Worker Memory

[dobryy]

Hi,

When I check PHP memory usage with memory_get_usage or memory_get_peak_usage at the end of the action of the Symfony controller I see some value around 33 Mb but when I check the memory usage with rr workers I see that around 76 Mb are allocated for the worker.

Is it expected behavior? Why is the difference that big? Is there any way to free up the memory?

[rustatian]

Hey @dobryy 👋🏻
I'm not a PHP dev, so correct me if I'm wrong, but memory_get_usage shows only currently allocated memory by the PHP script, but rr workers shows allocated RSS memory by the whole PHP process. On Linux, RR reads /proc/<pid>/statm, which is inaccurate (according to the man-pages) because it might include the currently swapped-out pages.

[rustatian]

I guess in the calm state, the RSS memory should be approx. equal to the memory_get_usage. /proc/<pid>/statm is a common way to know the allocated memory by the process. There is no need to do something in your code to reduce memory usage. You may also check the RSS memory with the htop, top or btop utilities and compare it to the RR's value.

[wolfy-j]

In Spiral memory usage are pretty stable, and on bare app with few services sits around 36mb. The difference you might see is the gap managed by PHP GC. It can be caused by inefficient core initialization or re-initialization between requests which creates a ton of garbage.

Can you try to check the memory consuption on clean Symfony installation to make sure that it's driven by your app vs Symfony Kernel. That would be the first step.

[wolfy-j]

Also, you shouln't worry that much about RSS, since PHP can always de-allocate this memory to system, but it's nice to have some memory available on short notice by the process.

[dobryy]

I have another application that uses Symfony and RR. And memory usage per worker is 35Mb.

Definitely, such huge memory usage is caused by the nature of the application. Some endpoints return quite a lot of data but it was curious to me why this memory is never freed up.

Thank you for the explanation, makes sense to me. I'll try to dig deeper into what can cause such memory usage.

[rustatian]

One way Linux freed up the memory is madv_free syscall. But, if you have enough memory, Linux might postpone freeing the memory. If the memory usage constantly grows w/o freeing, that is the problem, keep in mind :)

To check for sure, you may run some script that allocates a lot of memory to force Linux to get the freed memory from the processes (RR worker).