Re: "client prematurely closed connection" между двумя nginx
Evgeniy Berdnikov
bgx на protva.ru
Пн Окт 3 09:54:22 UTC 2016
On Sun, Oct 02, 2016 at 10:03:06PM -0400, Trurl wrote:
> Evgeniy Berdnikov Wrote:
> -------------------------------------------------------
> > On Sat, Oct 01, 2016 at 09:59:51PM -0400, Trurl wrote:
>
> >
> > Заголовок content-length: присутствует в ответе?
>
> на выходе получается 415я ошибка, а nginx при этом всё "лишнее" выкидывает
Я имел в виду ответ того сервера, который выдаёт файлы. Для статики
наличие content-length: нормально, и наоборот, было бы странно, если бы
такой хедер отсутствовал. А если такой хедер есть, непонятно, как клиент
может "не заметить" оборванный при передаче ответ и ничего не написать
при этом в error_log.
> > > Размер кусочка всегда 17376 байт (не зависимо от размера
> > оригинального
> > > файла).
> >
> > Похоже на 12 сегментов с mss=1448 (17376=12*1448), интересно было бы
> > взглянуть на дамп трафика для такой коннекции. Если есть активное
> > оборудование между узлами -- сравнить дампы с обеих сторон.
>
> Это все происходит в локалке в датацентре, и трафик между файлером и нодами
> там слишком интенсивный, чтобы что-то мониторить. А если нагрузки нет - то и
> ошибок нет. А так там даже просто логи включать "больно".
Запись дампа на нагруженной системе может быть непростым делом, да. :)
Но можно начать с простого: взять лишь пакеты SYN, FIN и RST, и проверить
фильтром, все ли они имеют mac-адреса серверов с nginx (проверка гипотезы
об обрыве коннекций каким-то активным оборудованием по пути или со стороны).
Полезно также помониторить icmp.
--
Eugene Berdnikov
Подробная информация о списке рассылки nginx-ru