The issue is dat PHP doesn’t support Cgroups yet so unless we apply tacky method where we check every second the load the user gens it will never work …
Maybe it’s worth integrating this script at the panel level? GitHub - oulfr/php
It really works and this is the best solution so far. FPM limits.
But the problem is that when adding a new user or changing the package for an existing one, you need to restart the script manually.
I was able to do this with cgroups v2 (available only above Ubuntu 24)
I used cgroups rules to auto apply cgroups restrictions on user level, so it automatically applies the rule to any new fpm processes launched under the user.
PHP doesn’t support it yet …
I do not understand this. PHP FPM runs the master process with the user root. Is that what you are talking about? And all the child processes are run by the individual users, that can be cgroup-ed.
It can’t be done at the moment at kernel level without any other extra scripts. Until php-fpm support it …
Cgroups are not applied to forked processes. So when php-fpm forks an user pool process the cgroup restrictions are not applied.
Please readup on cgrulesengd, it automatically applies cgroup to forked processes as it run as daemon.
Ok, can we please assume I did my research on this topic and that the way php-fpm forks user processes from a root process means that cgroups won’t be applied?
But anyway, I did my testing and research, feel free to do your own. I’ll gladly merge any good looking PR that fixes this issue by changing some config settings.
Edit:
Hopefully cgrulesengd can solve this issue but as DirectAdmin and other admin panels build php-fpm from source to fix this issue I’m not sure it will.
Atm. I’m working on something else so I cannot test it as we speak.
I will raise a PR soon.
hi @oulfr is this added for current application release?
Hi, I’ve been following the discussions regarding the complexity of implementing native cgroups support for PHP-FPM within HestiaCP. I understand the main challenge lies in how PHP-FPM manages its child processes and the differences between cgroups v1/v2 across various distributions.
However, for those of us looking for an immediate and automated solution without waiting for full native GUI integration, I’d like to propose an OS-level approach using Systemd User Slices instead of application-level limiting.
The Proposal:
Instead of trying to make Hestia manage cgroups through its internal PHP-FPM logic, we can use a post_user_add Hook that leverages native User Slices (standard in Cgroups v2).
Why this approach?
-
PHP Version Agnostic: It doesn’t matter if the user is running PHP 7.4, 8.2, or multiple versions. All processes (PHP-FPM, Cron, SSH) are tied to the same UID.
-
UID-based Control: By limiting the
user-$UID.slice, the Linux kernel aggregates the resource consumption of every process owned by that user. If the sum exceeds the limit, the kernel throttles them. -
Persistency: Using
systemctl set-propertycreates persistent configuration files in/etc/systemd/system.control/, meaning limits survive reboots and service restarts.
Example Implementation (Hook Script):
We can create a script at /usr/local/hestia/conf/hooks/post_user_add.sh:
Bash
#!/bin/bash
# /usr/local/hestia/conf/hooks/post_user_add.sh
USER=$1
USER_UID=$(id -u "$USER")
if [ -n "$USER_UID" ]; then
# Apply limits to the user's slice
# This covers PHP, Cron, and SSH combined
systemctl set-property "user-${USER_UID}.slice" CPUQuota=50% MemoryLimit=512M
# Log the event
echo "$(date) - Resource limits applied to $USER (UID: $USER_UID)" >> /var/log/hestia/resource_limits.log
fi
Does the team see this as a viable “lightweight” alternative or fallback for resource management?
While it wouldn’t be visually integrated into the Hestia dashboard immediately, it solves the “noisy neighbor” problem and the manual task of setting limits for new users. Are there any technical drawbacks I might be overlooking, particularly regarding how Hestia manages on-demand services?
Looking forward to your thoughts!