Move tunning parameters to the FAQ.

This commit is contained in:
Paul J. Davis 2010-05-30 15:05:29 -04:00
parent d8e6cb1769
commit d26afdacc1
5 changed files with 79 additions and 74 deletions

View File

@ -104,14 +104,17 @@ the servers. For the curious, <a class="reference external" href="http://ha.cker
</div>
<div class="section" id="how-many-workers">
<h2><a class="toc-backref" href="#contents">How Many Workers?</a></h2>
<p>DO NOT scale the number of workers to the number of clients you expect to have.
Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
of requests per second.</p>
<p>Gunicorn relies on the operating system to provide all of the load balancing
when handling requests. Generally we recommend <tt class="docutils literal">(2 x $num_cores) + 1</tt> as the
number of workers to start off with. While not overly scientific, the formula
is based on the assumption that for a given core, one worker will be reading
or writing from the socket while the other worker is processing a request.</p>
<p>Obviously, your particular hardware and application are going to affect what
the optimal number of workers is. Our recommendation is to start with the above
guess and tune using TTIN and TTOU signals while the application is under load.</p>
<p>Obviously, your particular hardware and application are going to affect the
optimal number of workers. Our recommendation is to start with the above guess
and tune using TTIN and TTOU signals while the application is under load.</p>
<p>Always remember, there is such a thing as too many workers. After a point your
worker processes will start thrashing system resources decreasing the throughput
of the entire system.</p>

View File

@ -47,6 +47,11 @@
<li><a class="reference internal" href="#how-can-i-change-the-number-of-workers-dynamically" id="id11">How can I change the number of workers dynamically?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#kernel-parameters" id="id12">Kernel Parameters</a><ul>
<li><a class="reference internal" href="#how-can-i-increase-the-maximum-number-of-file-descriptors" id="id13">How can I increase the maximum number of file descriptors?</a></li>
<li><a class="reference internal" href="#how-can-i-increase-the-maximum-socket-backlog" id="id14">How can I increase the maximum socket backlog?</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="wsgi-bits">
@ -108,6 +113,34 @@ $ kill -TTOU $masterpid
</blockquote>
</div>
</div>
<div class="section" id="kernel-parameters">
<h2><a class="toc-backref" href="#questions">Kernel Parameters</a></h2>
<p>When dealing with large numbers of concurrent connections there are a handful of
kernel parameters that you might need to adjust. Generally these should only
affect sites with a very large concurrent load. These parameters are not
specific to Gunicorn, they would apply to any sort of network server you may be
running.</p>
<p>These commands are for Linux. Your particular OS may have slightly different
parameters.</p>
<div class="section" id="how-can-i-increase-the-maximum-number-of-file-descriptors">
<h3><a class="toc-backref" href="#questions">How can I increase the maximum number of file descriptors?</a></h3>
<p>One of the first settings that usually needs to be bumped is the maximum number
of open file descriptors for a given process. For the confused out there,
remember that Unices treat sockets as files.</p>
<pre class="literal-block">
$ sudo ulimit -n 2048
</pre>
</div>
<div class="section" id="how-can-i-increase-the-maximum-socket-backlog">
<h3><a class="toc-backref" href="#questions">How can I increase the maximum socket backlog?</a></h3>
<p>Listening sockets have an associated queue of incoming connections that are
waiting to be accepted. If you happen to have a stampede of clients that fill up
this queue new connections will eventually start getting dropped.</p>
<pre class="literal-block">
$ sudo sysctl -w net.core.somaxconn=&quot;2048&quot;
</pre>
</div>
</div>
</div>
</div>

View File

@ -74,15 +74,19 @@ Some examples of behavior requiring asynchronous workers:
How Many Workers?
=================
DO NOT scale the number of workers to the number of clients you expect to have.
Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
of requests per second.
Gunicorn relies on the operating system to provide all of the load balancing
when handling requests. Generally we recommend ``(2 x $num_cores) + 1`` as the
number of workers to start off with. While not overly scientific, the formula
is based on the assumption that for a given core, one worker will be reading
or writing from the socket while the other worker is processing a request.
Obviously, your particular hardware and application are going to affect what
the optimal number of workers is. Our recommendation is to start with the above
guess and tune using TTIN and TTOU signals while the application is under load.
Obviously, your particular hardware and application are going to affect the
optimal number of workers. Our recommendation is to start with the above guess
and tune using TTIN and TTOU signals while the application is under load.
Always remember, there is such a thing as too many workers. After a point your
worker processes will start thrashing system resources decreasing the throughput

View File

@ -78,3 +78,36 @@ How can I change the number of workers dynamically?
.. _worker_class: /configure.html#worker-class
.. _`number of workers`: /design.html#how-many-workers
Kernel Parameters
=================
When dealing with large numbers of concurrent connections there are a handful of
kernel parameters that you might need to adjust. Generally these should only
affect sites with a very large concurrent load. These parameters are not
specific to Gunicorn, they would apply to any sort of network server you may be
running.
These commands are for Linux. Your particular OS may have slightly different
parameters.
How can I increase the maximum number of file descriptors?
----------------------------------------------------------
One of the first settings that usually needs to be bumped is the maximum number
of open file descriptors for a given process. For the confused out there,
remember that Unices treat sockets as files.
::
$ sudo ulimit -n 2048
How can I increase the maximum socket backlog?
----------------------------------------------
Listening sockets have an associated queue of incoming connections that are
waiting to be accepted. If you happen to have a stampede of clients that fill up
this queue new connections will eventually start getting dropped.
::
$ sudo sysctl -w net.core.somaxconn="2048"

View File

@ -1,68 +0,0 @@
template: doc.html
title: Tuning
Tuning
======
Unicorn Configuration
---------------------
DO NOT scale the number of workers to the number of clients you expect to have.
Gunicorn should only need 4-12 worker processes to handle hundreds or thousands
of simultaneous clients. Remember, Gunicorn is **NOT** designed for serving slow
clients, that's the job of Nginx_.
See Configuration_ for a more thorough description of the available parameters.
.. _Nginx: http://www.nginx.org
.. _Configuration: configuration.html
Kernel Parameters
-----------------
When dealing with large numbers of concurrent connections there are a handful of
kernel parameters that you might need to adjust. Generally these should only
affect sites with a very large concurrent load. These parameters are not
specific to Gunicorn, they would apply to any sort of network server you may be
running.
The commands listed are tested under Mac OS X 10.6. Your flavor of Unix may use
slightly different flags. Always reference the appropriate man pages if
uncertain.
File Descriptor Limits
++++++++++++++++++++++
One of the first settings that usually needs to be bumped is the maximum number
of open file descriptors for a given process. For the confused out there,
remember that Unices treat sockets as files.
::
$ sudo ulimit -n 2048
Listen Queue Size
+++++++++++++++++
Listening sockets have an associated queue of incoming connections that are
waiting to be accepted. If you happen to have a stampede of clients that fill up
this queue new connections will eventually start getting dropped.
::
$ sudo sysctl -w kern.ipc.somaxconn="2048"
Ephemeral Port Range
++++++++++++++++++++
After a socket is closed it enters the TIME_WAIT state. This can become an issue
after a prolonged burst of client activity. Eventually the ephemeral port range
is exhausted which can cause new connections to stall while they wait for a
valid port.
This setting is generally only required on machines that are being used to test
a network server.
::
$ sudo sysctl -w net.inet.ip.portrange.first="8048"