Brian wrote: > $ egrep -i "storeAufsOpenDone" cache.log | wc -l > 408 If only 12 people are using this, perhaps 408 is a lot - I don't get that particular error so wouldn't know.
> Squid Cache: Version 2.5.STABLE1 > configure options: --prefix=/usr/local --disable-dependency-tracking --enable-async-i o=32 --with-aio --enable-snmp --enable-ssl --with-openssl=/usr/local/ssl --e nable-poll Well I assume you know the chorus of: upgrade to a newer version - yours is not so out of date but still a lot has been fixed. Check what was fixed http://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE2-RELEASENOTES.ht ml and here for bug info: http://www.squid-cache.org/Versions/v2/2.5/bugs/#STABLE1 - or just do the easy/lazy thing and upgrade to 2.5STABLE3 before further testing. Also: why did you set async-io to 32? I just used "--enable-async-io" and let squid set it's default. Maybe your way is better but just so you know why you did that and that it's not at all related to your aufs problem.... Also I thought you had to include aufs as one of the compile options? I did (--enable-storeio=aufs,ufs). Maybe I didn't have to since I assume your squid would squawk if it weren't compiled in (does "squid -k parse" run cleanly?). Unrelated but I'd add --enable-removal-policies=heap,lru so you can later try the heap algorithms (we use GDSF). Lastly, why are you enabling ssl? If you think you need to enable ssl to pass https/443 traffic that is incorrect. From reading Henrik and other's posts, it looks like lots of people compile it in when that wasn't what they really wanted (see the archives for better explanations). If you don't need it, I'd suggest leaving it out. > cache_dir aufs /squid/s00 1781188 16 256 > cache_dir aufs /squid/s01 1593568 16 256 I'm pretty sure Henrik confirmed for me that the cache_dir sizing parameter is in MB's. It looks like earlier you posted the output from a "df -k" and if so, you've got 2GB partitions. Above you've defined cache_dirs of 1781GB (gigabytes). I just checked my conf default and in fact the value is MB's. So drop that down to: cache_dir aufs /squid/s00 1781 16 256 For such small cache_dir's, your RAM vis-a-vis sizing is fine but as you make a larger cache, be sure to use the FAQ to calculate the memory correctly so you don't make your cache_dir's larger than RAM+squid's other RAM needs will require. Since you original problem "resource temporarily unavailable" sounds like a resource contention issue, I would try to get squid it's OWN disk, not just partition. aufs is great (I use it as well) but my uninformed opinion would be to give it all the I/O you can - check the archives I am pretty sure they would confirm that. The fact that you don't see this error often in the archives would imply that it is probably your configuration. The fact that you've done two things squid recommends you not do (have a huge/incorrecly defined cach_dir allotment and put them on non-dedicated disks) my guess would be that the error stems from one or both of those and once you've fixed both you should be ok. hth Adam
