On 14/03/2014 4:34 p.m., csn233 wrote:
> Testing delay_pools on 3.3.11 (and other versions too)
>
> delay_pools 1
> delay_class 1 3
> delay_parameters 1 -1/-1 -1/-1 128000/256000
> delay_access 1 allow all
>
> This works as expected. However, when requests goes a bit higher, say
>> 20 req/s, the CPU shoots up to 100%, and strace shows epoll calls:
>
> epoll_ctl(6, EPOLL_CTL_MOD, 7251, {EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP,
> {u32=7251, u64=15832364667084217427}}) = 0
> epoll_ctl(6, EPOLL_CTL_MOD, 8068, {EPOLLIN|EPOLLOUT|EPOLLERR|EPOLLHUP,
> {u32=8068, u64=14612651267063816068}}) = 0
> epoll_wait(6, {{EPOLLOUT, {u32=46, u64=3639753988997382190}},
> {EPOLLOUT, {u32=7111, u64=16029163435841297351}}, {EPOLLOUT,.. [snip]
>
> Is this "normal"?
Maybe yes, maybe no.
It is normal to see that type of fast looping when there is a lot of
incoming connections or TCP buffers constantly providing new bytes for
handling.
It may be expected when the delay pool slows down reading out of TCP
buffers and causes traffic to become backlogged.
However, I think sockets hitting the delay limits should be omitted from
the polling until they had more bytes allowed. So this may be a bug in
the mechanism doing that.
>
> Next, I also tried client_delay_pools (3.3.11/3.4.3)
>
> client_delay_pools 1
> client_delay_access 1 allow all
> client_delay_parameters 1 128000 256000
>
> This gets "connection reset" straightaway. What am I missing?
>
Information about what the connection reset is coming from?
Is squid crashing? http://bugs.squid-cache.org/show_bug.cgi?id=3696
Amos
