> That's better, though with such a large growth rate you will need to
> anticipate network bottlenecks far ahead, and be ready to switch to
> gigabit on the squids or grow the number of squids, whichever one is
> cheaper. Set up MRTG or something equivalent to keep an eye on this.
> Squid has a built in SNMP server that can produce some useful graphs
> though MRTG.
i was just trying to produce graphs using squidclient. but i will try
snmp tomorrow :).
>> i think that loadbalancing is based on source ip, instead of url.
>> so carp wouldnt be an option.
>> Is that the same CARP I was looking at?
>> http://squid-docs.sourceforge.net/latest/html/x2398.html
>
obviously not, i googled from carp load balacing and it came up with a
loadbalancer solutions for BSD.
>>
>>>> If you have a load balancer with packet inspection capabilities you
>>>> can also direct traffic that way. On F5 BigIPs the facility is
>>>> called iRules. I'm pretty sure NetScaler can do that too.
>>>>
>>> That is the kinda solution iam looking for, but then without the
>>> cost we are pretty new company without the money to buy expensive
>>> solutions. so we prefer open source solutions.
>>>
>>> another point:
>>> what is your experience with ext2/3 reiserfs?
>>> our ext3 partitions tend to get corrupted, when used for squid
>>> caches or simular purposes.
>>> i tend to change things to reiserfs entirely, but its just a guess.
>>> does anyone have the same experience?
>>
>>
>> Read the flames on the LKML about ReiserFS and decide if it's stable
>> for production use ;-)
>>
>> I've got six squids handling a similar traffic load to what you
>> describe (though on a smaller working set) on ext3 with no corruption
>> issues.
>> No corruption issues on any other server using ext3 either. Looks
>> like you have a serious issue to fix there.
>
LKLM? i havent been around for long, so please forgive my lack of
vocabulair :P
hmm, its strange it only happens on partitions with large directory's
with alot of small files in it.
strange, worth a closer look in the future
Received on Wed Jul 06 2005 - 10:08:24 MDT
This archive was generated by hypermail pre-2.1.9 : Mon Aug 01 2005 - 12:00:02 MDT