You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. We might need more context ; e.g. pool configuration, what kind of web application could it be, was cpu usage significantly lower with previous php releases .. etc ...
i'm experiencing issues since 8.3 that was the reason to try 8.4 and it performs like that since that moment. Only way to lower cpu usage is just restart service via service php_fpm restart.
Would it be possible to profile your web app ? e.g. pmcstat is able to do it on a cpu cycles level pcmstat -O php-sample.dat -P cycles -T -p <php process ID> might give further clues.
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.
OUTPUT:
Version & Build Information
PHP Version:
8.3: 8.3.17
8.4: 8.4.4
Build Date:
8.3: Mar 10 2025 15:24:50
8.4: Mar 9 2025 17:05:03
Configuration Files & Directories
php.ini Location:
PHP 8.3 uses: /etc/php/8.3/cli/php.ini
PHP 8.4 uses: /etc/php/8.4/cli/php.ini
Additional .ini Files Parsed:
Almost the same list except PHP 8.4 includes a new file (25-memcached.ini) that isn’t in PHP 8.3.
Extension Directory:
8.3: /usr/lib/php/20230831
8.4: /usr/lib/php/20240924
Core API & Engine Changes
PHP API / Extension Build:
Updated from API20230831 to API20240924.
Zend Engine:
8.3: Zend Engine v4.3.17 with OPcache v8.3.17
8.4: Zend Engine v4.4.4 with OPcache v8.4.4
Output Formatting Changes
Syntax Highlighting:
In PHP 8.3, highlight colors are output using tags.
In PHP 8.4, these are output using tags.
Specific Directive & Extension Differences
FFI Setting:
ffi.enable changed from preload in 8.3 to On in 8.4.
libmagic:
Version changed slightly from 543 to 545.
IMAP Extension:
PHP 8.4 now shows an “IMAP extension Version => 1.0.3” entry.
Memcached Extension:
PHP 8.4 includes a detailed block showing memcached settings and support (e.g. serializer, compression settings).
MySQL Native Driver (mysqlnd):
Updated from version 8.3.17 to 8.4.4 in several places.
PostgreSQL Settings:
pgsql.auto_reset_persistent changed from On to Off.
Session Settings:
session.sid_bits_per_character changes from 5 to 4.
session.sid_length changes from 26 to 32.
OPcache JIT Buffer:
opcache.jit_buffer_size has been reduced from 128M to 64M.
Miscellaneous
Zip Version:
Updated from 1.22.3 to 1.22.4.
CLI Binary Reference:
The underscore variable ($SERVER['']) now reflects the PHP 8.4 binary (/usr/bin/php8.4) instead of PHP 8.3.
Timing Values:
Slight differences in REQUEST_TIME_FLOAT and REQUEST_TIME reflecting the moment the CLI started.
OUTPUT: Version & Build Information PHP Version: 8.3: 8.3.17 8.4: 8.4.4 Build Date: 8.3: Mar 10 2025 15:24:50 8.4: Mar 9 2025 17:05:03 Configuration Files & Directories php.ini Location: PHP 8.3 uses: /etc/php/8.3/cli/php.ini PHP 8.4 uses: /etc/php/8.4/cli/php.ini Additional .ini Files Parsed: Almost the same list except PHP 8.4 includes a new file (25-memcached.ini) that isn’t in PHP 8.3. Extension Directory: 8.3: /usr/lib/php/20230831 8.4: /usr/lib/php/20240924 Core API & Engine Changes PHP API / Extension Build: Updated from API20230831 to API20240924. Zend Engine: 8.3: Zend Engine v4.3.17 with OPcache v8.3.17 8.4: Zend Engine v4.4.4 with OPcache v8.4.4 Output Formatting Changes Syntax Highlighting: In PHP 8.3, highlight colors are output using tags. In PHP 8.4, these are output using tags. Specific Directive & Extension Differences FFI Setting: ffi.enable changed from preload in 8.3 to On in 8.4. libmagic: Version changed slightly from 543 to 545. IMAP Extension: PHP 8.4 now shows an “IMAP extension Version => 1.0.3” entry. Memcached Extension: PHP 8.4 includes a detailed block showing memcached settings and support (e.g. serializer, compression settings). MySQL Native Driver (mysqlnd): Updated from version 8.3.17 to 8.4.4 in several places. PostgreSQL Settings: pgsql.auto_reset_persistent changed from On to Off. Session Settings: session.sid_bits_per_character changes from 5 to 4. session.sid_length changes from 26 to 32. OPcache JIT Buffer: opcache.jit_buffer_size has been reduced from 128M to 64M. Miscellaneous Zip Version: Updated from 1.22.3 to 1.22.4. CLI Binary Reference: The underscore variable ($SERVER['']) now reflects the PHP 8.4 binary (/usr/bin/php8.4) instead of PHP 8.3. Timing Values: Slight differences in REQUEST_TIME_FLOAT and REQUEST_TIME reflecting the moment the CLI started.
Hi @grisha2217, not entirely sure it is "kind of the same" here.
Is disabling memcached, for example, for a while and restesting a possibility ?
We are also noticing similar issues after upgrading to the php:8.4.7-fpm tag in Docker - we moved from php:8.3.17-fpm before. So I don't think this is isolated to FreeBSD. As with OP, we also have Memcached enabled, however it is the AWS variant: https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php
We use the following extensions: sockets intl zip pdo pdo_mysql pcntl gd exif bcmath mbstring curl sqlsrv pdo_sqlsrv opcache + memcached.
+1
We are also noticed similar issues after upgrading from php:8.4.6-fpm to the php:8.4.7-fpm tag in Docker. Jobs got killed due to using 100% CPU, when they were fine before without any issues.
In a QA environment we experienced the issue again on php:8.4.7-fpm inside an AWS ECS Fargate container. I managed to gather some intersting metrics @devnexen
Running uptime tells me the container has been running for just over 7 and a half hours - keep this in mind for later.
Here is the command output:
12:44:55 up 7:38, 0 user, load average: 2.07, 2.12, 2.09
In order to give some background about what is running inside the container, I can share it is running the scheduling part of a Laravel-based application. The container is periodically spawing a PHP process with php artisan schedule:run. This process will then for every scheduled action spawn a new background process: /usr/local/bin/php artisan <command name parameter>.
There is thus no HTTP-traffic to the container.
Running htop shows only two of these background PHP processes running for almost 6 and 7 hours. Everything else appears to have ran as expected.
I sampled a few of the processes running on the machine.
8796 is the scheduled invocation php artisan schedule:run
3920 and 5109 are processes spawned by a previously running instance of php artisan schedule:run
For 3920 and 5109 I notice nonvoluntary_ctxt_switches is very high.
Attempts to strace -f -p <pid> the hung PHP processes produce no output, maybe indicating the process is stuck in a blocking syscall? I think this supports the theory that JIT is the culprit, as opcache.enable_cli is true in this application.
Sadly inspecting kernel operations are unsupported or restricted in ECS Fargate. However the process never recovers, and no userland activity occurs..
Hi. We might need more context ; e.g. pool configuration, what kind of web application could it be, was cpu usage significantly lower with previous php releases .. etc ...
Same CPU/load spikes happens to us on latest Nextcloud instance with latest PHP 8.4+ (.19) We did not have problems before with PHP <= 8.3 and do not have problems with other Nextcloud instances with PHP <= 8.3. CPU/load spikes comes randomly, 2 weeks no problems, than few times a day, but always after server restart. PHP-FPM restart helps, sometimes only with explicit stop and start.
Now I set pm.max_requests = 1 in PHP-FPM pool and Nextcloud instance is more perfomant, load rearly exceeding 1. If it holds for a month, it is some kind of memory leak for sure.
Activity
devnexen commentedon Feb 14, 2025
Hi. We might need more context ; e.g. pool configuration, what kind of web application could it be, was cpu usage significantly lower with previous php releases .. etc ...
jostreff commentedon Feb 14, 2025
php.ini:
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=128
opcache.max_accelerated_files=20000
opcache.save_comments=1
opcache.jit=1235
opcache.revalidate_freq=0
opcache.validate_timestamps=1
opcache.max_accelerated_files=10000
opcache.memory_consumption=192
opcache.max_wasted_percentage=10
opcache.interned_strings_buffer=16
opcache.fast_shutdown=1
opcache.jit_buffer_size=500000000
and php-fpm pool:
pm.status_path = /fpm-status
slowlog = log/$pool.log.slow
security.limit_extensions = .php .php3 .php4 .php5 .php7 .php8
php_admin_value[upload_max_filesize] = 5M
php_admin_value[error_reporting] = E_ALL & ~E_NOTICE & ~E_WARNING & ~E_STRICT & ~E_DEPRECATED
php_admin_value[mysqli.allow_local_infile] = 1
pm = dynamic
pm.max_children = 16
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 1000
pm.process_idle_timeout = 60s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = yes
devnexen commentedon Feb 14, 2025
Thanks.
The reason I ask, often this kind of report comes from major migrations e.g. from 8.2 to 8.4 when behavior differences could be witnessed.
jostreff commentedon Feb 14, 2025
i'm experiencing issues since 8.3 that was the reason to try 8.4 and it performs like that since that moment. Only way to lower cpu usage is just restart service via
service php_fpm restart.8 remaining items
devnexen commentedon Feb 15, 2025
Would it be possible to profile your web app ? e.g. pmcstat is able to do it on a cpu cycles level
pcmstat -O php-sample.dat -P cycles -T -p <php process ID>might give further clues.bukka commentedon Feb 24, 2025
I would guess it won't be related to FPM but the actual execution. Profiling might help with that.
Try to also comment out pm.max_requests = 200 or set it very high which can lead to too many unnecessary restarts ...
github-actions commentedon Mar 11, 2025
No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.
grisha2217 commentedon Mar 13, 2025
Same problem on production server
I compared 2 configs
/usr/bin/php8.3 -i > php83.txt
/usr/bin/php8.4 -i > php84.txt
diff php83.txt php84.txt | less
OUTPUT:
Version & Build Information
PHP Version:
8.3: 8.3.17
8.4: 8.4.4
Build Date:
8.3: Mar 10 2025 15:24:50
8.4: Mar 9 2025 17:05:03
Configuration Files & Directories
php.ini Location:
PHP 8.3 uses: /etc/php/8.3/cli/php.ini
PHP 8.4 uses: /etc/php/8.4/cli/php.ini
Additional .ini Files Parsed:
Almost the same list except PHP 8.4 includes a new file (25-memcached.ini) that isn’t in PHP 8.3.
Extension Directory:
8.3: /usr/lib/php/20230831
8.4: /usr/lib/php/20240924
Core API & Engine Changes
PHP API / Extension Build:
Updated from API20230831 to API20240924.
Zend Engine:
8.3: Zend Engine v4.3.17 with OPcache v8.3.17
8.4: Zend Engine v4.4.4 with OPcache v8.4.4
Output Formatting Changes
Syntax Highlighting:
In PHP 8.3, highlight colors are output using tags.
In PHP 8.4, these are output using tags.
Specific Directive & Extension Differences
FFI Setting:
ffi.enable changed from preload in 8.3 to On in 8.4.
libmagic:
Version changed slightly from 543 to 545.
IMAP Extension:
PHP 8.4 now shows an “IMAP extension Version => 1.0.3” entry.
Memcached Extension:
PHP 8.4 includes a detailed block showing memcached settings and support (e.g. serializer, compression settings).
MySQL Native Driver (mysqlnd):
Updated from version 8.3.17 to 8.4.4 in several places.
PostgreSQL Settings:
pgsql.auto_reset_persistent changed from On to Off.
Session Settings:
session.sid_bits_per_character changes from 5 to 4.
session.sid_length changes from 26 to 32.
OPcache JIT Buffer:
opcache.jit_buffer_size has been reduced from 128M to 64M.
Miscellaneous
Zip Version:
Updated from 1.22.3 to 1.22.4.
CLI Binary Reference:
The underscore variable ($SERVER['']) now reflects the PHP 8.4 binary (/usr/bin/php8.4) instead of PHP 8.3.
Timing Values:
Slight differences in REQUEST_TIME_FLOAT and REQUEST_TIME reflecting the moment the CLI started.
devnexen commentedon Mar 13, 2025
Hi @grisha2217, not entirely sure it is "kind of the same" here.
Is disabling memcached, for example, for a while and restesting a possibility ?
Nations112 commentedon Mar 30, 2025
Same problem after update from 8.3...
I have a PHP pool for each project. With this problem, all pools are using the processor. Restarting PHP helps.
boserup commentedon May 28, 2025
We are also noticing similar issues after upgrading to the php:8.4.7-fpm tag in Docker - we moved from php:8.3.17-fpm before. So I don't think this is isolated to FreeBSD. As with OP, we also have Memcached enabled, however it is the AWS variant: https://github.com/awslabs/aws-elasticache-cluster-client-memcached-for-php
We use the following extensions:
sockets intl zip pdo pdo_mysql pcntl gd exif bcmath mbstring curl sqlsrv pdo_sqlsrv opcache+memcached.We also saw an increase in memory usage.
nbb-content commentedon Jun 2, 2025
+1
We are also noticed similar issues after upgrading from php:8.4.6-fpm to the php:8.4.7-fpm tag in Docker. Jobs got killed due to using 100% CPU, when they were fine before without any issues.
boserup commentedon Jun 6, 2025
In a QA environment we experienced the issue again on php:8.4.7-fpm inside an AWS ECS Fargate container. I managed to gather some intersting metrics @devnexen
Running
uptimetells me the container has been running for just over 7 and a half hours - keep this in mind for later.Here is the command output:
In order to give some background about what is running inside the container, I can share it is running the scheduling part of a Laravel-based application. The container is periodically spawing a PHP process with
php artisan schedule:run. This process will then for every scheduled action spawn a new background process:/usr/local/bin/php artisan <command name parameter>.There is thus no HTTP-traffic to the container.
Running
htopshows only two of these background PHP processes running for almost 6 and 7 hours. Everything else appears to have ran as expected.I sampled a few of the processes running on the machine.
php artisan schedule:runphp artisan schedule:runFor 3920 and 5109 I notice
nonvoluntary_ctxt_switchesis very high.Attempts to
strace -f -p <pid>the hung PHP processes produce no output, maybe indicating the process is stuck in a blocking syscall? I think this supports the theory that JIT is the culprit, asopcache.enable_cliis true in this application.Sadly inspecting kernel operations are unsupported or restricted in ECS Fargate. However the process never recovers, and no userland activity occurs..
PID 8796
PID 3920
PID 5109
Configuration and environment
stfast commentedon Apr 3, 2026
Same CPU/load spikes happens to us on latest Nextcloud instance with latest PHP 8.4+ (.19) We did not have problems before with PHP <= 8.3 and do not have problems with other Nextcloud instances with PHP <= 8.3. CPU/load spikes comes randomly, 2 weeks no problems, than few times a day, but always after server restart. PHP-FPM restart helps, sometimes only with explicit stop and start.
Now I set pm.max_requests = 1 in PHP-FPM pool and Nextcloud instance is more perfomant, load rearly exceeding 1. If it holds for a month, it is some kind of memory leak for sure.