On Thu, 2003-01-02 at 16:02, Henrik Nordstrom wrote:
> Wait a minute.. yes, naturally. This will quite likely happen on an aufs
> Squid which has nothing to do as the I/O queue is only polled once per
> comm loop, and an "idle" comm loop runs at 100/s. The question is more
> why it does not always happen, and why it is 200KB/s and not 400KB/s.
> What can be said is also that the likelyhood that this won't happen
> decreases a lot on SMP machines as the main thread then have no
> copmetition with the I/O threads for the CPU.
I have a suggestion. If there are queued disk IO's, set the comm_timeout
lower than 100.
We current service store IO's, then do any queued comm callbacks. That
may result in more storeIO's being queued, so waiting for the comm
system becomes a performance limit.
Another possibility is to do a decaying average of the last -say 100-
comm_select call return times as a % of the timeout, and reduce the
handed timeout to that %. That will result in no reduction when
comm_select() times out, and will quickly reduce the timeout when it
does return within the timeout.
Cheers,
Rob
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:05 MST