Re: [squid-users] Uneven load distribution between SMP Workers

On Wed, Jul 31, 2013 at 1:44 AM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 07/30/2013 06:44 AM, Tim Murray wrote:
>
>> I'm running Squid 3.3.5 on 3 multicore systems here, using SMP and 6
>> workers per server dedicated to their own core. Each one running OS
>> RHEL6 U4 with 2.6.32 kernel.
>>
>> I'm noticing as time goes on, some workers seem to be favoured and
>> doing the majority of the work. I've read the article regarding SMP
>> Scaling here:
>>
>> http://wiki.squid-cache.org/Features/SmpScale
>>
>> However I'm find our workers CPU time is differing quite substantially;
>
> As discussed on the above wiki page, this is expected. We see it all the
> time on many boxes, especially if Squid is not very loaded. IIRC, the
> patch working around that problem has not been submitted for the
> official review yet -- no free cycles to finish its polishing at the moment.
>
>
>> I can also see the connections differ massively between the workers:
>
> Same thing.
>
>
>> I'm a little concerned that the more people I migrate to this solution
>> the more the first 1 or 2 workers will become saturated. Do the
>> workers happen to have some form of source or destination persistance
>> for (SSL?) connections or something that might be causing this to
>> occur?
>
> The wiki page provides the best explanation of the phenomena I know
> about. In short, some kernels (including their TCP stacks) are not very
> good at balancing this kind of server load.
>
>
>> And is there anything I can do to improve the distribution between
>> workers?
>
> I am not aware of any specific fix, except for the workaround patch
> mentioned on the wiki.
>
>
> Alex.
>

Thank you very much for that Alex, to be honest when I read the Wiki
page I had assumed this patch had already been implemented.

In the meantime, I might see if using separate http_ports for each
worker and using the load balancer to even up the spread of traffic
will work.
Received on Wed Jul 31 2013 - 01:13:28 MDT