Re: [squid-users] SMP with multiple cache_dirs config question

On 9/05/2013 4:01 a.m., Neal Howard wrote:
> I am trying to configure a quad-core server (64-bit RHEL 6.4 with 8GB
> ram) for running Squid in SMP mode and not sure if I fully understand
> how to configure for more than one cache_dir to get around the
> limitations of sharing the cache between workers and all the
> implications of attempting what I'm trying to accomplish anyway.
>
> I think I understand that multiple workers can only truly share a rock
> cache, and that they must each have their own ufs disk directory
> structure type of cache. And also the caveat with the rock cache is
> that the maximum shareable object size is a mere 32K bytes. So, for
> example if I want two workers, and to be able to cache objects larger
> than 32K, I need two ufs cache_dirs and one rock cache_dir. I'm
> currently testing the following configs and squid seems to be proxying
> OK, but the cache hits percentages seem to be really low. Is this set
> of cache_dir configs going to get me what I'm fishing for here, in
> that each worker has its own ufs cache for objects greater than 32K
> but less than 4M, and the one rock cache will be shared between the
> two workers for objects 32K and smaller?

For the current releases that is right. There is work underway to raise
the rock size limits, and if anyone gets around to it UFS need not be
this way either. So you will be wanting to readjust in a few versions,
but that is fine for now.

> relevant portion of my squid.conf
> -----------------------------
> workers 2
> cpu_affinity_map process_numbers=1,2 cores=2,3
> if ${process_number}=1
> cache_dir ufs /proxycache1 20000 32 512 min-size=32769 max-size=4096000
> endif
>
> if ${process_number}=2
> cache_dir ufs /proxycache2 20000 32 512 min-size=32769 max-size=4096000
> endif
>
> cache_dir rock /proxycache3 40000 min-size=0 max-size=32768
>
> cache_replacement_policy lru
> store_dir_select_algorithm round-robin
> maximum_object_size 4MB
>
>
> cache_mem 512MB
> maximum_object_size_in_memory 32KB
> memory_cache_shared on
> memory_cache_mode always
> memory_replacement_policy lru
> --------------------------------
>
> Here's the cache hits I'm currently seeing, roughly 1000 active users
> are surfing thru this server:
> Cache information for squid:
> Hits as % of all requests: 5min: 8.4%, 60min: 8.7%
> Hits as % of bytes sent: 5min: 5.5%, 60min: 5.1%
> Memory hits as % of hit requests: 5min: 30.4%, 60min: 26.6%
> Disk hits as % of hit requests: 5min: 16.2%, 60min: 16.5%
>
> ----------------------------------------------------------------------------------------------------------
>
> Any thoughts? Or am I doing anything wrong here?

Hit ratio depends a lot on what the traffic actually is. 30% memory hit
ratio is not too bad. What were you getting before?

NP: the 4MB lmit is just an arbitrary flag in the sand marking a size
which enables large scripts, graphics and audio on web pages, but does
not cache video content. If you have much video traffic and cache space
you may want to consider raising that to a few tens of MB.

PS. I have a doubt about how "memory_cache_mode always" interacts with
SMP-aware Squid shared memory limits.
Could you let me know if turning that off changes the ratios at all?

Amos
Received on Thu May 09 2013 - 04:25:24 MDT