Re: [squid-users] RE: Increased service times using aufs vs diskd

From: Adrian Chadd <adrian@dont-contact.us>
Date: Wed, 28 Jun 2006 09:17:26 +0800

On Tue, Jun 27, 2006, O'Brien, Kevin wrote:
> Yes, and thanks for understanding what I'm trying to find out.
>
> I did run bootstrap after applying the patch and I ran an strace on the
> process just to be sure that it's using epoll.
>
> My current working theory is that the service timers don't apply to the
> diskd process. So, when using diskd the IO portion of the service times
> is not accounted for. But that's just a theory...
>
> What still perplexes me is the increase in times as traffic decreases?
> Seems odd...

Its to do with the way squid handles checking for completed disk IO.
It checks for disk IO at the beginning of every run through the main
loop - and the main loop does have an implicit sleep if there's no
network traffic (ie, if poll/epoll/select/kqueue don't pick up any
changes to any filedescriptors.) Similarly - more network traffic
(especially with epoll) results in many more times through the event
loop - which means more chances to pick up completed disk IO.
There'll be a point where you're checking often enough for diminishing
returns to kick in (say, ~1000 times through the loop a second).

I'm sure there's going to be some other influence - have you told us
what "low traffic" is? Having some idea of throughput vs service
time would be helpful.

Check the average select loop time (in milliseconds) under the General
Information page. Here's mine, ignoring the wrapped 32 bit counter:

        Select loop called: -802084506 times, -3.637 ms avg

Adrian
Received on Tue Jun 27 2006 - 19:14:32 MDT

This archive was generated by hypermail pre-2.1.9 : Sat Jul 01 2006 - 12:00:02 MDT