[Bug] - PHP -FPM OOM killed after a few minutes

[MUBARAK-SSR]

Describe the bug
Elastic Beanstalk PHP application crashes due to excessive memory consumption (3.2GB+ per PHP-FPM process) caused by ELB Health Checker repeatedly calling a memory-intensive dashboard page (index.php). The health checker triggers database queries and dashboard rendering every 15 seconds, leading to memory leaks and eventual OOM (Out of Memory) crashes.
I precise only the Health Check because the application crashes even if I don't launch any link, there's only the Health Check that is active.

Steps to reproduce the behavior

Deploy a PHP 8.4 (Amazon Linux 2023) application on AWS Elastic Beanstalk with index.php
Configure default ELB health check (which automatically targets /index.php)
Wait 1-3 minutes for health checker to make repeated requests
Monitor memory usage: top shows PHP-FPM processes consuming 3.2GB+ memory (85%+ of instance memory)
Instance becomes unresponsive and crashes with OOM errors
Expected behavior Health checks should use a lightweight endpoint that doesn't execute business logic, database queries, or memory-intensive operations. The application should remain stable under normal health check intervals.

Environment Information

Platform: AWS Elastic Beanstalk
Instance Type: t4g.medium (3.7GB RAM)
OS: Amazon Linux 2023
PHP Version: 8.4
Web Server: Apache with PHP-FPM
Region: us-west-2
Error Logs:

Memory consumption

21399 webapp 20 0 3862000 3.2g 25804 S 6.6 85.0 0:05.42 php-fpm

Health checker requests

172.31.31.208 - - [22/May/2026:10:46:51 +0000] "GET /index.php HTTP/1.1" 307 - "-" "ELB-HealthChecker/2.0"
172.31.49.235 - - [22/May/2026:10:46:51 +0000] "GET /index.php HTTP/1.1" 307 - "-" "ELB-HealthChecker/2.0"

PHP-FPM configuration attempts

pm.max_children = 4
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3
php_admin_value[memory_limit] = 512M

Root Cause Analysis

Default Health Check Target: ELB automatically uses /index.php for health checks
Memory Leak: Repeated execution of heavy logic causes memory accumulation in PHP-FPM processes
Frequency: Health checks every 15 seconds compound the memory leak
OOM Crash: Eventually consumes all available memory (3.2GB+ on 3.7GB instance)

Additional context

Initially suspected PHP-FPM configuration issues, but root cause was application-level memory leaks triggered by health checker
Problem persists even with optimized PHP-FPM settings (reduced max_children, proper memory limits)
Only one specific PHP-FPM process shows excessive

Issue is reproducible across deployments and instance restarts
Attempted Fix: Implemented dedicated lightweight health check endpoint (/health.php) and configured ELB to use it instead of /index.php, but the problem persists

Current Status: Issue remains unresolved - memory leaks continue to occur even with lightweight health check configuration
Attempted Workarounds:

// health.php - lightweight health check (attempted)

.ebextensions/healthcheck.config (attempted)

option_settings:
aws:elasticbeanstalk:application:
Application Healthcheck URL: /health

Current Investigation:

Memory leaks may be occurring from other sources beyond health checks
Need further investigation into application code and PHP-FPM process behavior
Seeking community input on additional debugging approaches

// health.php - lightweight health check

.ebextensions/healthcheck.config

option_settings:
aws:elasticbeanstalk:application:
Application Healthcheck URL: /health

[bhatiays]

Hi @MUBARAK-SSR, thanks for the report. A few things stand out from what you've shared, and there's some information we'd need before we can confirm whether this is anything in the AL2023 PHP package.

Could you share the exact PHP version?

php --version
rpm -qa | grep -E '^php'
php -m

A 3.2 GB worker with memory_limit = 512M is not a per-request PHP allocator issue. memory_limit is enforced inside the Zend allocator on each request and is reset between requests. A worker reaching 3.2 GB has to be growing from something outside per request PHP memory, almost always a third-party C extension (look closely at any PECL or third-party extensions you've added).

---

Immediate mitigation - set pm.max_requests.

In /etc/php-fpm.d/www.conf, set:

pm.max_requests = 500

This is commented out by default. It causes each FPM worker to recycle after handling N requests, so any per-process leak is bounded. Pick a value low enough that worker RSS stays under a few hundred MB on your t4g.medium. Then sudo systemctl reload php-fpm.

---

About your health check change, please double check it actually applied. The setting you pasted:

option_settings:
    aws:elasticbeanstalk:application:
      Application Healthcheck URL: /health

This controls the Classic Load Balancer health check only. If your environment is using an Application Load Balancer (the EB default for new environments), the LB ignores that namespace and you have to set:

option_settings:
    aws:elasticbeanstalk:environment:process:default:
      HealthCheckPath: /health.php

You can confirm what the health checker is actually requesting by tailing the web-server access log (/var/log/httpd/access_log for the Apache platform, /var/log/nginx/access.log for the nginx platform) and grepping for ELB-HealthChecker. If the path showing up is still /index.php after deploying the .ebextensions change, the config was wrong for that LB type.

---

Quickest way to determine whether this is AL2023's PHP or your application.

Spin up a clean AL2023 instance, install only php-fpm and the absolute minimum set of extensions you need, drop in a trivial index.php:

<?php phpinfo();

Point the same health check at it for an hour. If FPM worker RSS stays flat, the leak is in your application code path or a non-default extension. If it grows, please attach the following from the affected instance:

• php -m
• php -i | head -50
• The FPM pool config: cat /etc/php-fpm.d/www.conf
• Two pmap -x <pid> snapshots of the highest-RSS php-fpm: pool www worker - one when memory is normal and one after it has grown, taken with the same PID

Happy to help further.