Re: [squid-users] Squid 3.2x: Question about performances in tmpfs

Thanks Amos

You are talking about rock but it seems that rock is not really ready in
the 3.2 branch...
There is some bugs still need to be fixed.

Do you confirm it ?

Le 02/03/2012 17:03, Amos Jeffries a écrit :
> On 3/03/2012 4:47 a.m., David Touzeau wrote:
>> Dear /
>> /
>> I have a server with 8Go memory on 4 processors.
>> Currently my squid proxy 3.2 and my Debian using around 2Go memory in
>> the full production mode.
>>
>> I would like to try to add a kind of "temporary" cache in tmpfs using
>> around 3.5go of Squid Cache./
>>
>> /Did it make sense to perform this infrastructure in order to speed
>> I/O for Squid ?/
>>
>
> I'd suggest looking into rock store instead. It is a more efficient
> cache than UFS, equivalent in speed to a tmpfs, with real disk backing.
>
>> /Did it possible to do this on the squid.conf ? :/
>> /
>
> Yes, as long as the tmpfs is mounted before Squid starts, and never
> disappears.
>
>> Means that the tmpfs is monted on /var/cache/squid-tmpfs
>> Each instance will have 875 Mb on a tmpfs and when the size is full
>> it will automatically start to run the standard cache based on disk.
>
> Squid prefers the disk caches with more space over smaller ones. So
> what you will see is the opposite filling style with the below config.
> You can instead use the min/max object limits on each dir to force
> small stuff into the tmpfs.
>
> Amos
>
>> /
>> /workers 4
>> if ${process_number} = 1
>> cache_dir aufs /var/cache/squid-tmpfs/proc1 875 128 512
>> cache_dir aufs /var/cache/squid2-1 15000 128 512
>> endif
>> if ${process_number} = 2
>> cache_dir aufs /var/cache/squid-tmpfs/proc2 875 128 512
>> cache_dir aufs /var/cache/squid2-2 15000 128 512
>> endif
>> if ${process_number} = 3
>> cache_dir aufs /var/cache/squid-tmpfs/proc3 875 128 512
>> cache_dir aufs /var/cache/squid2-3 15000 128 512
>> endif
>> if ${process_number} = 4
>> cache_dir aufs /var/cache/squid-tmpfs/proc4 875 128 512
>> cache_dir aufs /var/cache/squid2-4 15000 128 512
>> endif
>>
>>
>> /
>> /
>
>
Received on Fri Mar 02 2012 - 16:07:33 MST