Memory leak PHP FPM 8.1 with class entry instances

[davtur19]

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 pong

My 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=1235

php8.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)

[iluuu1994]

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]

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]

@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 the die; 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]

You might use https://github.com/BitOne/php-meminfo to analyze memory leaks

[github-actions]

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.