2 of 16 cores are constantly maxing out - how to balance the load?

Lucas Rolff lucas at lucasrolff.com
Thu Jan 11 10:16:29 UTC 2018


If it’s the same two cores, it might be another process that uses the same two cores and thus happens to max out.
One very likely possibility would be interrupts from e.g. networking. You can check /proc/interrupts to see where interrupts from the network happens.

From: nginx <nginx-bounces at nginx.org> on behalf of Raffael Vogler <raffael.vogler at yieldlove.com>
Reply-To: "nginx at nginx.org" <nginx at nginx.org>
Date: Thursday, 11 January 2018 at 11.14
To: "nginx at nginx.org" <nginx at nginx.org>
Subject: 2 of 16 cores are constantly maxing out - how to balance the load?

Hello!

I have nginx with php-fpm running on a 16 core Ubuntu 16.04 instance. The server is handling more than 10 million requests per hour.

https://imgur.com/a/iRZ7V

As you can see on the htop screenshot cores 6 and 7 are maxed out and that's the case constantly - even after restarting nginx those two cores stay at that level.

I wonder why is that so and how to balance the load more evenly?

Also I'm curious to know whether this might indicate a performance relevant issue or if it is most likely harmless and just looks odd.

> cat /etc/nginx/nginx.conf | grep -v '^\s*#'



user www-data;

worker_processes auto;

pid /run/nginx.pid;

events {

        worker_connections 768;

}

http {

        sendfile on;

        tcp_nopush on;

        tcp_nodelay on;

        keepalive_timeout 65;

        types_hash_max_size 2048;

        include /etc/nginx/mime.types;

        default_type application/octet-stream;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE

        ssl_prefer_server_ciphers on;

        access_log /var/log/nginx/access.log;

        error_log /var/log/nginx/error.log;

        gzip on;

        gzip_disable "msie6";

        include /etc/nginx/conf.d/*.conf;

        include /etc/nginx/sites-enabled/*;

}

Thanks

Raffael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180111/2e70f232/attachment-0001.html>


More information about the nginx mailing list