PHP7.3-FPM异常致站点性能下降、502错误，寻求技术解决方案

Hey there, let’s walk through troubleshooting this persistent php7.3-fpm 502 Bad Gateway issue you’re facing— I’ve tackled similar problems on Ubuntu 18.04 setups before, so here’s a step-by-step approach to get to the bottom of it:

1. Validate the Buffer Overflow Suspicions #

First, let’s confirm if buffer overflow is actually the culprit. Check your php7.3-fpm.log for explicit errors like "buffer overflow", "request buffer too large", or entries indicating processes getting stuck while handling large requests.

Also, cross-reference these config settings:

• In php.ini, verify memory_limit, post_max_size, and upload_max_filesize— if these values are too low, large POST requests or file uploads can cause processing failures that manifest as 502s.
• In www.conf, check request_terminate_timeout— if this is set too high, slow-running requests can hog php-fpm processes indefinitely, leading to a backlog of unhandled requests.

2. Check php-fpm Resource Limits & Process Health #

Before restarting php-fpm when the issue hits, run these commands to diagnose process behavior:

• ps aux | grep php-fpm: See if the number of active processes hits your pm.max_children limit. If so, new requests can’t be handled, resulting in 502s.
• top or htop: Monitor CPU and memory usage of php-fpm processes. Look for signs of memory leaks (e.g., processes consuming increasing memory over time without releasing it) — this is a common cause of slowdowns and unresponsive processes.
• Review your www.conf pm settings: If you’re using dynamic process management, ensure pm.start_servers, pm.min_spare_servers, and pm.max_spare_servers are tuned to match your site’s concurrent traffic. Too few spare servers can lead to request queues during traffic spikes.

3. Fix Nginx & php-fpm Connection Timeouts #

502s often stem from Nginx giving up waiting for php-fpm to respond. Check your Nginx config for these fastcgi timeout values:

• fastcgi_connect_timeout
• fastcgi_send_timeout
• fastcgi_read_timeout

If these are set too low (e.g., 30s or less), slow php-fpm requests will trigger Nginx to drop the connection early. Increase them temporarily (e.g., to 60s) to see if the 502s reduce while you troubleshoot the root cause.

4. Tune php-fpm’s Process Restart Behavior #

Your existing emergency_restart_threshold and emergency_restart_interval only trigger restarts if processes crash unexpectedly. If processes are just hanging (not exiting), these settings won’t help. A quick fix to mitigate memory leaks or stuck processes is to add:

pm.max_requests = 500

to your www.conf. This forces each php-fpm process to restart after handling 500 requests, preventing long-running processes from accumulating issues. Adjust the number based on your traffic (lower values for leakier apps).

5. Enable Slow Request Logging to Find Culprit Requests #

The most effective way to identify why php-fpm is slowing down is to log slow requests. In www.conf, set:

request_slowlog_timeout = 5s
slowlog = /var/log/php7.3-fpm.slow.log

This will log any request that takes longer than 5 seconds to process. Check this log after the issue occurs— you’ll likely find slow database queries, stuck external API calls, or inefficient PHP code that’s tying up processes. These are almost always the real root cause, not just buffer overflow.

6. Check for System-Level Issues #

Don’t overlook system-wide problems:

• Review syslog for signs of the OOM Killer (Out-of-Memory) terminating php-fpm processes, or high disk IO that’s slowing down file/DB operations.
• Ensure your server has enough swap space— low memory can cause php-fpm processes to stall.

Temporary Automation (While You Fix Root Cause) #

Instead of manually restarting php-fpm, you can create a simple bash script to monitor for 502s and auto-restart the service. For example:

#!/bin/bash
if curl -s -o /dev/null -w "%{http_code}" http://your-site-url | grep -q 502; then
    /etc/init.d/php7.3-fpm restart
fi

Schedule this with cron to run every 5 minutes, but remember this is a band-aid— focus on fixing the root cause first.

内容的提问来源于stack exchange，提问作者Aleksandr Korsukov