On 5/26/06, Matus UHLAR - fantomas <uhlar@xxxxxxxxxxx> wrote:
is that on linux? try checking /proc/interrupts. Maybe reordering PCI cards would help a bit. Do you use 32 or 64bit architecture? iwith 32bit, you probably can't use more than one (or two?) GB of data segment per process, which may also cause some more load...
This is on a stable debian system. 32 bit architecture... but data segments _should_ be well within limits.
> >May be caused by the fact squid searches for valid cache_dir > > I'm starting to believe the same thing. Squid probably tries to find out which objects to purge from memory cache, and then it decides where to save them. Also, it has to purge some objects off ths disk, which results which in case of big memory and relatively small disk cache results into much CPU processing.
I've come to learn that this is a result of squid blocking for diskd. The queue for reading/writing is getting too large and squid slows down (by a _lot_) for diskd to keep up. All of those "no valid swapdirs for this object" messages are the result of the queue exceeding Q1 and squid blocking. I'm playing with the Q1 and Q2 values to see if I can fix this. So far I've had no luck though.
now, first I would try to decrease cache_mem to one half (51MB is still MUCH) and increase cache_dirs' sizes. --
I'll give this a try. The thing that bothers me about this is that I have other cache servers running squid 2 and they're able to make use of much more cache mem than this. -- Dan Thomson Systems Engineer Peer1 Network 1600 555 West Hastings Vancouver, BC V6B 4N5 866-683-7747 http://www.peer1.com
