On 24/08/2014 6:06 a.m., dxun wrote: > So, to sum it all up (please correct me if I'm wrong) - it is possible to > have multiple cache_dirs AND instruct a single squid instance to place files > in those caches according to file size criteria using > min_file_size/max_file_size params on the cache_dir directive. Also, > maximum_object_size directive is basically a global max_file_size param > applied to all cache_dirs, so it has to be specified BEFORE any particular > cache_dir configuration.
Sort of. * default value for maximum_object_size is 4MB, which is used until you change it. * maximum_object_size is the default value for cache_dir max-size=N parameter. Its current value is applied only if you omit that parameter from a cache_dir. For example (not a good idea to actually do it like this): # default maximum_object_size is 4 MB cache_dir ufs /a 100 16 256 maximum_object_size 8 MB cache_dir ufs /b 100 16 256 maximum_object_size 2 MB cache_dir ufs /c 100 16 256 Is the same as writing: cache_dir ufs /a 100 16 256 max-size=4194304 cache_dir ufs /b 100 16 256 max-size=8388608 cache_dir ufs /c 100 16 256 max-size=2097152 > > If that is the case, I am wondering - is this separation actually > inadvisable for any reason? It is advised for better performance on high throughput configurations with multiple cache_dir. It does not matter for other configurations. > Is there a better way to separate files > according to their transiency and underlying data store speed? Squid automatically separates out the most recently and frequently used objects for storage in the high speed RAM cache. Also monitors the drive I/O stats for overloading. There is just no differentiation between HDD and SSD speeds (yet) - although indirectly via the loading checks SSD can see more object throughput then HDD. rock cache type is designed to reduce disk I/O loading on objects with high temporal locality ("pages" often requested or updated together in bunches), particularly if they are small objects. Transiency is handled in memory, or by RAM caching objects for a while before they go near disk. This is controlled by maximum_object_size_in_memory, objects over that limit will have disk I/O regardless of transiency in older Squid. Upcoming 3.5 releases only involve disk on them if they are actually cacheable. ? What would > you recommend? Upstream recommendation is to configure maximum_object_size, then your cache_dir ordered by the size of objects going in there (smallest to largest). Also, to use a Rock type cache_dir for the smallest objects. It can be placed on the same HDD as an AUFS cache and working together a rock for small objects and AUFS for large objects can utilize larger HDD sizes better than either cache type alone. * 32KB object size is the limit for rock in current stable releases, that is about to be increased with squid-3.5. Based on theory and second-hand reports: I would only use an SSD for rock type cache with block size parameter for the rock cache sized to match the SSD sector or page size. So that only writing a single rock block/page causes each SSD sector/page to bump further towards its lifetime write limit. Amos