How to prevent running out of connections?

[Neil Sheth]

Rt Ibmer,

I think you replied to my post on "Surviving Digg" a while back - there were
some useful tips throughout that thread, if you still have it.  I'd be happy
to forward that email thread, if you'd like.

I also set worker_rlimit_nofile to a relatively high value - that seemed to
help things out on the box.

On that note, I'm not sure what a reasonable permanent value for that
variable should be, if anyone has any insight on that?  And how is that
related to worker_connections?


On Mon, May 26, 2008 at 6:48 AM, Rt Ibmer <rtibmx at yahoo.com> wrote:

> [Hello - I sent this last week but did not receive any responses so I am
> resending it in hopes of getting some information. Thank you!]
> ----------------------
>
> How do I make sure we don't run out of available connections for our nginx
> 6 box?
>
> For instance when I run stub_status I see that I have x active connections.
>  I can also see how the keepalive setting in nginx impacts this number.
>
> It seems that under heavy load where connections are coming in at a much
> faster rate than the keepalive timeout is expiring, that things could get to
> a point where the number of active connections becomes too great and then
> there would not be enough connections available for new users.
>
> A few questions please:
>
> 1) Is such a situation that I described above possible?
>
> 2) In such a situation, would nginx automatically free the idle keepalive
> connections so that it could have more connections available for use?
>
> 3) What nginx and/or Linux settings (I am using Fedora core 8 if that
> matters) controls what the maximum number of connections is that my box can
> have active?  How can this be bumped up?
>
> Obviously under some heavy load a box will reach a physical maximum that it
> is capable of serving.  That is ok and why we have other boxes available.
>  However I want to understand how this works so that I can keep an eye on
> the connections and say "Hey that's getting awfully close to our limit -
> time to get another box up!".  Right now I have no idea how to predict what
> that limit is.  Thanks!
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080528/6be24226/attachment.html>