fbpx

NGINX / Server Setup

Maximizing NGINX Performance: A Comprehensive Guide to Tuning the Backlog and net.core.somaxconn Parameters

by ,


We have by far the largest RPM repository with NGINX module packages and VMODs for Varnish. If you want to install NGINX, Varnish, and lots of useful performance/security software with smooth yum upgrades for production use, this is the repository for you.
Active subscription is required.

The net.core.somaxconn Linux kernel parameter

The net.core.somaxconn kernel parameter is used to set the maximum number of connections that can be queued for a socket. This parameter is used to prevent a flood of connection requests from overwhelming the system.

In other words, this parameter determines the maximum length of the queue of pending connections that are waiting to be accepted by the system. And it’s used to prevent the system from being overwhelmed with too many connections that it cannot handle.

The maximum value for the net.core.somaxconn parameter depends on the system and kernel version. On most systems, the maximum value is around 65535. However, it is not recommended to set the value to the maximum, as this can cause performance issues. Instead, it is best to set the value to a reasonable value based on the needs of your system and the workload that it is expected to handle.

The default value for the net.core.somaxconn Linux kernel parameter is typically 128.

The backlog NGINX parameter

In the context of NGINX, net.core.somaxconn kernel parameter has the relevant counterpart. That is the backlog parameter of the listen directive. The backlog parameter determines the maximum number of connections that can be queued for a listening socket. If the number of connections exceeds the backlog, NGINX will start rejecting incoming connections.

The default value of this parameter, when unspecified, is 511 on the majority of Linux-based systems.

Here’s an example of how the backlog parameter of the listen directive can be used in the NGINX configuration file:

server {
  listen 80 backlog=1024;
  server_name example.com;
  root /var/www/example.com;
  index index.html;
}

In this example, the backlog parameter is set to 1024, which means that NGINX will allow up to 1024 pending connections to be queued up in the kernel before they are accepted by the server.

The maximum value for the backlog parameter is usually around 65535, but this can vary depending on the specific operating system and kernel version.

Connecting the dots

It is important to set the net.core.somaxconn parameter to a value that is larger than the backlog value of NGINX, as the backlog value is used to determine the maximum number of connections that can be queued for a listening socket of NGINX only. If the net.core.somaxconn value is smaller than the backlog value, NGINX will not be able to queue all the incoming connections, resulting in connection errors.

As we can see from the mentioned defaults, it is quite possible that in a default setup for NGINX to have connection errors, in a high-traffic scenario.

The net.core.somaxconn parameter can be set to any value between 128 and 65535. As we’ve mentioned, it is generally recommended to set it to a value that is equal to or slightly larger than the backlog value of NGINX. For example, if the backlog value of NGINX is set to 2048, it is recommended to set the net.core.somaxconn parameter to a value of 2048 or 4096.

Furthermore, it is recommended to set the net.core.somaxconn parameter to a value that is appropriate for the expected number of incoming connections. If the number of incoming connections is expected to be high, a larger value should be set. On the other hand, if the number of incoming connections is expected to be low, a smaller value can be set.

Your typical website

For a website with 10 thousand daily visitors, a reasonable value for net.core.somaxconn could be somewhere in the range of 2048 to 4096. This should provide sufficient capacity for handling incoming connections, while also allowing for some headroom for handling unexpected spikes in traffic.

However, it is important to keep in mind that the optimal value for net.core.somaxconn will depend on various factors, such as the hardware and system resources available on the server, the expected workload and traffic patterns, and the specific needs and goals of the website. Therefore, it is always a good idea to monitor and fine-tune this parameter based on actual performance data, rather than relying on fixed or generic recommendations.

Getting the best values

To determine the best value for the kernel parameter net.core.somaxconn, you can use the following steps.

1. Monitor your server’s connection queue length over time

Using a tool like vmstat, you can get an idea of how many connections are waiting to be processed at any given time.

To get the server connection queue length using vmstat, you can use the following steps:

  • Open a terminal and run the command vmstat. This will show you various statistics about the server, including the connection queue length.
  • The connection queue length is displayed in the “wa” column, which stands for “wait”. This value represents the number of processes that are waiting for a resource, such as a connection. This is what you can use for further calculations.

Note that if the value in the “wa” column is high, it could indicate that the server is experiencing a high load and may be unable to handle additional connections efficiently. In this case, increasing its capacity to handle the load by e.g. upgrading the hardware/network capacity for your website is recommended.

You can also use the vmstat -n 1 command to continuously display the server’s statistics, updating every second. This can help you monitor the connection queue length in real-time and identify any potential issues.

2. Doing the math

Based on the average queue length and the number of CPU cores you have available, you can calculate the optimal value for net.core.somaxconn. Here is the formula you can use:

optimal value = CPU cores * queue length / 4

For example, if your average queue length is 1000 and you have 2 CPU cores, the optimal value for net.core.somaxconn would be 1000 * 4 / 2 = 2000.

Keep in mind that this is just a rough estimate, and you may need to adjust the value based on your specific workload and hardware.

Apply settings

After calculating the best values, you should set the net.core.somaxconn kernel parameter.

To set the net.core.somaxconn kernel parameter, you can create a parameter file, e.g. /etc/sysctl.d/custom.conf and place your value there:

net.core.somaxconn = 2000

Then, run the command sudo sysctl --system to apply the changes.

After we’re done with the kernel setting, we can adjust NGINX backlog parameter to match up:

server {
  listen 80 backlog=2000;
  server_name example.com;
  root /var/www/example.com;
  index index.html;
}

Remember to restart NGINX after changing this parameter to apply the changes.

It’s also important to monitor your server’s performance after changing this parameter to ensure that it’s set to an optimal value.

In conclusion, the net.core.somaxconn kernel parameter is an important factor in tuning the performance of NGINX. It is important to set this parameter to a value that is equal to or larger than the backlog value of NGINX and to choose a value that is appropriate for the expected number of incoming connections. By setting this parameter correctly, it is possible to optimize the performance of NGINX and ensure that it is able to handle incoming connections effectively.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.