Re: [squid-users] Advise about cache store in SMP mode, single disk

On 9/05/2014 6:29 a.m., fernando wrote:
> Hi there,
>
>
> I have a server configured to run in SMP mode with two cache stores: a
> shared rock store and a dedicated aufs store for each worker. But I have
> only one physical disk (actually a hardware raid).

RAID ? ... pretty much "dont".

http://wiki.squid-cache.org/SquidFaq/RAID

What is recommended for AUFS is a cache_dir per drive spindle. It is
extremely difficult to configure that when RAID is in the way. Since
RAID purpose is partially to hide where the spindles are.

This does not change with SMP. I fact it gets worse as each worker will
be adding I/O contention at much higher overall rate than a single Squid
process could.

>
> My preliminary tests show that having the shared rock store brings
> better response times than having only the aufs stores. But, as I still
> have some disk contention between workers, I wonder if I should replace
> the aufs stores by a diskd one.

diskd is roughly equivalent to AUFS with one I/O thread. It will remove
the contention by removing cache_dir throughput capacity, and thus
limiting Squid traffic speed.
 So no diskd is not likely to be useful if your aim is high performance.
(unless you happen to be using a BSD operating system where an AUFS is
oddly slower, we think a write(2) scheduling bug hits Squid).

>
> Squid docs are not clear about how diskd is supposed to work in a SMP
> setup: will I get only one diskd process, and so eliminate the disk
> contention from aufs stores? Or will squid start a diskd daemon for each
> worker?

Both diskd and AUFS are just different styles of separating the blocking
I/O tasks from the main squid process. AUFS does with with actual
threads. diskd does it with a helper process.

None of the UFS storage types are using SMP-aware code at present so
each SMP worker requires a unique cache_dir location for ufs, diskd, and
aufs caches.

>
> I also guess building a CARP setup wound not be so benefical because
> there would be still many workers competing for the same physical disk.

Yes, in your situation CARP would the be somewhat equivelant to AUFS is
disk behaviour. Just using whole Squid processes instead of lightweight
threads.

I would take a good look over that hardware RAID controller and see if
there is either a way to expose the underlying HDD as mounts for Squid
use (effectively disabling the RAID), or pin a particular Squid worker
process to a physical spindle (random guess at that even being possible).

You dont mention a Squid version, so another thing to look at might be
the upcoming large file support for rock caches in 3.HEAD packages. That
should (in theory a least) let you replace the AUFS dirs with rock dirs.

Amos
Received on Fri May 09 2014 - 17:50:34 MDT