Rock store status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Rock store status

FredB
Hello All,

I tried rock store and smp long time ago (squid 3.2 I guess), Unfortunately I definitely drop smp because there are some limitations (In my case), and I fall-back to diskd because there were many bugs with rock store. FI I also switched to aufs without big differences.

But now with the latest 3.5.20 ? Sadly SMP still not for me but rock store ?

There is someone who are using rock store with a high load, more than 800 r/s, without any problem ? There is a real difference in this situation, cpu, speed, memory ?

My configuration is

Debian 8
Squid 3.5.20
16 cores Xeon E5-2637 3.50Ghz
64 Go ram
2 drives sata - 15k - dedicated to caches (+ one for OS) 150 Go each
Delay pool -> BP limitation by ldap account
Authentication digest + basic

Any advice welcome.

Fred

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

Steve Hill
On 17/08/16 11:50, FredB wrote:

> I tried rock store and smp long time ago (squid 3.2 I guess), Unfortunately I definitely drop smp because there are some limitations (In my case), and I fall-back to diskd because there were many bugs with rock store. FI I also switched to aufs without big differences.
>
> But now with the latest 3.5.20 ? Sadly SMP still not for me but rock store ?
>
> There is someone who are using rock store with a high load, more than 800 r/s, without any problem ? There is a real difference in this situation, cpu, speed, memory ?

We use SMP and Rock under the 3.5 series without problems.  But I don't
think any of our sites have as high req/sec load as you.

--
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    [hidden email]        [hidden email]
    +44-1792-824568           +44-1792-825748
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

FredB

>
> We use SMP and Rock under the 3.5 series without problems.  But I
> don't
> think any of our sites have as high req/sec load as you.

Thanks for your answer

Please can you describe your load and configurations ?
No crash ?

Fred
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

Steve Hill
On 19/08/16 08:45, FredB wrote:

> Please can you describe your load and configurations ?

We supply Squid based online safety systems to schools across the UK,
utilising Rock store for caching and peek/splice, external ACLs and ICAP
for access control/filtering/auditing.  Typically I think our biggest
schools probably top out at around 400,000 requests/hour, but I don't
have any hard data to hand to back that up at the moment.

The only serious Squid issue we've been tracking recently is the memory
leak associated with spliced connections, which we've now fixed (and
submitted patches).  That said, with the schools currently on holiday
those fixes haven't yet been well tested on real-world servers - we'll
find out if there are any issues with them when term starts again :)

--
  - Steve Hill
    Technical Director
    Opendium    Online Safety / Web Filtering    http://www.opendium.com

    Enquiries                 Support
    ---------                 -------
    [hidden email]        [hidden email]
    +44-1792-824568           +44-1792-825748
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

FredB
Just for for information, no problem after two weeks.
Unfortunately I can't test now with IpcIo (a problem with systemd) but rock store is very stable
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

FredB
One thing, squid restart is very slow because of time required to rebuild the cache

2016/09/13 00:25:34|   Took 1498.42 seconds (3972.24 objects/sec). -> Rock
2016/09/13 00:00:51|   Took 5.71 seconds (533481.90 objects/sec). -> Diskd

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

Alex Rousskov
On 09/13/2016 05:01 AM, FredB wrote:
> One thing, squid restart is very slow because of time required to rebuild the cache
>
> 2016/09/13 00:25:34|   Took 1498.42 seconds (3972.24 objects/sec). -> Rock
> 2016/09/13 00:00:51|   Took 5.71 seconds (533481.90 objects/sec). -> Diskd

This is a known problem, with several important wrinkles, including:

* Squid start itself is not slow. Cache index build is slow.

* Squid can serve requests, including cache hits while it builds rock
index, but indexing does affect overall Squid performance and hit ratios.

* Avoid comparing loading a "few" ufs entries (from the clean swap
state) with scanning all available cache slots for rock. The biggest
difference is observed for a virtually empty ufs cache that was in use
for a short time (small swap.state). Rock focus is on Squid running for
a long time with a full cache (the common and intended use case).

* We are essentially comparing a from-scratch index build for rock with
a clean index loading for ufs. If you remove all swap state files, ufs
indexing time will probably be worse than that of rock. If you leave
dirty swap state files, then ufs indexing may slow down significantly;
this happens after Squid crashes, for example. Rock indexing does not
depend on the previous Squid state.

* Rock indexing can be optimized in various ways, of course. Many trade
offs are involved, and some optimizations may hurt runtime performance.
For example, there is a trade-off between
    - maintaining a disk index (i.e., swap state files) at runtime
     (and then saving a clean index at shutdown) like UFS stores do and
    - building an index from scratch by scanning the entire cache at
      start like rock stores do.


This is now documented at

http://wiki.squid-cache.org/Features/LargeRockStore#Slow_cache_index_build


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Rock store status

FredB
Hello Alex and thank you for the explanations, I forgot but of course the test is running on same hardware and same full caches (2 sata drives 15k rpm 123 Gb of caches each)

I will return to diskd now, because the point 2 is annoying for me, but rock seems very promising for me
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users