于 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
