Нет, у нас вообще фаерволы на этих серверах не используются. iptables -L пуст совершенно<br>MTU для eth0 установлен 1500, насколько я понимаю это дефолт для Ethernet<br><br><div><span class="gmail_quote">03.03.08, <b class="gmail_sendername">Alexey Kovyrin</b> <<a href="mailto:alexey@kovyrin.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">alexey@kovyrin.net</a>> написал(а):</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Очень похоже на проблемы с mtu. Вы там случаем icmp не фаерволите?<br> <br> 2008/3/3 TDz <<a href="mailto:tdz@modestus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdz@modestus.org</a>>:<br>
<br>> Забавная штука судя по всему обслуживание/необслуживание запросов зависит от<br>
> размера ответа. Так файлы до ары килобайт отдаются нормально а свыше<br> > подвисают. Что интересно в putty если вызвать программу с богатым выводом<br> > (top например или ps aux или длинный man) то коннект тоже подвисает<br>
> Мог пров по ошибке включить какое-то ограничение по кол-ву данных на<br> > коннект?<br> ><br> > 03.03.08, TDz <<a href="mailto:tdz@modestus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdz@modestus.org</a>> написал(а):<br>
><br> > > Сегодня ни с того ни с сего перестали отвечать все продакшн сервера на<br>
> базе nginx 6.0.26<br> > > Никаких изменений в конфигурации или апдейтов системы не делалось, они<br> > даже не рестартились<br> > > На всех серверах 2 сетевых интерфейса - внутренний (eth1 172.16.0.X) и<br>
> внешний (eth0)<br> > > nginx слушает на eth0<br> > ><br> > > Симптомы:<br> > > любые запросы из инета зависают в нирване (HTTP request sent, awaiting<br> > response...) не дожидаять ответа<br>
> > исключение составили локейшены с редиректами типа 302, там nginx отдавал<br> > хедер сразу<br> > ><br> > > Что интересно на запросы из сети нет ответов, на локальные запросы на тот<br> > же интерфейс ответы есть (тестировал обычным wget). При чём я пытался<br>
> сделать обычный putty ssh тунель чтобы получился вроде как локальный запрос<br> > (так сказать обмануть ошибку) ничего не дало. Что интересно более старый<br> > nginx который по случайности висел на одной из машин с аналогичным конфигом<br>
> имел аналогичные проблемы, тоесть это очевидно не ошибка самого nginx а<br> > какая-то грабля в системе<br> > ><br> > > Трабла временно решилась перевешиванием nginx на внутренний интерфейс и<br> > проксированием на него с другой машины, но мне хотелось бы понять в чём<br>
> собственно загвоздка и почему она так неожиданно из ниоткуда взялась<br> > ><br> > > Если кто-то сталкивался с похожими проблемами был бы благодарен за любой<br> > фидбек<br> > ><br> > > Дмитрий<br>
> ><br> ><br> ><br> <br> <br> <br> <br>--<br> Alexey Kovyrin<br> <a href="http://kovyrin.info/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://kovyrin.info/</a><br> </blockquote>
</div><br>