>>>>> "Vitaly" == Vitaly Oratovsky <vmo@stripped> writes:
>> On Mon, Dec 18, 2000 at 05:32:04PM +0200, Richard Ellerbrock wrote:
>> > I have an implementation question concerning user level async
>> > IO. Is MySQL capable of using user level async IO as defined
>> > by the POSIX standard? Reading the Redhat Oracle performance
>> > FAQ, this is hinted at. User level async IO is available in
>> > the RedHat Extended Edition Kernel (2.2.16). This kernel also
>> > supports Large File Support and Big memory.
>> No, MySQL doesn't use this API. Since MySQL is a multi-threaded
>> application, it's always doing many things at once anyway. If
>> you are having performance problems with MySQL, there's something
>> else going on (check the manual section on how to deal with table
>> locking to find some good things to try).
Vitaly> Hmmm ... I am confused by this answer (of course, I am easily confused
Vitaly> since I am a newbie to mysql, and I just started looking at mysql source
Vitaly> Examination of the mysql-3.23.30-gamma source code in mysys/mf_iocache.c
Vitaly> has provisions for using aioread/aiowrite/aiowait if HAVE_AIOWAIT is
Vitaly> #defined. Are you saying that I'm looking at dead code?
Yes; This is not enabled when you have threads.
Vitaly> BTW, in my opinion if you want to do asynchronous i/o, you really ought
Vitaly> to use aio APIs instead of multi-threading. I've spent a number of
Vitaly> years writing O/S kernels, and I'll make the observation that
Vitaly> multi-threading is not all that cheap. The cost of context switching,
Vitaly> even between threads rather than full blown processes, is non-trivial
Vitaly> (pipeline stalls, register context swaps, cache and TLB pollution, trip
Vitaly> thru the scheduler, etc.) This cost can be significantly reduced if the
Vitaly> underlying OS has efficient async i/o facilities. Not to mention the
Vitaly> fact that each thread needs its own stack, signal mask/queue, and a few
Vitaly> other ancilliary things ... it all adds up. And when your threads are
Vitaly> done performing async i/o they must block and later resume when you want
Vitaly> more async i/o (assuming you can't put them to better use). The act of
Vitaly> blocking and resuming is useless work. And of course, since they are
Vitaly> concurrent threads, you must use mutexes in all the right places.
Yes, we uses mutexes when needed. The problem is that in most cases
in MySQL ASYNC would not really help as the thread doesn't have
anything to do until it gets the data. Before we used ASYNC when
scanning tables but in practice we found out that the programs got
much more unstable when we used that because of bugs in ASYNC handling
in the operating systems. After loosing data a couple of times we
have tried to stay away from ASYNC.