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
