Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
Description:
|
------------
|
The InnoDB engine support native AIO and simulated AIO on linux platform.
|
Native AIO use io_submit that glibc supplied to request IO.
|
But InnoDB engine requested AIO one by one through io_submit when trigger read-ahead,
|
so it is a little inefficiency.
|
|
Solution:
|
---------
|
We buffered the AIO requests, then io_submit all.
|
For example: when linear-ahead. we buffered next 64 pages io requests,
|
at last, io_submit all io requests.
|
https://github.com/alibaba/AliSQL/commit/4c9d1c72b9db5f7d2267906e0fa6d66948f5dc6c
Attachments
Issue Links
- relates to
-
MDEV-26547 Restoring InnoDB buffer pool dump is single-threaded for no reason
-
- Closed
-
-
MDEV-30986 Slow full index scan in 10.6 vs 10.5 for the (slow) I/O-bound case
-
- Closed
-
-
MDEV-32067 InnoDB linear read ahead had better be logical
-
- Confirmed
-
-
MDEV-16526 Overhaul the InnoDB page flushing
-
- Closed
-
-
MDEV-31095 Create separate tpool thread for async aio
-
- Closed
-
-
MDEV-31492 Provide a way to "pin" InnoDB table in memory
-
- Open
-
I wonder whether combining requests would make any sense at all with modern storage devices, which should have deep work queues and could combine requests at the low level by themselves. I do not know it, but I could believe that even on HDD a native command queue could implement the ‘elevator algorithm’ for optimizing the head movements.
One reason against combining read requests would seem to be that if we completed the reads of multiple pages at once, then we would be validating page checksums within only one execution thread. If we received read completion callbacks for each individual page, then multiple checksums could be calculated in parallel and we could utilize the I/O capacity better. It still was nowhere near the maximum capacity of a fast NVMe when I tested
MDEV-26547.