Hi Amos , thank you. I just wanted to explain something Now , im okay without SMP , I can save bandwidth and its fine...but cores are not balanced and that may lead some cpu cores reach 100 % But...... I need to use SMP with large rock to save bandwidth .... now it works fine ...but no saving !! Im using 3.4.7 stable What I need is , Someone used 3.head and found a result of saving bandwith.....as an example wt max cache size and mem size allow in large rock ? That wt I need .... I need a fast browsing squid that can save my bandwidth. Amos , can u guide me with a 3.head verison you used with large rock and gave you thr best results of saving bandwidth ??? regards -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Amos Jeffries Sent: Monday, October 27, 2014 5:53 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Large rock supporting with stable squid version -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25/10/2014 2:09 a.m., Ahmed Allzaeem wrote: > Hi > > I want to ask about Large rock supporting. > > In large rock supporting wts the max size for disk store ? and max > size of ram store? The disk store limit depends on HDD/SSD space available. That goes for all cache_dir types. What do you mean by "ram store" ? IIRC, rock storage does away with the split memory/disk "slices" which were used in COSS. So there is no tricky management of how many slices are in memory and swapping in/out. Squid has a RAM store (cache_mem) which is not particularly related to Rock storage. You need to tune that cache_mem size around how much RAM is used for all cache_dir existing, and active transaction needs. Nobody can tell you the answer since the administrative "test, measure, tune" process is the only way to find it. > > I need someone tried large rock with squid 3.head version and have > seen a stability , I used last time squid3.head but it hanged after > sometime > Details required. "hangs after some time" and "it" are very vague. > > I need a help with a squid large rock best practice. > The feature is still in beta. As an early adopter you are one of the people whose feedback will define what the best practice in future will be. Despite being *capable* of large object storage rock is optimal for small objects. UFS/AUFS/diskd cache types are optimal for large objects - except no SMP sharing there yet which is just annoying. For now the regular best practice for cache_dir in general applies. To ensure you have enough RAM for cache index (10-15MB er GB of cached data) not to cause memory swapping, to ensure you do not exceded available disk space, etc. etc. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTuj5AAoJELJo5wb/XPRjwW4IAJcHO5Nbz1y1DZ8K3vIWLEaQ 02kqrTShzkciM98dzMfBzRytq/8zuCiQNW463vgxdypTmcYKo4vNCfuGuf8Jo8yY MxmTsEgZQvZgxCrpCBPuklzz2oyGcIrXvtL0OJZ1WqNL0oa8fjHjJ1YP5RMeGHD4 LwHbM0OI1+MEpGErCETFXGiO5EZz2pnHfWj8VNz3Eb81Dm0whJy09gfayX4Nqm77 W1/1k4fihXZ2WtLvKPqN16fBOrWJUxe0x3r5vhb9YTv/mbU06jv3EPa58tXAI6H0 Etno/ITlwbkJOhvpCJpl6r5BeQyuATEI1NLG1Ffg3Cd5x/cc8NTJHMPUIBhXlHk= =+IXG -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
