[squid-users] Squid-3.5.28 slowdown

[Enrico Heine]

Hm, I do at least "believe" that it is very likely to be the same with ecap, but I don't know this protocol in anyway, so I can't give a qualified answer on that. 

Anyway, if it is your issue then you can use the test command provided anytime and see the issue slowly emerging until it reaches an amount where tcp_mem is getting to big and a net rate limit is triggered by the kernel which then finally results in slow networking performance, which can be only resolved with a squid restart  . Also check /var/log/kern.log for the point in time where you had the slowness issue, you should see some lines there which you can provide here.

Anyway, if it is your bug, please share this info with us.

Br, Flashdown

Am 1. März 2019 23:43:49 MEZ schrieb Michael Hendrie <michael at hendrie.id.au>:
>
>> On 1 Mar 2019, at 9:34 pm, Enrico Heine <flashdown at data-core.org>
>wrote:
>> 
>> >>just a shot into the dark<<, is it possible that you use the
>adaption service for ICAP?
>
>There is an eCAP adaptation service but not ICAP, would eCAP be
>effected by the same condition reported the bug report you linked to?  
>Early in the investigation I did change 'ecap enable off' and do 'squid
>-k reconfigure' while the condition was present but it didn't restore
>speed, a full squid restart was required.
>
>> If so, fast test, this should return 0 if u are not affected by this,
>if higher than 0 check the link below:
>> netstat -pa | grep CLOSE_WAIT | wc -l 
>> 
>> also have a look into /var/log/kern.log 
>
>I will check these out next time the condition occurs
>
>Thanks,
>
>Michael

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190304/53477315/attachment.html>