Repository navigation
Memory leak PHP FPM 8.1 with class entry instances #8646
Description
Description
Description
A few months ago I tried to migrate to php8.1 but it had a memory leak, so I stayed at 8.0, the memory leak is still present today, while on version 8.0 no problem, the memory remains stable.
Info
Armbian (Ubuntu 20.04.4 LTS)
Linux roc-rk3399-pc 5.15.25-rockchip64
Docker version 20.10.16, build aa7e414
Docker image not working: php8.1-fpm
Docker image working fine: php8.0-fpm
My dockerfile:
FROM php:8.1-fpm
RUN pecl install igbinary
RUN pecl bundle redis && cd redis && phpize && ./configure --enable-redis-igbinary && make && make install
RUN docker-php-ext-enable opcache igbinary redis
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
HEALTHCHECK CMD curl -s 172.17.0.1:8080/ping | grep pongMy php.ini
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,pcntl_unshare,exec,passthru,shell_exec,system,popen,curl_multi_exec,parse_ini_file,show_source,
expose_php = Off
max_execution_time = 60
max_input_time = 60
error_reporting = E_ALL
display_errors = Off
post_max_size = 51M
file_uploads = On
upload_max_filesize = 50M
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
open_basedir = "/code/:/tmp/"
cgi.force_redirect = 1
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1
; The OPcache shared memory storage size.
opcache.memory_consumption=128
; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer=8
; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 1000000 are allowed.
opcache.max_accelerated_files=10000
; The maximum percentage of "wasted" memory until a restart is scheduled.
opcache.max_wasted_percentage=5
; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
opcache.validate_timestamps=1
; Enables or disables file search in include_path optimization
opcache.revalidate_path=1
; If disabled, all PHPDoc comments are dropped from the code to reduce the
; size of the optimized code.
opcache.save_comments=0
; Allow file existence override (file_exists, etc.) performance feature.
opcache.enable_file_override=1
; Check the cache checksum each N requests.
; The default value of "0" means that the checks are disabled.
opcache.consistency_checks=100
#opcache.enable_cli=1
#opcache.jit_buffer_size=100MB
#opcache.jit=1235php8.1-fpm memory usage (purple line):
It had gone up to 800MB in a relatively short time without stopping
php8.0-fpm memory usage (purple line):
I don't know what other information to give you because I don't know how to use profiling tools, and I can't test disabling extensions.
PHP Version
8.1
Operating System
Armbian (Ubuntu 20.04.4 LTS)
Reacted by Takayasu Oyama, Asrorbek Sultanov, sneakyimp and Yassine Bridi
Activity
iluuu1994 commentedon May 27, 2022
Well, most likely there's some code in your application that makes PHP leak memory. Is it possible that you isolate the code causing the problem and then provide a snippet that reproduces the leak?
davtur19 commentedon May 27, 2022
All the code runs on the webserver and doesn't run for more than 60 seconds, could it still be due to my code?
It's a little tricky trying to isolate everything, isn't there a way to do it without going crazy?
Do you have any ideas or guides to link to me?
Could functions like memory_get_usage() help me?
A Telegram bot runs on the webserver, so it's mostly curl requests and some redis.
iluuu1994 commentedon May 27, 2022
@davtur19 Normally any memory that PHP allocates per request gets automatically deallocated after the request ends. It's possible that some code in PHP incorrectly allocates memory (persistently instead of request-bound) which does not automatically get freed and thus the memory keeps creeping up.
Assuming you can't provide the source code, it's probably easiest to add a
die;statement in different places of your application, run a couple hundred times and check if the memory keeps increasing. If not, move thedie;back and check again. There are other ways to check if PHP leaks (valgrind or ASAN) but that's not quite as easy to set up.staabm commentedon May 27, 2022
You might use https://github.com/BitOne/php-meminfo to analyze memory leaks
github-actions commentedon Jun 11, 2022
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.
103 remaining items
sneakyimp commentedon Nov 15, 2023
I think I'm experiencing this memory leak with the very latest PHP 8.2.12 on our production server. We were running PHP 7 in PHP-FPM configuration and memory consumption was stable for years. We migrated our app to another server (with only tiny changes to avoid deprecation warnings about dynamic class properties) and we now see the per-process RAM consumption for our pool of PHP-FPM processes creep up over the course of several days until our server is completely out of memory. Restarting the PHP-FPM pool appears to get all the memory back. Our web app is pretty elaborate so I doubt I can replicate it for anyone, but I do have a bunch of data, including an OOM/Killed dump from the syslog, and some lists of processes were you can see the bloated RAM consumption after about a week versus the lean RAM consumption immediately following a PHP-FPM pool restart.
I was pretty alarmed to see that PHP 8.1 is going to be closed for bug fixes and this memory leak may not be resolved?
ndossche commentedon Nov 15, 2023
I'm going to clarify something: the original reported issue, and some related ones have been long fixed.
In fact, the original issue wasn't even fpm-specific!
But this issue report has become a general "report your memleak here" issue, which is kinda ok but confusing for people.
Without a reproducer or dump it is not clear if the leak is even in fpm, or in an extension. It could even be a leak in a third party extension.
@sneakyimp whatever issue you're having is different from OP's. A dump is better than nothing but since it comes from a production system it has no debug symbols so it will be hard to figure out what exactly happened.
And indeed, 8.1 is closed for bugfixes.
If anyone wants to share a dump, please do so privately via mail. Reminder: never share the dump in public here because a dump usually contains sensitive data like passwords/credentials/private keys.
Please also include the output of phpinfo() when sending a dump.
sneakyimp commentedon Nov 16, 2023
@nielsdos Thanks for your response.
I'm happy to provide any detail I have. Thanks for the warning about the dump possibly containing sensitive info. I was aware of this. That said, I don't think the dump i'm talking about is the same thing as the dump you are referring to. I'm no expert but the information doesn't look very sensitive. I just copied it from the syslog. It goes something like this:
EDIT: I tried posting the charts here but they are not showing up. I posted them to imgur here.
ndossche commentedon Nov 17, 2023
Right, I indeed thought about a different kind of dump. The one you posted is not sensitive indeed.
From the charts it seems like the memory usages spikes shortly after a memory drop. So could it be that it spikes after an opcache restart?
sneakyimp commentedon Nov 20, 2023
@nielsdos It looks like the adjustment to
pm.max_requestsis working, and memory consumption once again seems stable. Perhaps the default php-fpm config should have a nonzero value for this setting?ndossche commentedon Nov 20, 2023
Interesting workaround. It probably hides the real issue, or somehow some children aren't properly terminated? I don't know.
Anyway, cc @bukka perhaps for ideas
wizardist commentedon Dec 21, 2023
Version 8.2.5 changelog states:
Should this be closed then?
ndossche commentedon Dec 21, 2023
The original bug reported in this issue was fixed. It was reopened because people use this issue as a generic leak issue thread.
Perhaps this should be renamed and closed because this thread became a bit messy.
cc @iluuu1994 wdyt?
iluuu1994 commentedon Dec 21, 2023
Sure! If the original problem is solved we should close this and create new issues for anything distinctly unrelated.
[-]Memory leak PHP FPM 8.1[/-][+]Memory leak PHP FPM 8.1 with class entry instances[/+]Fix phpGH-8646: Memory leak PHP FPM 8.1