How to prevent running out of connections?
nsheth at gmail.com
Wed May 28 12:53:42 MSD 2008
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...
More information about the nginx