Re: [squid-users] question about large rock

�� 13/2/14 ����7:08, Alex Rousskov �:
> On 02/12/2014 09:23 AM, k simon wrote:
>
>> I
>> create a 16GB size "rock" and limit the swap rate to 200, swap timeout
>> to 300.
>> When it's full filled, I reconfigured it. Iostat display the disk rps
>> is about 200/s and throughput about 4MBytes/s. It's spent 61 minutes to
>> rebuilding sucessfully, but the worker report it "register failed" 30
>> minutes ago.
>
> Registration should proceed regardless of the cache rebuild. If it does
> not, it is a bug. If there is such a bug, it may have been fixed in
> trunk or even v3.4, but I have not tested that use case recently.
>
OK. When squid 3.4 port on freebsd 10 is ready, I'll test it again.

> For example, if I restart Squid once a month, and there is a secondary
> Squid that can serve traffic during cache rebuild, a 61 minute rebuild
> is not a problem for me. On the other hand, if I have just one Squid and
> restart it every hour during peak usage, the performance degradation
> associated with the rebuild may be prohibitive even if the rebuild takes
> 5 minutes.
>
I have 5 box with 15 squid instances, most instances worked on Freebsd
9+ufs. I'd say squid is stable but IO bottleneck is annoying me. So I
limit one instance serve no more than 600 request per second in the peak
time and the disk's busy% not exceed 80%. Though I know it's quite
inefficient.

> As I said, Rock rebuild has not been optimized yet so you are unlikely
> to see faster rebuild times with Large Rock.
>
>
> The next steps may include:
>
> 1. optimizing Rock code so that it can rebuild faster
> 2. optimizing your OS so that it can read disk faster
> 3. optimizing your disks so that they can read faster
OK, I'd like to tune something and tested it again. And BTW I wonder to
know does the rock store's 32KB slot means that I can use 32KB block size ?

Regards
Simon
Received on Thu Feb 13 2014 - 17:14:18 MST