Pool memory utilization display is incorrect (not quite the template's fault though)

[victor-sudakov]

Hello!

The "pool XXX memory utilization" item uses proc.mem["XXX",,,,pmem] and is very incorrect for this reason. When you have many php-fpm children, this item may show 400% or more of RAM (and an alarm triggers), but in fact there is still plenty of free RAM on the host (as top shows).

This happens IMHO because proc.mem calculates the memory incorrectly: it just multiplies each child's %MEM by the number of children, not taking into account that most memory is shared between children. This is not your template's fault per se, this is the fault of the Zabbix agent logic.

Still, can we think of providing a more realistic picture of the memory consumption of a pool? By analyzing something in /proc for example?

[welcome]

Thank you so much for opening your first issue here! 🌸
✅ I hope you have kindly checked any other opened issues to make sure that it's not a duplicate 🙏
✅ And you have read the Wiki of this project that contains a full documentation, specifically the Installation instructions and Troubleshooting guide 😇
ℹ️ You may add any additional information by editing your original post or by posting additional comments below.
ℹ️ We need some time to read your issue and verify it, so please, be patient 😇
ℹ️ Any questions or comments regarding your issue will be posted here below that may require your response. So, please, don't miss the Github notifications about new updates on this topic 😉

We will kindly investigate the information you provided and hopefully return to you as soon as possible! 😊

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[victor-sudakov]

Ping!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rvalitov]

@victor-sudakov Thank you for your comments and sorry for a late reply. According to the Zabbix manual the pmem is supposed to show the percentage of real memory used. May be you're right and the proc.mem calculation is not correct. You said that memory is shared between PHP-FPM children. Perhaps you know documentation where I can read about it? If you have any ideas how to improve this, please kindly share them. I think that reading /proc will gave exactly the same results as proc.mem. Or do you suggest to do some processing to the data received from /proc?

[victor-sudakov]

I've studied the matter a bit and come to the conclusion that there is not much we can do about it. A good explanation of this effect is at http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html

The moral of this story is that process memory usage on Linux is a complex matter; you can't just run ps and know what is going on. This is especially true when you deal with programs that create a lot of identical children processes

[rvalitov]

@victor-sudakov Thank you for the link. A very good explanation.
After a little googling I found the following methods to get the memory consumption that we need:

1. Use smem

Use smem, which is an alternative to ps which calculates the USS and PSS per process. You probably want the PSS.

USS - Unique Set Size. This is the amount of unshared memory unique to that process (think of it as U for unique memory). It does not include shared memory. Thus this will under-report the amount of memory a process uses, but it is helpful when you want to ignore shared memory.

PSS - Proportional Set Size. This is what you want. It adds together the unique memory (USS), along with a proportion of its shared memory divided by the number of processes sharing that memory. Thus it will give you an accurate representation of how much actual physical memory is being used per process - with shared memory truly represented as shared. Think of the P being for physical memory.

It seems that PSS is exactly what we need.

2. Use pmap
3. Use smaps

[victor-sudakov]

smem has too many runtime dependencies. pmap and smaps will probably require root privileges.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.