Re: [squid-users] Maximum disk cache size per worker

On 03/21/2013 08:11 PM, Sokvantha YOUK wrote:

> Thank you for your advice. If I want large files to be cached when it
> fist seen by worker, My config should change to first worker that see
> large file and cache it else left it over to remaining worker for rock
> store worker?

Your OS assigns workers to incoming connections. Squid does not control
that assignment. For the purposes of designing your storage, you may
assume that the next request goes to a random worker. Thus, each of your
workers must cache large files for files to be reliably cached.

> I don't want cached content to be duplicated
> among AUFS cache_dir and I want to use the advantage of rock store
> which can be shared within worker on SMP deployment.

The above is not yet possible using official code. Your options include:

1. Do not cache large files.

2. Cache large files in isolated per-worker ufs-based cache_dirs,
   one ufs-based cache_dir per worker,
   suffering from false misses and duplicates.
   I believe somebody reported success with this approach. YMMV.

3. Cache large files in SMP-aware rock cache_dirs,
   using unofficial experimental Large Rock branch
   that does not limit the size of cached objects to 32KB:
   http://wiki.squid-cache.org/Features/LargeRockStore

HTH,

Alex.

> On Fri, Mar 22, 2013 at 12:13 AM, Alex Rousskov wrote:
>> On 03/21/2013 02:21 AM, Sokvantha YOUK wrote:
>>
>>> ## 2. Handle large object > 32kb < 200MB. The fourth worker handles large file
>>> 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 to make sure you are not expecting a miracle here: The above worker
>> may cache large files, but ALL workers will receive requests for large
>> files. Workers 1-3 will always miss on large files.
>>
>> On average, 75% of requests for large files will go through workers that
>> do not cache them and do not see them in the worker4 cache (in practice,
>> this could be 90% if those workers happen to be busier due to OS
>> scheduling bias!).
>>
>> If that is what you are after, the above config is correct. Otherwise,
>> you need to redesign.
>>
>>
>> HTH,
>>
>> Alex.
>>
>
>
>
Received on Fri Mar 22 2013 - 03:39:41 MDT