Re: [squid-users] (smp-rock )store rebuilding take too much time while squid has started !!

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 13 Nov 2013 15:42:12 -0700

On 11/13/2013 02:04 AM, Dr.x wrote:
> hi ,
> when i restart squid
> ihave
> Store rebuilding is 0.94% complete
>
> note that although im getting small storage to squid (10 G) it takes alot of
> time to rebuild !!!
>
> also , im disableing wccp rebuild during starr , which mean that squid will
> start with wccp and the store hasnt rebuilt yet
>
> the question is :
> can i let squid do rebuild it faster ???

There is currently no configuration options to tune rebuild speed except
foreground rebuild. In general, there is a trade-off between rebuild
speed and resources remaining for HTTP traffic handling, but Squid lacks
options to control that trade-off (IIRC). There are also bugs that make
Squid less responsive that necessary during rebuild. Finally, Rock
storage rebuilds slower than clean UFS rebuild (but probably faster than
dirty UFS rebuild).

Going forward, my plan is:

1) Fix rebuild responsiveness bugs (in progress).

2) Optimize Rock rebuild (may require Rock db format change and will
probably be done after Large Rock integration).

3) Fix WCCP handling during SMP disk cache rebuild (there is no sponsor
for this fix at this time though, and I am not sure this bug has been
officially filed even, so this may take a while unless somebody volunteers).

> should i stop wccp redirection to squid from router untill rebuild is
> completed ?? or it is just normal issue to let squid start and redirect
> users and the rebuilt hasnt finished yet?

Bugs notwithstanding (e.g., see #3 above), there is no right or wrong
choice here. Some folks prefer Squid to handle traffic while their cache
is being loaded. Others prefer Squid to start handling traffic with the
fully loaded cache. The best option depends on the deployment
environment and optimization goals.

Cheers,

Alex.
Received on Wed Nov 13 2013 - 22:42:21 MST

This archive was generated by hypermail 2.2.0 : Thu Nov 14 2013 - 12:00:03 MST