[squid-users] connections from particular users sometimes get stuck

[Amos Jeffries]

On 30/09/2016 7:38 p.m., Eugene M. Zheganin wrote:
> On 29.09.2016 23:17, Alex Rousskov wrote:
>>
>> In summary, your browser is probably stuck because Squid could not
>> accept a connection. Why did that accept call fail with ECONNABORTED? I
>> cannot say for sure -- the packet trace is rather dirty/misleading
>> (e.g., it shows the redirect packet being sent to the client _after_ the
>> client follows that redirect which does not make sense).
>>
>> Any relevant errors in you system logs?
> Nothing except
> 
> Limiting closed port RST response from 294 to 200 packets/sec
> 
> repeated by many times, which doesn't look related to this, because they
> keep popping even when nobody's complaining. I've already did the
> initial investigation and found no signs of resource starvation -
> meaning no connection/files/mbufs/memory/pf states starvation happens.
> At least I didn't find it. Plus, it would affect all of the clients
> randomly, right ? Not this particular one.
>>
>> If you cancel browser wait and repeat the request, will it work?
> Sometimes, but this means like 3-5% percents. Most of the time
> rerequests lead to the same timeout, Chrome shows the request is
> "pending" in the developer's tools/network tab for dozens of seconds,
> and so on.
>>  If this
>> was just a random accept failure, then it should work on the second try.
>> If it does not work again, then there is something more serious going on
>> (but you would need to collect more logs to study that).
>>
>> The connection accepting code in Squid is in poor shape, but I do not
>> think those minor code problems affect this particular use case.
>>
> I still have this machine in stuck state (I think), what should I focus on ?

I think the TCP packets, particularly the SYN and first few after that
between the client and Squid.
There may be some clues in the TCP features which they are trying to
negotiate for use. Or the timings relative to when Squid calls accept()
to receive the connection (TCP queues too big etc).

Amos