Re: async-i/o for 2.4

Costas Tavernarakis wrote:

> What worries me, though, is that now i keep getting a lot of messages such
> as:
> 2000/11/10 15:58:33| aio_queue_request: WARNING - Queue congestion
> 2000/11/10 15:58:35| aio_queue_request: WARNING - Queue congestion
> in cache_log...

Defenitely explains the hang you saw then.. before the fix each use of
request_queue2 corrupted request_queue, and the above message never got
logged...

> It seems to me request_queue2 now gets used more than it should,
> even while the cache is not seeing production load yet! Maybe
> pthread_mutex_trylock failes due to too many active queue operations
> (or too many threads, as i have 10 independent cache_dirs).

Perhaps. Try reducing the number of threads. I have found the default to
be a definite overkill.

Also, the current code is perhaps a bit too keen on giving this message.
It is mostly a debug message, and has not been tuned to give any useful
feedback. It does not hurt performance very much when it happens, as
long as the lock is not blocked for very long (milliseconds), and this
message appears each and every time the lock was blocked when a async-io
request was made..

> Could we have multiple request queues, such as one per cache_dir,
> with separate sets of threads for each cache_dir, or something alike?

I plan to eventually do something like that, but mostly to get per
cache_dir response time measurements to tell when not to touch the
disk.. but it would also help scaling the locks..

I also plan on splitting the I/O request pools on swapin/swapout
requests to allow these to be given different priorities.

But before any of this I have to figure out why the over-all performance
quickly spirals down when supposedly the disk limit is reached... first
prio when I get back.

/Henrik
Received on Fri Nov 10 2000 - 10:34:29 MST