Tuning workers and connections
Momchil Ivanov
slogster at gmail.com
Fri Jul 3 12:58:08 MSD 2009
На Thursday 02 July 2009 03:23:06 Avleen Vig написа:
> Hi folks, I have some questions about tuning nginx for best
> performance, on a site which handle ~1000 requests per second.
>
> In our config, we have:
>
> worker_processes 16;
> worker_rlimit_nofile 32768;
> events {
> worker_connections 8192;
> }
>
> This is on a server with 8 CPU cores and 8Gb RAM.
> My understanding is that this should allow nginx to establish up to
> 32k network connections, because that is the limit of
> worker_rlimit_nofile. We serve very few files off the disk, maybe a
> dozen CSS and JS files. Everything else is handed to backends using
> proxy_pass.
> So with one fd for the browser, and one fd to the upstream, we should
> be able to handle 16k concurrent connections.
>
> However what we're seeing, is that around 5k connections we get a
> performance hit. Connections slow down, take longer to establish, etc.
> The load on the box is almost zero, nginx is clearly working very fast
> and efficiently, but I'm not sure why it slows down.
> Any thoughts?
>
>
> Also, I'm thinking about enabling the multi_accept option, but I
> couldn't find much documentation on how this works.
> It sounds like a high-performance tweak which we should be using if we
> get this many requests per second.
> Could it be that not using multi_accept is the problem?
> Nginx otherwise has to handle the incoming connection requests in
> serial and this is a bottleneck?
The first thing to do would be playing with sysctls, especially increasing
backlog and somaxconn, decreasing tcp_fin_timeout. If this doesn't help a lot
you may consider using keepalive connections (only if you are hitting some
issue with handling lots of accepts).
If you move to keepalive connections, you should make sure that you befefit at
all, therefore monitor requests/handled accepts.
Momchil
--
PGP KeyID: 0x3118168B
Keyserver: pgp.mit.edu
Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://nginx.org/pipermail/nginx/attachments/20090703/0c2f5ac6/attachment.pgp>
More information about the nginx
mailing list