On 5/26/06, Matus UHLAR - fantomas <uhlar@fantomas.sk> 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.comReceived on Fri May 26 2006 - 11:47:37 MDT
This archive was generated by hypermail pre-2.1.9 : Thu Jun 01 2006 - 12:00:02 MDT