<span style>Mystery solved. I will just proxy_max_temp_file_size 0, as the intention was to just avoid the disk.</span><div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Thank you!<br>
</font><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 4:23 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello!<br>
<div class="im"><br>
On Tue, Feb 07, 2012 at 03:54:08PM -0800, W. Andrew Loe III wrote:<br>
<br>
> We use nginx as both a load-balancer and webserver. This issue is with the<br>
> nginx functioning as a load-balancer.<br>
><br>
> We reverse proxy to 6 nginx webservers running a number of Unicorn (Rails)<br>
> application servers, these webserver nginx instances also run Evan Miller's<br>
> mod_zip to assemble archives on the fly. We have discovered under certain<br>
> circumstances the load-balancing nginx will "hang-up" on the webserver if<br>
> the load-balancer is configured with proxy_buffering off, however<br>
> proxy_buffering on seems to succeed. We would prefer to run without<br>
> proxy_buffering to prevent the load-balancer's local storage from being<br>
> overrun.<br>
<br>
</div>If you want to disable disk buffering you don't need to disable<br>
buffering at all.  Use<br>
<br>
    proxy_max_temp_file_size 0;<br>
<br>
instead.<br>
<br>
The only valid reason to disable buffering completely with<br>
"proxy_buffering off" is when you need even single byte from<br>
backend to be immediately passed to client, i.e. as in some<br>
streaming / long polling cases.<br>
<div class="im"><br>
> Our default setup uses nginx 0.7.65 for both the load-balancer and the<br>
> webserver, however switching to using 1.0.12 as the load-balancer has the<br>
> same problem. We have experimented with different software doing the<br>
> load-balancing and it does not exhibit this issue.<br>
><br>
> I've have linked the nginx configuration file we're using on the load<br>
> balancer, and debug logs for both 0.7.65 and 1.0.12.<br>
><br>
> <a href="https://x.onehub.com/transfers/sg32zsar" target="_blank">https://x.onehub.com/transfers/sg32zsar</a><br>
><br>
> The buffering on log is very long, but it does show success of a 4.8GB<br>
> response, the other responses always fail at the same point (826 MB).<br>
><br>
> The client sees the following (in access.log):<br>
><br>
> $ curl -b cookie.txt -o US.zip <a href="https://mydomain.com/folders/7816672/archive" target="_blank">https://mydomain.com/folders/7816672/archive</a><br>
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time<br>
>  Current<br>
>                                  Dload  Upload   Total   Spent    Left<br>
>  Speed<br>
>  16 4922M   16  826M    0     0  1906k      0  0:44:03  0:07:23  0:36:40<br>
> 1075k<br>
> curl: (18) transfer closed with 4294967296 bytes remaining to read<br>
<br>
</div>The response is over 4G, and this won't work with "proxy_buffering<br>
off" in 1.0.x on 32bit systems.  The non-buffered mode was<br>
originally designed for small memcached responses and used to use<br>
size_t for length storage.<br>
<br>
You have to upgrade to 1.1.x where it now uses off_t and will be<br>
able to handle large responses even on 32bit platforms.<br>
Alternatively, just forget about "proxy_buffering off" as you<br>
don't need it anyway, see above.<br>
<br>
Maxim Dounin<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div><br></div>