This relates to the number of simultaneous requests squid is handling
-- I'm assuming you are using AUFS.
Basically, the IO threads are not processing "fast enough" and the io
request queue is getting long. "Fast enough" is a metric defined by
squid (it's in store_dir.c file I think, and there isn't much
commentary on where the heuristics originate from).
You can potentially alleviate this by increasing the number of IO
threads at compile time - but it depends on how much disk activity
you are seeing. A quick look at iostat (or sar data) correlated to
the queue congestion messages should be enough to tell.
If the disks aren't saturated, I'd say you could increase the number
of threads to at least 48 (depending on hardware), but that's not
much more than the 36 you seem to have already. I don't know the
maximum number of threads you can really throw at the problem, but
you can obviously experiment.
If your disks are overloaded, there won't be much you can do (aside
from adding more spindles, or more RAM). File system and kernel io
tuning may yield small gains, but it won't solve the core problem.
-Mike
On Mar 24, 2006, at 12:47 PM, pak kumis wrote:
> hi,
>
> i got this message in my log.
>
> squidaio_queue_request: WARNING - Queue congestion
>
> my sistem use 4 hdd sata for the cache directory.
>
> when i type pstree i found my squid proses
>
> |-squid---squid-+-squid---36*[squid]
> | |-24*[squid_redirect]
> | `-unlinkd
>
Received on Sat Mar 25 2006 - 22:34:46 MST
This archive was generated by hypermail pre-2.1.9 : Sat Apr 01 2006 - 12:00:04 MST