[squid-users] few questions around multiple cache_dirs
Hi. I'm in the early stages of designing and testing a config with multiple aufs cache_dirs on squid-2.6.STABLE3 as httpd accel for a lot of content, and have a few questions based on what I've observed thus far: * "x-squid-internal/vary" stubs appear to be able to wind up on a different cache_dir than the object itself. Is this a bug? Or a tradeoff in favor of performance in the cache_dir being available 99% of the time case, rather than storing the stubs on the same cache_dir so a failure of a disk containing one or the other doesn't invalidate the object? (note: I'm using max-size, which may have contributed to the splitting, as the stubs are small and the objects large). * how does squid determine which of several cache_dirs has an object after a restart... is the complete url->cachefile mapping stored in swap.state and each completely loaded into memory at startup, or are N lookups performed, where N is the # of cache_dirs? Does an unclean shutdown/interrupted flush to swap.state completely invalidate all objects in a cache_dir, or does it attempt to "fsck" the objects? Also, if entirely in memory, is it exempt from cache_mem limits? * although i admittedly can't reproduce now, i earlier saw object files in the aufs cache_dir occasionally getting renamed(rewritten?) in the same cache_dir, incrementing the filename by 1 on each of multiple successive identical requests (same client). any idea what could account for this behavior? thanks, -neil
[squid-users] few questions around multiple cache_dirs
Hi. I'm in the early stages of designing and testing a config with multiple aufs cache_dirs on squid-2.6.STABLE3 as httpd accel for a lot of content, and have a few questions based on what I've observed thus far: * "x-squid-internal/vary" stubs appear to be able to wind up on a different cache_dir than the object itself. Is this a bug? Or a tradeoff in favor of performance in the cache_dir being available 99% of the time case, rather than storing the stubs on the same cache_dir so a failure of a disk containing one or the other doesn't invalidate the object? (note: I'm using max-size, which may have contributed to the splitting, as the stubs are small and the objects large). * how does squid determine which of several cache_dirs has an object after a restart... is the complete url->cachefile mapping stored in swap.state and each completely loaded into memory at startup, or are N lookups performed, where N is the # of cache_dirs? Does an unclean shutdown/interrupted flush to swap.state completely invalidate all objects in a cache_dir, or does it attempt to "fsck" the objects? Also, if entirely in memory, is it exempt from cache_mem limits? * although i admittedly can't reproduce now, i earlier saw object files in the aufs cache_dir occasionally getting renamed(rewritten?) in the same cache_dir, incrementing the filename by 1 on each of multiple successive identical requests (same client). any idea what could account for this behavior? thanks, -neil
Re: [squid-users] few questions around multiple cache_dirs
On tor, 2007-08-09 at 14:08 -0700, Neil Harkins wrote: > * "x-squid-internal/vary" stubs appear to be able to wind up on a > different cache_dir than the object itself. Is this a bug? It's not a bug, it's a design artefact. The stub and the object is separate from each other, so there is only 1/N probability they will end up on the same cache_dir just as for any other two objects (assuming none of the max-/min-size options is used). The risk of loosing the object due to loss of another cache_dir is not considered important. > * how does squid determine which of several cache_dirs has an object > after a restart... By reading the swap.state files, these contains the per-cache_dir object indexes + transaction log. > lookups performed, where N is the # of cache_dirs? Does an unclean > shutdown/interrupted flush to swap.state completely invalidate all > objects in a cache_dir, varies. > Also, if entirely in memory, is it exempt from cache_mem limits? cache_mem is only object storage in memory, not the meta data. > * although i admittedly can't reproduce now, i earlier saw object > files in the aufs cache_dir occasionally getting renamed(rewritten?) > in the same cache_dir, incrementing the filename by 1 on each of > multiple successive identical requests (same client). any idea what > could account for this behavior? Most likely the client forced a refresh of the object using Control-Reload or similar. Regards Henrik signature.asc Description: This is a digitally signed message part
