Re: Squid 2.2 async-io.

David Luyer wrote:

> Well, we're running Linux 2.0/Squid 2.2 with async-io and I've had to increase
> NUM_THREADS to 128, and it even gives me warnings now due to backlogged deletes.
> However, even with NUM_THREADS at 16, it runs very well and the warnings are
> little more than something to try and stop being logged :-)

I am aware of this. It is caused by a change in Squid 2.2 rather than
Linux. Previously unlinks was kept on an separate queue, but due to
various problems with this (mainly priority problems which caused the
unlink queue to grow infinitely on high load without Squid knowing about
the fact) I selected to remove this queue.

I notice that one of my follow-up async-io patches which tries to
address part of this is missing from Squid 2.2:
1. Don't swap out anything if async-io is overloaded.
2. Block if the queues is heavily overloaded, instead of terminating
with a fatal error.
(this is squid-2.2.DEVEL3.asyncio_overload.patch)

> Of course not using async-io would be slow as you go back to the performance
> nightmare of 1.1.x which we liked so much we stuck with it to further the
> impact of delay pools on the students :-)

I have planned 2 future improvements:

1. Don't waste async-io on operations which usually does not block.
However, there seems to be some syncronisation problem somewhere because
each time I tries this it results in assertion errors... (or it could be
me being plain stupid when coding..)
2. Put unlinking under the same performance conditions as swapouts in
the patch mentioned above, to stop unlinks from overloading async-io.

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT