Fixing Repeated Application Restarts Caused by Resource Exhaustion
A WordPress website that was being used for production was being downed and brought back up regularly on AWS. Users were getting error status of HTTP 503, especially during periods of heavy traffic on the site. The configuration was quite easy to set up, with one Amazon Linux EC2 instance with Nginx and PHP-FPM, and CloudWatch collecting simple CPU and network metrics.
Bobcares conducted a detailed analysis of the cause of the failures in the logs on the web server and in PHP-FPM logs, and discovered the instance was hitting memory and process limits. A number of PHP-FPM workers were being killed, resulting in Nginx becoming unresponsive. The team optimized PHP-FPM and PHP configuration, increased swap space, decreased unneeded application load, and increased monitoring.
Business Challenge
The customer was dealing with recurring outages on a production WordPress application. Requests could overwhelm the available resources, causing PHP-FPM workers to terminate and Nginx to return 503 errors. The immediate need was to stop the repeated failures and keep the application responsive as activity increased.
Technology Used
Blueprint
The website was served by Nginx, which passed dynamic requests to PHP-FPM on the same EC2 instance. During heavier activity, PHP-FPM consumed more memory and processes were terminated. Bobcares adjusted its worker settings and PHP limits, added swap space, reduced application workload, and strengthened CloudWatch monitoring around the environment.
Key Outcomes
- The recurring application failures stopped.
- No further HTTP 503 errors were observed.
- Page response times improved.
- Resource consumption became more stable.
- Concurrent requests could be handled without the previous failures.
- CloudWatch provided more useful visibility into resource pressure.
Customer Profile
The client was running a WordPress-based production website on AWS. Its web stack consisted of Nginx and PHP-FPM on an Amazon Linux EC2 instance. CloudWatch was already in use, but only basic CPU and network metrics were being monitored. As activity increased, the single-server setup struggled to handle the resulting workload.
The Challenges
- PHP-FPM workers were being terminated under memory and process pressure.
- Resource consumption increased sharply during heavier activity.
- Nginx could not consistently communicate with PHP-FPM.
- Users encountered HTTP 503 responses.
- Page loads became slower when resource usage increased.
- The single EC2 instance had no mechanism to absorb sudden increases in demand.
- Existing monitoring did not provide alerts for the resource conditions behind the failures.
Why Bobcares?
- The investigation started with the actual failure symptoms rather than assuming the EC2 instance itself was unhealthy.
- Nginx and PHP-FPM logs helped narrow the problem down to the application stack.
- The existing server was tuned before broader infrastructure changes were considered.
- The fix addressed both PHP-FPM behavior and the memory pressure behind the process failures.
- Monitoring was strengthened so resource problems could be identified earlier.
What We Delivered
- Checked EC2 instance health, disk usage, and network connectivity.
- Reviewed CloudWatch data for CPU and memory spikes.
- Examined Nginx errors associated with failed backend connections.
- Reviewed PHP-FPM logs for unexpected worker termination.
- Adjusted PHP-FPM worker settings based on available resources.
- Increased PHP memory and execution-time limits.
- Added a temporary swap file to absorb memory spikes.
- Expanded CloudWatch monitoring and configured high-resource alerts.
- Reduced heavy background operations within the application.
- Enabled caching to reduce processing load.
Results
Application Availability
- Before: The website would become unavailable repeatedly, with PHP-FPM failures followed by HTTP 503 responses from Nginx.
- After: The repeated failures stopped, and no further 503 errors were observed.
Resource Handling
- Before: Periods of increased activity pushed memory and process usage high enough to terminate PHP-FPM workers.
- After: Resource usage became more stable, and the application handled concurrent requests without the earlier failures.
Response Performance
- Before: Higher activity was accompanied by increased latency and slow page loads.
- After: Response times improved after the PHP-FPM and application-level changes.
Monitoring
- Before: CloudWatch provided basic CPU and network information, with no alerting mechanism for the resource conditions affecting the application.
- After: More detailed monitoring and alerts provided earlier visibility into high resource usage.
The Business Impact
- Users experienced fewer interruptions while accessing the website.
- The production environment became more predictable during periods of increased activity.
- Recurring application failures required less immediate intervention.
- The customer gained better visibility into resource conditions affecting the application.
- The existing EC2 environment could support concurrent requests more reliably.
Ongoing Collaboration
- Continue monitoring CPU and memory behavior through CloudWatch.
- Review resource usage as application activity changes.
- Reassess server capacity when workload increases.
- Continue tuning application operations that create unnecessary load.
- Review caching effectiveness and application performance over time.
- Evaluate scaling requirements as traffic patterns change.
Conclusion
The recurring failures were traced to PHP-FPM processes being terminated under memory and process pressure. Bobcares stabilized the existing environment by tuning the PHP stack, adding swap capacity, reducing application load, and improving monitoring. The application stopped returning the recurring 503 errors and handled concurrent activity more reliably.
