<div dir="ltr">Sorry, but it is still the same... server is now running the modified nginx, but this file still can't be fetched: <a href="http://www.noal.org.il/static/temp/barvazi2.pdf">http://www.noal.org.il/static/temp/barvazi2.pdf</a> .<br>
I just can't think what the problem might be.<br><br>If it helps, my VPS is running CentOS 5.2 with kernel 2.6.18.<br><br>Any more tests I can run?<br><br>Thanks again.<br>Yo'av.<br><br><br><div class="gmail_quote">
2009/1/20 Igor Sysoev <span dir="ltr"><<a href="mailto:is@rambler-co.ru">is@rambler-co.ru</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, Jan 20, 2009 at 02:59:34AM +0200, Yo'av Moshe wrote:<br>
<br>
> Thanks.<br>
> I'm not an strace guru but I don't think it shows anything unusual...<br>
><br>
> <a href="http://paste-it.net/public/mffe731/" target="_blank">http://paste-it.net/public/mffe731/</a><br>
><br>
> You can see download starts right at the beginning, and at 02:25:25 you can<br>
> see the last sendfile64 event. After that, no data was sent and I couldn't<br>
> find anything related to that in this strace log.<br>
><br>
> The only thing this strace log is telling me is that nginx knows that there<br>
> is still more data to send, since it recognized the right size of the file<br>
> in the beginning (line 13: sendfile64(22, 23, [0], *1950230)*), and it knows<br>
> it has more to send by the last sendfile event (line 1173: sendfile64(22,<br>
> 23, [1618265], *331965*)).<br>
><br>
> What stops the sending?<br>
<br>
</div>Looking at these lines:<br>
<br>
2140 02:25:24 epoll_wait(11, <unfinished ...><br>
2140 02:25:24 <... epoll_wait resumed> {{EPOLLOUT, {u32=140043201, u64=13817743186826159041}}}, 512, 22224) = 1<br>
2140 02:25:24 gettimeofday({1232411124, 913871}, NULL) = 0<br>
2140 02:25:24 sendfile64(22, 23, [1559225], 391005) = 28800<br>
<br>
2140 02:25:24 epoll_wait(11, {{EPOLLOUT, {u32=140043201, u64=13817743186826159041}}}, 512, 22077) = 1<br>
2140 02:25:25 gettimeofday({1232411125, 66164}, NULL) = 0<br>
2140 02:25:25 sendfile64(22, 23, [1588025], 362205) = 30240<br>
<br>
2140 02:25:25 epoll_wait(11, {{EPOLLOUT, {u32=140043201, u64=13817743186826159041}}}, 512, 21924) = 1<br>
2140 02:25:25 gettimeofday({1232411125, 211986}, NULL) = 0<br>
2140 02:25:25 sendfile64(22, 23, [1618265], 331965) = 28800<br>
<br>
I see that client socket (22) is associated with u64=13817743186826159041<br>
in epoll. Also I see that the socket was added and modified in epoll<br>
in the start of the transfer:<br>
<br>
2140 02:25:12 epoll_ctl(11, EPOLL_CTL_ADD, 22, {EPOLLIN|EPOLLET, {u32=140043201<br>
, u64=579069412499841985}}) = 0<br>
<br>
2140 02:25:12 epoll_ctl(11, EPOLL_CTL_MOD, 22, {EPOLLIN|EPOLLOUT|EPOLLET, {u32=140043201, u64=13817743186826159041}}) = 0<br>
<br>
However, I do not see socket deletion from epoll or closing.<br>
I see only that after 02:25:25 epoll_wait(), i.e. kernel, never<br>
returned any events about 22 socket.<br>
<br>
You may try the attached patch.<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="Wj3C7c">Igor Sysoev<br>
<a href="http://sysoev.ru/en/" target="_blank">http://sysoev.ru/en/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Yo'av Moshe<br>
</div>