Therefore squid SMP is not stable. if we need to store more than 32KB the best way is to use multi-instance and peering...I wish I could use multicast in localhost. When would probably finish the rock for large content? I've tried in production squid3head SMP rock storage only and crashed with BUG 3279: HTTP reply without Date: @1kreq/sec squid3(storied worker2) vs squid2(storeurl) coss..... squid2 gets higher hit. And to be honest. Squid2head runs more stable than squid3 stable. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Saturday, March 09, 2013 3:03 PM > To: squid-users@xxxxxxxxxxxxxxx > Subject: Re: squid3 SMP aufs storage/process > > On 03/08/2013 11:21 PM, jiluspo wrote: > > > If squid3 configured with cache_dir aufs per process would they > > share to other process? > > No. Ufs-based store modules, including aufs, are currently not > SMP-aware. If you use them in SMP Squid (without protecting them with > SMP conditionals), your cache will get corrupted. > > SMP conditionals in squid.conf can be used to prevent corruption, but > they also prevent sharing of cache_dirs among workers. > > Rock store and memory cache are SMP-aware, share cache among workers, > and do not need SMP macros, but they have their own limitations (we are > actively working on addressing most of them). > > > Pick your poison, > > Alex. > > Email secured by Check Point
