Gavin McCullagh wrote:
Hi, our squid system (according to our munin graphs), is suffering rather from high iowait. I'm also seeing warnings of disk i/o overloading. I'm interested to understand how this disk load scales. I know more disks (we only have a single cache disk just now) would be a big help. One question I have is how (and if) the disk load scales with the size of the cache. I'll present a ludicrously simplistic description of how disk load might scale (purely as a starting point) and see could people point out where I'm wrong. The job a single disk running a cache must do in some time step might be: disk_work = (write_cached_data) + (cache_replacement_policy) + (read_hits) where: (write_cached_data) =~ x * (amount_downloaded) (cache_replacement_policy) = (remove_expired_data) + (LRU,LFUDA,...) (read_hits) =~ byte_hit_rate (LRU,LFUDA,...) =~ amount of space needed =~ x * (amount_downloaded) (remove_expired_data) =~ (amount_downloaded) over previous time so disk_work = f(amount_downloaded,byte_hit_rate,cache_replacement_policy) To me this speculative analaysis suggests that the load on the disk is a function of the byte_hit_rate and the amount being downloaded, but not of the absolute cache size. So, decreasing the cache_dir size might lower the disk load, but only as it lowers the byte_hit_rate (and possibly the seek time on the disk I guess). Is there something wrong in this? Gavin
You appear to be correct. Squid ignores disk objects that it does not need. Things get stored to disk when requests need more memory space, and pulled off disk when they are needed to server a request.
Occasionally during low-load and with a full cache_dir the garbage collection will purge a small % batch of objects which raises disk IO above the hit rate.
Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13 Current Beta Squid 3.1.0.6
