Automatic memory downsizing seems to break requests/job executions

[MightySepp666]

Description

I'm using the Relay extension within a Laravel application and receive lots of errors in our error reporting tool (Sentry) related to the automatic reduction of the memory limit. The errors are caused by a PHP Warning, that by default in Laravel, will throw an error.

The errors don't provide much information (no context or stacktrace) and there's no way to reproduce it, but as I understand it, the exception triggered by the warning will cause the current process to fail.

Example:

PHP Request Shutdown: Reducing allocation from 536870912 to 33554432 bytes. (pid: 8, code: 201, state: unlicensed, reason: 'NO_KEY', response-id: '', last-code: 201, last-reason: 'NO_KEY', last-response-id: '')

Expected Behavior

The downsizing must not break applications and cause requests or long running jobs to fail. Especially the behavior of this extension should be deterministic and reproducible and not cause side-effects like this.

Actual Behavior

If error_reporting is configured to catch warnings (like with default Laravel configuration), the PHP warning will cause an exception to be thrown, which will abort execution.

Possible Fix

Either allow this "feature preview" or "unlimited" mode to be switched off by a setting or remove the PHP warning (as it's an expected/documented behavior).

Steps to Reproduce

This error is very, very hard to reproduce as it's caused by a side-effect that can't be enforced without access to the source code. Therefore, errors like this occur only in production environments with high load.

Additional context

I found out, that the prefix PHP Request Shutdown: is prepended by the PHP interpreter itself (in php_verror() in main.c). It seems to be related somehow to shutdown hooks, but I was unable to get this prefix to be logged.

This warning doesn't seem to respect the relay.loglevel setting.

Disabling error reporting for PHP or reducing the log level is not desirable, as I want to be notified about any misconfigurations or errors. Hiding warnings and errors is generally a bad idea.

Relay diagnostics

Relay Support => enabled
Relay Version => 0.10.1
Available cache => 536816448
Available serializers => php, json, igbinary, msgpack
Available compression => lzf, zstd, lz4
Binary UUID => 7d81d895-8989-4321-98f2-4cccb3b91517
Git SHA => 63d48fcfec8fab27dd132598bd2234e1da47e840
Allocator => relay-mmap
Build OS => Ubuntu 16.04.7 LTS
Architecture => x86_64
OpenSSL version => OpenSSL 1.1.1p  21 Jun 2022
License state => unknown
License memory cap => 0
License request id =>
relay.enabled => true
relay.environment => development
relay.key =>
relay.maxmemory => 536870912
relay.maxmemory_pct => 99
relay.eviction_policy => lru
relay.eviction_sample_keys => 128
relay.initial_readers => 128
relay.invalidation_poll_usec => 5
relay.default_pconnect => 1
relay.max_endpoint_dbs => 1
relay.cap_endpoint_dbs => Off
relay.locks.allocator => adaptive-mutex
relay.locks.cache => adaptive-mutex
relay.loglevel => error
relay.logfile => stderr
relay.session.compression => none
relay.session.compression_level => 0
relay.session.locking_enabled => 0
relay.session.lock_expire => 0
relay.session.lock_wait_time => 0

Environment

We run Relay in many different environments (with PHP-FPM for web requests, in CLI variant for executing jobs and with Bref in AWS Lambda). However, this error shouldn't be related to a specific environment, this is the environment of the PHP-FPM version:

• OS and version: AWS ECS Fargate Linux 1.4.0
• PHP version: 8.3.10
• Redis version: Valkey 8.0.2 (acting as Redis 7.2.4)

[tillkruss]

Relay will reduce its allocation to 33554432 or 16777216 depending on the version after about an hour. If you're running Relay longer with a license and don't want to see a warning, I'd suggest leaving relay.maxmemory to the default.