Restarting PHP-FPM every hour on a Red Hat system with Apache (httpd) can have both benefits and risks, depending on your server’s traffic and configuration. Here’s what you should consider:
✅ Potential Benefits
- Memory Leak Mitigation: If your PHP code or extensions have memory leaks, hourly restarts can free up RAM by killing and respawning child processes.
- Log Rotation Compatibility: Some setups restart PHP-FPM to ensure new log files are properly written after rotation.
- Configuration Reloads: Useful if you frequently update PHP settings or deploy code that requires fresh worker processes.
⚠️ Potential Risks
1. Temporary Service Disruption
- During restart, all PHP-FPM child processes are killed and respawned.
- If Apache (
httpd) receives a request during this window, it may return a 502 Bad Gateway or 503 Service Unavailable error. - This typically lasts a few seconds but can be noticeable under load.
2. Increased CPU and I/O Usage
- Restarting PHP-FPM frequently causes overhead from process teardown and startup.
- Could impact performance on busy servers.
3. Loss of In-Memory Caches
- Any in-memory data (e.g., session data stored in memory, opcode cache) is lost during restart.
- This can slow down performance until caches warm up again.
🛠️ Best Practices
|
Strategy
|
Recommendation
|
|---|---|
|
Use
systemctl reload php-fpm |
Reloads config without killing active processes
|
|
Schedule restarts during low traffic
|
Use
cron to restart during off-peak hours |
|
Monitor for 502/503 errors
|
Use Apache logs or tools like Netdata/Grafana
|
|
Consider
pm.max_requests |
Automatically recycles workers without full restart
|
🧪 Example Cron Job for Safe Restart
0 * * * * /bin/systemctl reload php-fpm
This reloads PHP-FPM hourly without killing active requests—safer than a full restart.
