• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue nginx stops + open socket # left in connection #

Chrisa

Basic Pleskian
nginx stops and starts. seeing this error in /var/log/nginx/error.log:
2017/02/22 04:00:44 [alert] 13939#0: *150 open socket #41 left in connection 13
2017/02/22 04:00:44 [alert] 13939#0: *149 open socket #3 left in connection 14

Plesk Onyx v17.0.17
Ubuntu 16.04.2 LTS
 
Hello Janko1000,

Did you use Nginx direct from Plesk? Yes. Standard Plesk install
Apache MPM mode = prefork

nginx settings:
proxy mode (checked)
smart static files procession (unchecked), this option reduces performance
Serve static files directly by nginx (unchecked), this option reduces performance

PHP settings:
PHP 5.6.30
PHP as (FPM application served by nginx on some sites and FPM application served by Apache on others). I can change this to FPM application served by nginx, FPM application served by Apache or FastCGI application served by Apache and see no difference and see no difference in performance.
 
The error messages are not the cause for an Nginx reload, but a symptom. In some Nginx docs I read that SPDY module is causing the "open socket left in connection" error. SPDY is not needed if you have activated HTTP/2. Maybe you had previously added SPDY?

In the latest Nginx version without third party modules added the warnings should not appear. Refer to https://www.nginx.com/resources/wiki/start/topics/tutorials/debugging/#socket-leaks for more details.
 
Hello Peter,

Maybe you had previously added SPDY? By SPDY I am assuming you are referring to https://en.wikipedia.org/wiki/SPDY. A definite no. No special addons, just the standard plesk install.

I had previously seen the nginx link you are referring to. It doesn't provide me with a level of detail that I am able to act on which is why I opened a thread here.

Question. Is it possible to remove nginx? Maybe even just for testing. I know that nginx is 'marketed' as a making apache better but so far I don't see it. In fact when I start to use the 'smart' nginx options performance drops.

imho adding extra software to a configuration can sometimes just mean more to break. In a case where the extra software does not provide a demonstratable benefit, maybe the simplest solution is to just remove it.

When I see errors that I am not able to track down to a fault or configuration issue, I'm not left with the warmest feeling of confidence. In the back of my mind I am thinking, "OK what am I missing here?"

Thanks. Further suggestions would be appreciated.
 
You can deactivate nginx by this command:
# /usr/local/psa/admin/sbin/nginxmng -d
You can use the same command with parameter -e to enable Nginx again. Either command can take a while to execute, because all web server configuraton files need to be reconfigured.
 
Hello Peter,
"In the latest Nginx version without third party modules added the warnings should not appear." - So this warning should be considered abnormal?

Re: deactivating nginx. Thanks for the info.
Can you tell me what nginx 'brings to the table' for plesk? As I indicated earlier, it seems to drop performance when 'smart' options are enabled.
Will deactivating nginx cause other problems?

Thanks
 
I have no idea why your Nginx is slower than an Apache-only configuration. Nginx is the much better, faster system. It can handle more processes with less resources in less time. Nginx-only hosting is proven to be enormously faster than Apache hosting for the same websites, and the combination of both, Nginx and Apache, is great because Nginx is caching files and also deliverying static files directly, circumventing unnecessary Apache overhead.

To my knowledge deactivating Nginx will not cause any problems. It will still be the web server for Plesk GUI, but it will not server subscription or add-on domains.
 
Hello Peter,
Thanks for the feedback. From my experience enabling the nginx options in plesk significantly reduces performance as measured by https://developers.google.com/speed/pagespeed/insights/.
I'm fairly new to plesk (2+ years, versions 12.08, 12.5.30, 17.07) and have seen this performance drop consistently across the last 2 versions (do not recall if this was an issue with 12.0.8).

To put some hard numbers on this I just did some tests on live sites:
Wordpress (w/2017 theme) dropped from 89%/95% to 71%/74%. That's an 18% and 21% performance drop! (standard wordpress .htaccess file)
Joomla! (custom theme) dropped from 75%/91% to 59%/72% (16% & 19% performance drop) (custom .htaccess file)
Using the standard joomla! .htaccess file the numbers are 71%/87% and drop to 57%70% with nginx smart option. (14% &17% performance drop)

This is with "Smart static files processing" enabled. "Serve static files directly by nginx" did not seem to make any significant difference in any testing.

This is easy to reproduce 100% of the time:
1. Install plesk 17
2. Install latest version of wordpress
3. PageSpeed Test (site is slower)
4. Plesk | Domain to test | Apache & nginx Settings | Uncheck "Smart static files processing", Uncheck "Serve static files directly by nginx" | Apply
5. Retest in PageSpeed (performance improves significantly).

With this test, we can rule out wordpress or joomla! extensions/plugins, .htaccess files, 3rd party plesk addons, etc.

When I first discovered this I thought I was dealing with a simple configuration issue. I changed the PHP handlers, PHP versions, with and without .htaccess files and the only common element was the nginx "Smart static files processing" option.
 
Back
Top