mirror of
https://github.com/MariaDB/server.git
synced 2026-10-23 18:49:29 +03:00
1bb1738271
The traditional linear read-ahead, enabled by innodb_read_ahead_threshold, only helps when consecutively accessed pages have adjacent page numbers. That is rarely true for B-tree leaf pages: after splits, merges and page reuse, the logical order of leaves has nothing to do with their physical page numbers. So for a scan of scattered leaves the old read-ahead either did nothing or read the wrong pages. This replaces linear read-ahead of index pages with a logical read-ahead that prefetches the actual leaf pages a scan is going to visit, discovered from the B-tree during traversal. After this change, the exact nonzero value of innodb_read_ahead_threshold matters only for the read-ahead of undo log pages. buf_read_ahead_undo(): Renamed from buf_read_ahead_linear(). Now invoked only for undo log pages, whose page numbers are sequential. It is no longer called on BLOB pages or index pages. buf_read_ahead_one(): Read ahead a single leaf page. buf_read_ahead_pages(): Read ahead a set of known B-tree leaf pages. Stops at the first page that is already resident or fails. buf_read_ahead_random(): Split into a decision part(which extent to read) and action part (issue the reads) The pending read throttle now compares the os_aio_pending_reads_approx() with buf_pool.curr_size() instead of current pool bytes, which had made the throttle a no-op. buf_read_ahead_pages() releases the tablespace reference on a failed/corrupted page. btr_ra_latch: A caller-owned buffer of leaf page numbers, which also records the level-1 page and the child page number of the last node pointer collected, so read-ahead can be resumed later. btr_ra_collect(): Scan the node pointers of PAGE_LEVEL=1 page from the given record in scan order, appending child page numbers btr_cur_t::search_leaf(), btr_cur_t::open_leaf(): At PAGE_LEVEL=1, after the descent has located the child to follow, harvest leaf page numbers starting at that child in the scan direction. These are exactly the leaves the cursor will visit, so prefetch is precise regardless of physical page numbers. btr_ra_resume_rec(): Locate the record from which read-ahead should resume, by re-finding the last harvested child by value. It walks only genuine records, so a concurrent page reorganization cannot cause an invalid read btr_pcur_move_to_next_page(): Prefetch the sibling after the one being entered, with buf_read_ahead_one(). btr_pcur_move_backward_from_page(): Add a no-wait fast path that latches the previous page if it is resident (validating it against the current page), and prefetch the one before it. btr_copy_blob_prefix(): Simplified; no longer relies on FIL_PAGE_PREV/NEXT, which are not initialized on BLOB pages. records_in_range() reports the first and last leaf page of a range, and the optimizer forwards that extent to the engine through handler::advise_page_range(). multi_range_read_info_const() takes a page_range parameter; the default MRR implementation aggregates the per-range extents, and opt_range.cc carries the result through the chosen QUICK_RANGE_SELECT, whose reset() calls advise_page_range() before multi_range_read_init(). The extent only sizes and bounds read-ahead; it never gates the pages the scan actually reads. The LIMIT is converted in multi_range_read_info_const() to a leaf count (m_ra_limit_pages). mrr_readahead_from_scan_range() derives the read-ahead ceiling from the advised extent, falling back to that LIMIT-based estimate. The ceiling is capped by init_readahead_window() at 1/256 of the buffer pool (but at least 4 pages), because every prefetched page occupies a buffer pool frame as soon as its read is issued. The window ramps up: a positioning read harvests at most 4 leaves and resets the window to 4, and readahead_refill() doubles it toward the ceiling. Single-row probes such as index_first() for MIN()/MAX(), and every range of a multi-range read, therefore prefetch only a few leaves while long scans reach full depth. search_with_readahead(): Position the cursor while collecting the leaf pages, then call start_readahead(). It is used by index_read() and by the first general_fetch() only when read-ahead is armed, so the other paths carry no read-ahead locals. start_readahead(): For a just-positioned scan, prefetch the collected batch and set up the rolling cursor. readahead_refill(): As the scan advances (general_fetch()), resume the level-1 harvest under an index S-latch, chain across level-1 siblings, and prefetch the next batch bounded by the advised last leaf, or to the end of the index when the extent is unknown. The reads are issued after the latches are released. Read-ahead is started from index_read() (range and full index scans), rnd_init()/general_fetch() (full table scans), and, at one-page depth, from row_merge_read_clustered_index() (OPTIMIZE/ALTER rebuild). general_fetch() sets active_handler_stats before issuing read-ahead so prefetched pages are attributed to the query. dict_stats_analyze_index_for_n_prefix(): Choose the records to dive below first, prefetch their child pages in one batch with buf_read_ahead_pages(), and then dive below the same records. Undo/system tablespace shrinking holds fil_space_t::latch exclusively (x_lock_space()), and buf_read_ahead_undo() holds it shared, via the new fil_space_t::s_lock_try() that never waits, while it checks the size and issues the reads. If the latch is not available, the read-ahead is skipped. trx_undo_get_prev_rec(), trx_undo_get_prev_rec_from_prev_page(): take the trx_undo_t object instead of a long parameter list and always latch shared.
This directory contains test suites for the MariaDB server. To run currently existing test cases, execute ./mysql-test-run in this directory. Some tests are known to fail on some platforms or be otherwise unreliable. In the file collections/smoke_test there is a list of tests that are expected to be stable. In general you do not have to do "make install", and you can have a co-existing MariaDB installation, the tests will not conflict with it. To run the tests in a source directory, you must do "make" first. In Red Hat distributions, you should run the script as user "mysql". The user is created with nologin shell, so the best bet is something like # su - # cd /usr/share/mariadb-test # su -s /bin/bash mysql -c ./mysql-test-run This will use the installed MariaDB executables, but will run a private copy of the server process (using data files within /usr/share/mariadb-test), so you need not start the mysqld service beforehand. You can omit --skip-test-list option if you want to check whether the listed failures occur for you. To clean up afterwards, remove the created "var" subdirectory, e.g. # su -s /bin/bash - mysql -c "rm -rf /usr/share/mariadb-test/var" If tests fail on your system, please read the following manual section for instructions on how to report the problem: https://mariadb.com/docs/general-resources/community/community/bug-tracking/reporting-bugs If you want to use an already running MySQL server for specific tests, use the --extern option to mysql-test-run. Please note that in this mode, you are expected to provide names of the tests to run. For example, here is the command to run the "alias" and "analyze" tests with an external server: # mariadb-test-run --extern socket=/tmp/mysql.sock alias analyze To match your setup, you might need to provide other relevant options. With no test names on the command line, mysql-test-run will attempt to execute the default set of tests, which will certainly fail, because many tests cannot run with an external server (they need to control the options with which the server is started, restart the server during execution, etc.) You can create your own test cases. To create a test case, create a new file in the main subdirectory using a text editor. The file should have a .test extension. For example: # xemacs t/test_case_name.test In the file, put a set of SQL statements that create some tables, load test data, and run some queries to manipulate it. Your test should begin by dropping the tables you are going to create and end by dropping them again. This ensures that you can run the test over and over again. If you are using mysqltest commands in your test case, you should create the result file as follows: # mariadb-test-run --record test_case_name or # mariadb-test --record < t/test_case_name.test If you only have a simple test case consisting of SQL statements and comments, you can create the result file in one of the following ways: # mariadb-test-run --record test_case_name # mariadb test < t/test_case_name.test > r/test_case_name.result # mariadb-test --record --database test --result-file=r/test_case_name.result < t/test_case_name.test When this is done, take a look at r/test_case_name.result. If the result is incorrect, you have found a bug. In this case, you should edit the test result to the correct results so that we can verify that the bug is corrected in future releases. If you want to submit your test case you can send it to developers@lists.mariadb.org or attach it to a bug report on http://mariadb.org/jira/. If the test case is really big or if it contains 'not public' data, then put your .test file and .result file(s) into a tar.gz archive, add a README that explains the problem, ftp the archive to ftp://ftp.mariadb.org/private and submit a report to https://mariadb.org/jira about it. The latest information about mysql-test-run can be found at: https://mariadb.com/docs/server/clients-and-utilities/testing-tools/mariadb-test If you want to create .rdiff files, check https://mariadb.com/docs/server/clients-and-utilities/testing-tools/mariadb-test/mariadb-test-auxiliary-files