Another experiment is to try purging and rebuilding the ssl_crtd helper
cache.
Hi Amos,
We do the above on every squid restart anyway (via a wrapper script).
Your config file has some nits (may not be relevant to the problem though):
* Try switching the order of "manager localhost" so
On 21/06/2014 12:32 a.m., Alex Crow wrote:
>
> On 19/06/14 18:57, Eliezer Croitoru wrote:
>> OK and what about the squid.conf?
>>
>> I have not seen one until now and it seems to me kind of important...
>>
>> I do know about systems that do not get 100% cpu and it's weird that
>> we have couple gu
On 20/06/14 14:28, Eliezer Croitoru wrote:
OK after reading the config file it seems like there are couple things
that we\you should be aware of when looking at the issue:
1. External helpers code was changed from 3.3 to 3.4 (one way)
2. you are using delay_pools.
3. you are using ntlm aut
>
> Can you try with delay_access 1 allow !CONNECT (for each rule)
>
I forgot http://bugs.squid-cache.org/show_bug.cgi?id=2907
> FYI, config attached.
>
> The same config works without CPU spikes in 3.3.
>
> Alex
>
>
>
Can you try with delay_access 1 allow !CONNECT (for each rule)
On 06/20/2014 03:32 PM, Alex Crow wrote:
On 19/06/14 18:57, Eliezer Croitoru wrote:
OK and what about the squid.conf?
I have not seen one until now and it seems to me kind of important...
I do know about systems that do not get 100% cpu and it's weird that
we have couple guys having the issue
OK and what about the squid.conf?
I have not seen one until now and it seems to me kind of important...
I do know about systems that do not get 100% cpu and it's weird that we
have couple guys having the issue while others do not.
Thanks,
Eliezer
On 05/20/2014 09:54 PM, Alex Crow wrote:
Hi A
On 21/05/14 08:30, Amos Jeffries wrote:
On 21/05/2014 8:11 a.m., Alex Crow wrote:
Wrong on my part again.
Changing the memory_replacement_policy still got to 100% cpu after
Shift-reload in Thunderbird a few times - even disabling cache_mem
entirely did not eliminate it. 3.3 never gets about ab
Thunderbird, are these troubles all coming from HTML emails?
I meant Firefox, sorry - I was writing the email in Thunderbird so typed
that in instead. Not quite 40 yet but already losing it!
Does using AUFS instead of diskd cache types help? there are a lot of
calls in that trace polling
On 21/05/2014 8:11 a.m., Alex Crow wrote:
> Wrong on my part again.
>
> Changing the memory_replacement_policy still got to 100% cpu after
> Shift-reload in Thunderbird a few times - even disabling cache_mem
> entirely did not eliminate it. 3.3 never gets about about 67% load no
> matter how many
Wrong on my part again.
Changing the memory_replacement_policy still got to 100% cpu after
Shift-reload in Thunderbird a few times - even disabling cache_mem
entirely did not eliminate it. 3.3 never gets about about 67% load no
matter how many time the page is reloaded.
So again hope the the
I think I've just found something. I had this set:
memory_replacement_policy heap GDSF
replacing this with:
memory_replacement_policy lru
got rid of the high CPU in 3.4 (works ok in 3,3).
I will try heap LRU.
Cheers
Alex
On 20/05/14 19:54, Alex Crow wrote:
Hi Amos, all,
I have set up a t
Hi Amos, all,
I have set up a test box with latest 3.4.5 nightly. I get 95-100% cpu
even with one client accessing the cache. I've attached a compressed
strace of the child process in case anything is evident from that.
Please tell me what else I might need to do to help resolve this issue.
13 matches
Mail list logo
