Resolved 502 Issue Solved

[pDecrette]

We've been fighting to find the solution to random and frequent 502 Bad Gateway errors on many of our websites on one of our servers. They would generate entries like this in the site's proxy_error_log:

2016/06/17 08:55:46 [error] 23668#0: *24939 upstream prematurely closed connection while reading response header from upstream, client: x.x.x.x, server: domain.tld, request: "GET /script.php.

This occurred on sites with or without Nginx enabled in the Plesk control panel, and with FPM served by Apache, FastCGI served by Apache, but not FPM served by NGINX. This ultimately led us to "upstream" meaning Apache (i.e., an Apache issue).

What fixed it COMPLETELY was us switching Apache's MPM mode from "Event" to "Prefork" (which can be done in the Plesk control panel).

In our research we found TONS of folks with unresolved 502 errors. I thought I'd post this solution if it helps anyone else.

If someone has comments about WHY this worked, please let me know. We run Apache/2.4.6 on CentOS 7.2.1511. This machine in question has dual Xeon 8-core processors with 128 GB of memory.

Cheers!
- Paul

 

[trialotto]

@pDecrette

the explanation WHY your "solution" works, is quite simple.

Apache has some MPMs (Multi-Processing Module), the most important of them being

a) Prefork: non-threaded, pre-forking web server

b) Worker: hybrid multi-threaded multi-process web server

c) Event: a variant of the Worker MPM, consuming threads for connections with active processing


In essence, Prefork MPM is the most stable one and should be preferred in general, even though some (minor) performance penalties can be present.

Whenever performance is an issue, the Worker MPM should be preferred, but that is not available on a Plesk instance.

In fact, Plesk compensates by allowing for PHP-FPM, which is an ability to run PHP as a FastCGI process server and address the FastCGI server directly from within Apache (via modules).

Given the

- close relation between the Worker and Event MPM,
- nature of multi-threaded MPMs,
- lack of processing of inactive connections when using Event MPM,
- presence of PHP-FPM on Plesk,

any error on one site can result in (processing) errors on many (or all) sites, when having activated the Event MPM.

And simply the nature of the Event MPM (only threads for connections with active processing) implies that processing errors are leading to problems, which are multiplicated in the end.

In short, not choosing the Event MPM is one option.

The latter naturally means that we have to choose Prefork MPM, since an alternative MPM is not present in Plesk.

However, another alternative solution is present: debugging code that leads to processing errors.

The latter alternative solution is not always a serious option, since many correlated issues can be the root cause of one processing error.

In conclusion, choosing the Prefork MPM is often a safe choice.

Hope the above helps and explains a bit.

Regards!

 

[pDecrette]

@trialotto

Thank you! Debugging customer code isn't always possible when I am not getting paid for it, so this was a good solution for me. It's interesting how I have two nearly identical servers, and each had a different MPM out of the box, as I didn't even know that option existed.

I really appreciate your explanation.

Best,
- Paul

 

[trialotto]

@pDecrette, Paul,

No problem, glad it helped somewhat. If you have any future questions, you can post them, but you can also send me a PM, if you want to.

Regards....