[squid-users] Re: Squid 3.1.x and right configuration parameters for tmpfs 8GB

From: RW <rwmaillists_at_googlemail.com>
Date: Fri, 2 Dec 2011 18:53:02 +0000

On Fri, 02 Dec 2011 15:15:59 +1300
Amos Jeffries wrote:

> On 2/12/2011 5:13 a.m., Matus UHLAR - fantomas wrote:
> > On 01.12.11 15:05, Josef Karliak wrote:
> >> I wanna use tmpfs for squid cache, is 8GB enough or too big ?
> >> We've about 3000 computers behind squid, for OS is 16GB
> >> sufficient, that's why I used 8GB for squid tmpfs.
> >
> > what is the point of using tmpfs as squid cache? I think using only
> > memory cache would be much more efficient (unless you are running
> > 32-bit squid).
> Yes, consider the purpose of why a disk cache is better than RAM
> cache: objects are not erased when Squid or the system restarts.
> ==> tmpfs data is erased when Squid or the system restarts. So why
> bother?

tmpfs is cleared when the system is rebooted or shut down, it can
survive a daemon restart.

> All you gain from tmpfs is a drop in speed accessing the data, from
> RAM speeds down to the Disk speeds. Whether it is SSD or HDD that is
> slower than RAM.

That's not really a fundamental difference. Both memory cache and
tmpfs are stored in ram, optionally backed by swap. Both have the
advantage that there's no need to keep a backing store updated. Either
will force-out pages to swap if you set the cache large enough. If you
have swap configured tmpfs can cache more in memory than memory cache
because it's safe to let it use more - swap usage by tmpfs has very
little impact on the rest of the system.

Memory cache isn't faster because it's in memory per se. It's faster
because there's a lighter interface to the in-memory objects and
because in some configurations it prioritizes smaller objects giving a
higher hit rate on objects in memory.

I don't think it's necessarily a bad idea to use tmpfs, there may be
many cases where using both tmpfs and memory cache outperforms memory
cache alone.
Received on Fri Dec 02 2011 - 18:53:23 MST

This archive was generated by hypermail 2.2.0 : Sat Dec 03 2011 - 12:00:02 MST