I did not expect that to make a difference, I just thought I should mention the difference between the post and the log - just in case.You wrote something about ICP disabled, but you have 2004/06/01 10:50:48| Accepting ICP messages at >0.0.0.0, port 3130, FD in your log. Do you really need cache digest?
Yes I noticed that, I have sinced disabled ICP and SNMP , but it did not resolve the utilization spikes.
I am monitoring squid with snmp/mrtg, it helps a lot when looking at perfomance issues.
Hmmm, have you tried if the problem persists with a 2.4.x-Kernel? I am a bit conservative when it comes to "new & improved" releases.
I am not familiar how dansguardian interacts with >squid, but if you had the same setup running fine on another distro, >probably the suse rpm is to blame. IMHO suse professional is a distro build for easy use >on workstations. I had some really funny experiences with suse pro... For >servers we have switched over to SLES or debian depending on the >purpose.
I originally wanted SLES, however, we really want Kernel 2.6 and the new version of SLES with 2.6 is not out currently.
>>Probably you should try to build your own squid from >source?
For testing I would use no SRPM, but the sources from http://www.squid-cache.org/ and
I was afraid of that.. too bad as I was hoping I woudln't have to package my own RPMS anymore. Thanks anyways oh and while I'm at it should I use diskd instead of UFS? Thanks for your help.
./configure --with-a-lot-of-funny-options
make
make install
If you decide to deploy this build into production you can build the RPM later on.
Recommendation by this list for linux is aufs as I learned a couple of day ago. Use reiserfs for the cache-partitions, but you may be using reiserfs already if you are on suse...
