client timed out & readv() failed

[Evgeniy Berdnikov]

On Thu, Mar 03, 2016 at 10:49:34PM +0300, Maxim Dounin wrote:
> On Thu, Mar 03, 2016 at 09:41:09PM +0300, Evgeniy Berdnikov wrote:
> > On Thu, Mar 03, 2016 at 08:36:28PM +0300, Maxim Dounin wrote:
> > > Я бы для начала попробовал поискать statefull firewall между 
> > > фронтендом и бекендом.  Возможно, у него кончаются state'ы, и он 
> > > таким нехитрым образом пытается об этом сообщить.
> > 
> >  Нет, "while sending response to client" и "while reading upstream"
> >  однозначно свидетельствуют о том, что соединение установлено.
> >  Поэтому переполнение таблицы коннекций исключается.
> 
> Это очень сильно зависит от того, как именно ведёт себя firewall, 
> когда у него заканчиваются state'ы.  E.g., pf умеет уменьшать 
> таймауты в случае большого числа state'ов, и соответственно может 
> убить соединение в любой момент времени.

 Не думаю, что у вопрошавшего на линке скоростью 10G стоит файрвол.

> Так или иначе - "Connection reset by peer" при живом бекенде как 
> бы намекает на то, что в первую очередь надо смотреть, что 
> происходит в сети.

 Я бы скорее подозревал наличие какой-то баги в сетевой карте.

 Например, в неправильном подсчёте чексуммы для пакетов с опцией sack
 при включенном rx/tx checksumming offload'е, из-за чего все пакеты при
 ретрасмитах дропаются. Коннекция умирает по таймауту. Но при этом
 закрывается пакетом RST, который идёт без sack и потому доходит до
 ядра получателя, вот и "Connection reset by peer". Так как насытить
 линк 10G непросто, то потерь мало, но стоит хоть одному фрейму
 пропасть -- sack, затем ретрансмиссии с sack, таймаут, reset. 

 Можно придумать другие сценарии, наверное.
-- 
 Eugene Berdnikov