Search squid archive

Re: wccp2 does not working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux