> 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