On 04/25/2011 05:31 PM, david@xxxxxxx wrote:
> On Mon, 25 Apr 2011, david@xxxxxxx wrote:
>> On Mon, 25 Apr 2011, Alex Rousskov wrote:
>>> On 04/14/2011 09:06 PM, david@xxxxxxx wrote:
>>>
>>>> In addition, there seems to be some sort of locking betwen the multiple
>>>> worker processes in 3.2 when checking the ACLs
>>>
>>> There are pretty much no locks in the current official SMP code. This
>>> will change as we start adding shared caches in a week or so, but even
>>> then the ACLs will remain lock-free. There could be some internal
>>> locking in the 3rd-party libraries used by ACLs (regex and such), but I
>>> do not know much about them.
>>
>> what are the 3rd party libraries that I would be using?
See "ldd squid". Here is a sample based on a randomly picked Squid:
libnsl, libresolv, libstdc++, libgcc_s, libm, libc, libz, libepol
Please note that I am not saying that any of these have problems in SMP
environment. I am only saying that Squid itself does not lock anything
runtime so if our suspect is SMP-related locks, they would have to
reside elsewhere. The other possibility is that we should suspect
something else, of course. IMHO, it is more likely to be something else:
after all, Squid does not use threads, where such problems are expected.
BTW, do you see more-or-less even load across CPU cores? If not, you may
need a patch that we find useful on older Linux kernels. It is discussed
in the "Will similar workers receive similar amount of work?" section of
http://wiki.squid-cache.org/Features/SmpScale
> one thought I had is that this could be locking on name lookups. how
> hard would it be to create a quick patch that would bypass the name
> lookups entirely and only do the lookups by IP.
I did not realize your ACLs use DNS lookups. Squid internal DNS code
does not have any runtime SMP locks. However, the presence of DNS
lookups increases the number of suspects.
A patch you propose does not sound difficult to me, but since I cannot
contribute such a patch soon, it is probably better to test with ACLs
that do not require any DNS lookups instead.
> if that regains the speed and/or scalability it would point fingers
> fairly conclusively at the DNS components.
>
> this is the only think that I can think of that should be shared between
> multiple workers processing ACLs
but it is _not_ currently shared from Squid point of view.
Cheers,
Alex.
