Upon further debugging, the possible issue is at the following line:<div><br></div><div><div id=":4tf" dir="ltr" class="kl" style="margin-bottom:4px;text-align:left;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">

src/http/ngx_http_upstream_round_robin.c:433</div><div id=":4tg" dir="ltr" class="kl" style="margin-bottom:4px;text-align:left;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">

for ( ;; ) { <br>               rrp->current = ngx_http_upstream_get_peer(rrp->peers);<br><br>               ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0,<br>                              "get rr peer, current: %ui %i",<br>

                              rrp->current,<br>                              rrp->peers->peer[rrp->current].current_weight);<br><br>               n = rrp->current / (8 * sizeof(uintptr_t));<br>               m = (uintptr_t) 1 << rrp->current % (8 * sizeof(uintptr_t));<br>

</div><div><br></div><div><br></div><div><br></div><div>The<span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;text-align:left"> pc->tries is a ridiculously large number, which causes looping. Here is the configuration used to reproduce the error:</span></div>

<div><br></div><div><div>worker_processes 1;</div><div>worker_rlimit_nofile 32768;</div><div>error_log /var/log/nginx/error.log warn;</div><div>events { worker_connections  16384; use epoll; }</div><div><br></div><div>http {</div>

<div>    access_log  off;</div><div><br></div><div>    upstream a {</div><div>            server 10.56.140.8 backup;</div><div>            server 10.56.140.2 backup;</div><div>            server 10.56.140.4 backup;</div>
<div>
            server 10.56.140.6 backup;</div><div>    }</div><div><br></div><div>    upstream b {</div><div>            server 10.56.140.16 max_fails=100 fail_timeout=5s;</div><div>            server 10.56.140.8 backup;</div>

<div>            server 10.56.140.2 backup;</div><div>            server 10.56.140.4 backup;</div><div>            server 10.56.140.6 backup;</div><div>    }</div><div><br></div><div>    server {</div><div>        listen 80;</div>

<div><br></div><div>        location = /j.php {</div><div>            include /etc/nginx/proxy.conf; #with some timeout variables which are not relevant here I think</div><div>            proxy_pass <a href="http://b">http://b</a>;</div>

<div>            error_page 403 404 500 502 503 504 = @fallback;</div><div>        }</div><div><br></div><div>        location @fallback {</div><div>                proxy_pass <a href="http://a">http://a</a>;</div><div>        }</div>

<div>   }</div><div>}</div></div><div><br></div><div><br></div><div><div>Sparsh Gupta<br>
<br><br><div class="gmail_quote">On 30 March 2012 18:23, Sparsh Gupta <span dir="ltr"><<a href="mailto:sparshgupta@gmail.com">sparshgupta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>I compiled a stable release 1.0.14 with no 3rd party modules and under heavy load, gdb is showing <span style="text-align:left;color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">hot looping around when error_page directive is used. The CPU (all 8 cores) reaches 100% usage and the server stops responding to further requests</span></div>


<div style="text-align:left"><font color="#222222" face="arial, sans-serif"><br></font></div><div>I am happy to share my configurations but its a very simple arrangement with varnish server being the backend for proxy_pass. I am using apache-benchmark to test it.</div>


<div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888">Sparsh Gupta<br>
</font></span></blockquote></div><br></div></div></div>