Re: [squid-users] squid3 SMP aufs storage/process
On 03/09/2013 12:48 AM, jiluspo wrote: Therefore squid SMP is not stable. Support for ufs caching is not related to stability IMO, but perhaps your definition of stable is different from mine. if we need to store more than 32KB the best way is to use multi-instance and peering... Or use the unofficial Large Rock branch. It all depends on individual circumstances and needs. There is no single Squid version that works well for everybody. When would probably finish the rock for large content? The Large Rock branch on Launchpad is ready for testing. It will probably be submitted for Squid Project review in a few months. HTH, Alex. -Original Message- From: Alex Rousskov [mailto:rouss...@measurement-factory.com] Sent: Saturday, March 09, 2013 3:03 PM To: squid-users@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
Re: [squid-users] squid3 SMP aufs storage/process
On 03/09/2013 09:19 AM, Adam W. Dace wrote:
being able to use configuration like this sure makes it easier:
# Uncomment and adjust the following to add a disk cache directory.
cache_dir aufs /usr/local/squid/var/cache${process_number}/squid 1024 16 256
One should also add squid.conf conditional to exclude the above line
from being seen by the Coordinator process. Here is a sketch:
if ${process_number} = coordinator process number here
# do nothing -- this is Coordinator
else
# configure all SMP-unaware, non-shared cache_dirs here
cache_dir aufs ...${process_number}...
endif
Otherwise, Coordinator will create (during squid -z) and then open the
corresponding cache_dir, creating confusion and possibly running into bugs.
HTH,
Alex.
On Sat, Mar 9, 2013 at 1:48 AM, jiluspo jilu...@smartbro.net wrote:
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:rouss...@measurement-factory.com]
Sent: Saturday, March 09, 2013 3:03 PM
To: squid-users@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
Re: [squid-users] squid3 SMP aufs storage/process
It's not like they made it difficult. I haven't successfully gotten
SMP up and running,
but being able to use configuration like this sure makes it easier:
# Uncomment and adjust the following to add a disk cache directory.
cache_dir aufs /usr/local/squid/var/cache${process_number}/squid 1024 16 256
On Sat, Mar 9, 2013 at 1:48 AM, jiluspo jilu...@smartbro.net wrote:
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:rouss...@measurement-factory.com]
Sent: Saturday, March 09, 2013 3:03 PM
To: squid-users@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
--
Adam W. Dace colonelforbi...@gmail.com
Phone: (815) 355-5848
Instant Messenger: AIM Yahoo! IM - colonelforbin74 | ICQ - #39374451
Microsoft Messenger - colonelforbi...@live.com
Google Profile: http://www.google.com/profiles/ColonelForbin74
[squid-users] squid3 SMP aufs storage/process
Good day, If squid3 configured with cache_dir aufs per process would they share to other process?
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.
RE: [squid-users] squid3 SMP aufs storage/process
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:rouss...@measurement-factory.com] Sent: Saturday, March 09, 2013 3:03 PM To: squid-users@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
