RE: [squid-users] squid3 SMP aufs storage/process

From: jiluspo <jiluspo_at_smartbro.net>
Date: Sat, 9 Mar 2013 15:48:30 +0800

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_at_measurement-factory.com]
> Sent: Saturday, March 09, 2013 3:03 PM
> To: squid-users_at_squid-cache.org
> Subject: Re: [squid-users] 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
Received on Sat Mar 09 2013 - 07:48:53 MST

This archive was generated by hypermail 2.2.0 : Tue Mar 12 2013 - 12:00:04 MDT