Re: [squid-users] wccp2 does not working

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 20 Mar 2013 19:58:26 +1300

On 20/03/2013 7:19 a.m., Alex Rousskov wrote:
> On 03/19/2013 09:14 AM, Sokvantha YOUK wrote:
>
>> Here is my configuration
>>
>> # Rockstore filesytem
>> workers 4
>> cpu_affinity_map process_numbers=1,2,3,4 cores=2,4,6,8
>>
>> if ${process_number}=1
>> cache_dir rock /cache1 170000 max-size=31000
>> cache_dir rock /cache2 170000 max-size=31000
>> endif
>>
>> if ${process_number}=2
>> cache_dir rock /cache3 170000 max-size=31000
>> cache_dir rock /cache4 170000 max-size=31000
>> endif
>>
>> if ${process_number}=3
>> cache_dir rock /cache5 170000 max-size=31000
>> cache_dir rock /cache6 170000 max-size=31000
>> endif
>>
>> # AUFS file system
>> if ${process_number}=4
>> cache_dir aufs /cache7/squid/${process_number} 170000 16 256
>> min-size=31001 max-size=200000000
>> cache_dir aufs /cache8/squid/${process_number} 170000 16 256
>> min-size=31001 max-size=200000000
>> endif
>
> Just in case somebody finds this in the archives and tries to replicate,
> please note that the above config does not make sense: It does not allow
> rock directories to share cache storage among workers and it isolates
> the aufs storage to a single worker (#4) as if that worker is somehow
> special.
>
>
> I doubt WCCP problems are related to caching. However, I recommend
> making sure WCCP works _before_ you make your configuration more complex
> by adding caching.

I am suspecting the problem is related to the WCCP default of waiting
until all caches are loaded before starting to advertise HERE_I_AM.
Scanning 1.4 TB of disk is going to take a while. Sokvantha YOUK was
waiting _only_ about ten minutes for WCCP packets.

With the "fixed" config the AUFS disk cache is isolated into a worker
separate from the rock stores. This introduces a few new factors:
  1) no single worker is loading more than 333GB of cache. This alone
could make it fast enough to start emitting WCCP packets in the waiting
period.

  2) the AUFS cache is isolated by itself on one worker. This means that
worker is possibly _only_ loading the swap.state journal before starting
to emit WCCP packets. Which has long been a highly optimized process.

I suspect that factor #2 is teh main one causing WCCP packets to show up
within the waited 10 minute period.

Sokvantha YOUK, I have some tests for you to try:

1) Using your "works" configuration with per-worker cach_dir lines,
please run with debug_options ALL,1 and check your cache.log to see the
time difference between Startup message and store scan completion
messages from each worker/disker process.

2) Using your original "don't work" configuration please try starting
Squid with the configurtion option wccp2_rebuild_wait set to OFF.

HTH
Amos
Received on Wed Mar 20 2013 - 06:58:33 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 20 2013 - 12:00:06 MDT