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