On 30/05/2015 8:34 p.m., Henri Wahl wrote:
>
>> Thanks for any hint and best regards
>>
>
> Is there really nobody else using this combo of OpenBSD + Squid workers?
Quite possible. OpenBSD support was broken for a while during 3.3/3.4
lifecycles and most Squid installs are using Linux.
The workers registration problem should not have anything to do with
OpenBSD specificaly though. Its directly related to size of rock caches
and the disk I/O speeds.
If I assume you have say a 50GB rock cache...
(50 GB / 32 KB blocks) * 2 IO per block
=> 3 million disk I/O cycles to load the cache.
Your Squid has 6 seconds to do that, allocate the index memory in many
small blocks as it goes, and then respond to the coordinator.
Recalculate for your actual cache size and check:
* Can your disk handle that speed for non-sequential I/O ?
- technically sequential, but skipping 7 out of each 8 inode "blocks"
can do weird things in the disk controller.
If you have more than one rock cache you need to add them all together.
UFS/aufs/diskd caches are much faster but the swap.state journals can
still be quite large with lots of I/O required to load - and also add
that as non-sequential I/O on top of the pile from rock cache.
I'm working on a patch to make the timeout slightly more configurable
(at build time) and fix a bug I found in the messaging retries. Would
you be happy to test that out?
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
