Hi,
We run a large ISP in New Zealand and are having TREMENDOUS problems with our Cache server.. (Squid Version 2.2 under Redhat Linux 6.1)
The machine we have squid operating on is a Compaq with the following:
1GB RAM
Raid 5 Array with 5 x 18GB 20k seek SCSI drives in them
Raid Controller has 256MB RAM
Dual P700
Dual 100BaseT Ethernet Cards
We find that when we pass a fiar amount of traffic through them Squid keeps running but slowly stops serving pages to anyone.. Eventually it stops running and leaves no comments in the error logs as to why. Both of the machines that we have do this...
We have a VERY generic Squid configuration with no fine tuning and it KEEPS doing it... We have tried squid on a smaller machine with less traffic but it does it as well.
We have a layer 4 switch that sends only HTTP requests through the Proxy (although to do this for some reason the Proxy has to be set up to transparently cache everything) that was supplied by Alteon (a Alteon Cache Director) ....
Do you have any ideas? Do you have any idea as to the OPTIMAL configuration for Squid under this scenario (as in the details in the config file that I should utilise)??? What version of squid should I be using?? Any patches that I should apply? Any comments on the file structure that I should look at implementing?
Your help would really be appreciated!!
Regards,
Daniel Evans B.Sc (Comp Sci), B.Com (Acct), MCSE
Chief Technical Officer
Aaria Star Net
Alternative Futures Limited
Penthouse, Level 26, BNZ Tower
125 Queen Street
Auckland, NEW ZEALAND
Telephone:: + 64 9 307 1629
Facsimile: +64 9 373 3997
Direct Dial Line: +64 9 912 2760
Mobile: +64 21 316 111
=============================================================
The information contained in this message and any annexures
is confidential and intended only for the named recipient(s).
If you have received this message in error, you are
prohibited from reading, copying, distributing and using the
information.
If you have received this message in error, please contact
the sender immediately by return email and destroy the
original message.
=============================================================
Received on Sun Jun 11 2000 - 15:41:25 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:53:59 MST