## 綜述 在[前一篇](http://mysql.taobao.org/monthly/2016/02/01/)我們介紹了InnoDB文件系統的物理結構，本篇我們繼續介紹InnoDB文件系統的IO接口和內存管理。 為了管理磁盤文件的讀寫操作，InnoDB設計了一套文件IO操作接口，提供了同步IO和異步IO兩種文件讀寫方式。針對異步IO，支持兩種方式：一種是Native AIO，這需要你在編譯階段加上LibAio的Dev包，另外一種是simulated aio模式，InnoDB早期實現了一套系統來模擬異步IO，但現在Native Aio已經很成熟了，并且Simulated Aio本身存在性能問題，建議生產環境開啟Native Aio模式。 對于數據讀操作，通常用戶線程觸發的數據塊請求讀是同步讀，如果開啟了數據預讀機制的話，預讀的數據塊則為異步讀，由后臺IO線程進行。其他后臺線程也會觸發數據讀操作，例如Purge線程在無效數據清理，會讀undo頁和數據頁；Master線程定期做ibuf merge也會讀入數據頁。崩潰恢復階段也可能觸發異步讀來加速recover的速度。 對于數據寫操作，InnoDB和大部分數據庫系統一樣，都是WAL模式，即先寫日志，延遲寫數據頁。事務日志的寫入通常在事務提交時觸發，后臺master線程也會每秒做一次redo fsync。數據頁則通常由后臺Page cleaner線程觸發。但當buffer pool空閑block不夠時，或者沒做checkpoint的lsn age太長時，也會驅動刷臟操作，這兩種場景由用戶線程來觸發。Percona Server據此做了優化來避免用戶線程參與。MySQL5.7也對應做了些不一樣的優化。 除了數據塊操作，還有物理文件級別的操作，例如truncate、drop table、rename table等DDL操作，InnoDB需要對這些操作進行協調，目前的解法是通過特殊的flag和計數器的方式來解決。 當文件讀入內存后，我們需要一種統一的方式來對數據進行管理，在啟動實例時，InnoDB會按照instance分區分配多個一大塊內存（在5.7里則是按照可配置的chunk size進行內存塊劃分），每個chunk又以UNIV_PAGE_SIZE為單位進行劃分。數據讀入內存時，會從buffer pool的free list中分配一個空閑block。所有的數據頁都存儲在一個LRU鏈表上，修改過的block被加到`flush_list`上，解壓的數據頁被放到unzip_LRU鏈表上。我們可以配置buffer pool為多個instance，以降低對鏈表的競爭開銷。 在關鍵的地方本文注明了代碼函數，建議讀者邊參考代碼邊閱讀本文，本文的代碼部分基于MySQL 5.7.11版本，不同的版本函數名或邏輯可能會有所不同。請讀者閱讀本文時盡量選擇該版本的代碼。 ## IO子系統 本小節我們介紹下磁盤文件與內存數據的中樞，即IO子系統。InnoDB對page的磁盤操作分為讀操作和寫操作。 對于讀操作，在將數據讀入磁盤前，總是為其先預先分配好一個block，然后再去磁盤讀取一個新的page，在使用這個page之前，還需要檢查是否有change buffer項，并根據change buffer進行數據變更。讀操作分為兩種場景：普通的讀page及預讀操作，前者為同步讀，后者為異步讀 數據寫操作也分為兩種，一種是batch write，一種是single page write。寫page默認受double write buffer保護，因此對double write buffer的寫磁盤為同步寫，而對數據文件的寫入為異步寫。 同步讀寫操作通常由用戶線程來完成，而異步讀寫操作則需要后臺線程的協同。 舉個簡單的例子，假設我們向磁盤批量寫數據，首先先寫到double write buffer，當dblwr滿了之后，一次性將dblwr中的數據同步刷到ibdata，在確保sync到dblwr后，再將這些page分別異步寫到各自的文件中。注意這時候dblwr依舊未被清空，新的寫Page請求會進入等待。當異步寫page完成后，io helper線程會調用`buf_flush_write_complete`，將寫入的Page從flush list上移除。當dblwr中的page完全寫完后，在函數`buf_dblwr_update`里將dblwr清空。這時候才允許新的寫請求進dblwr。 同樣的，對于異步寫操作，也需要IO Helper線程來檢查page是否完好、merge change buffer等一系列操作。 除了數據頁的寫入，還包括日志異步寫入線程、及ibuf后臺線程。 ### IO后臺線程 InnoDB的IO后臺線程主要包括如下幾類： * IO READ 線程：后臺讀線程，線程數目通過參數`innodb_read_io_threads`配置，主要處理INNODB 數據文件異步讀請求，任務隊列為`AIO::s_reads`，任務隊列包含slot數為線程數 * 256(linux 平臺)，也就是說，每個read線程最多可以pend 256個任務； * IO WRITE 線程：后臺寫線程數，線程數目通過參數`innodb_write_io_threads`配置。主要處理INNODB 數據文件異步寫請求，任務隊列為`AIO::s_writes`，任務隊列包含slot數為線程數 * 256(linux 平臺)，也就是說，每個read線程最多可以pend 256個任務； * LOG 線程：寫日志線程。只有在寫checkpoint信息時才會發出一次異步寫請求。任務隊列為`AIO::s_log`，共1個segment，包含256個slot； * IBUF 線程：負責讀入change buffer頁的后臺線程，任務隊列為`AIO::s_ibuf`，共1個segment，包含256個slot 所有的同步寫操作都是由用戶線程或其他后臺線程執行。上述IO線程只負責異步操作。 ### 發起IO請求 入口函數：`os_aio_func` 首先對于同步讀寫請求（`OS_AIO_SYNC`），發起請求的線程直接調用`os_file_read_func`?或者`os_file_write_func`?去讀寫文件，然后返回。 對于異步請求，用戶線程從對應操作類型的任務隊列（`AIO::select_slot_array`）中選取一個slot，將需要讀寫的信息存儲于其中（`AIO::reserve_slot`）: 1. 首先在任務隊列數組中選擇一個segment；這里根據偏移量來算segment，因此可以盡可能的將相鄰的讀寫請求放到一起，這有利于在IO層的合并操作 ~~~ local_seg = (offset >> (UNIV_PAGE_SIZE_SHIFT + 6)) % m_n_segments; ~~~ 2. 從該segment范圍內選擇一個空閑的slot，如果沒有則等待； 3. 將對應的文件讀寫請求信息賦值到slot中，例如寫入的目標文件，偏移量，數據等； 4. 如果這是一次IO寫入操作，且使用native aio時，如果表開啟了transparent compression，則對要寫入的數據頁先進行壓縮并punch hole；如果設置了表空間加密，再對數據頁進行加密； 對于Native AIO（使用linux自帶的LIBAIO庫），調用函數`AIO::linux_dispatch`，將IO請求分發給kernel層。 如果沒有開啟Native AIO，且沒有設置wakeup later 標記，則會去喚醒io線程（`AIO::wake_simulated_handler_thread`），這是早期libaio還不成熟時，InnoDB在內部模擬aio實現的邏輯。 Tips：編譯Native AIO需要安裝libaio-dev包，并打開選項`srv_use_native_aio`。 ### 處理異步AIO請求 IO線程入口函數為`io_handler_thread --> fil_aio_wait` 首先調用`os_aio_handler`來獲取請求： 1. 對于Native AIO，調用函數`os_aio_linux_handle`?獲取讀寫請求。IO線程會反復以500ms（`OS_AIO_REAP_TIMEOUT`）的超時時間通過io_getevents確認是否有任務已經完成了（`LinuxAIOHandler::collect()`），如果有讀寫任務完成，找到已完成任務的slot后，釋放對應的槽位； 2. 對于simulated aio，調用函數`os_aio_simulated_handler`?處理讀寫請求，這里相比NATIVE AIO要復雜很多； * 如果這是異步讀隊列，并且`os_aio_recommend_sleep_for_read_threads`被設置，則暫時不處理，而是等待一會，讓其他線程有機會將更過的IO請求發送過來。目前linear readhaed 會使用到該功能。這樣可以得到更好的IO合并效果(`SimulatedAIOHandler::check_pending`)； * 已經完成的slot需要及時被處理(`SimulatedAIOHandler::check_completed`，可能由上次的io合并操作完成)； * 如果有超過2秒未被調度的請求(`SimulatedAIOHandler::select_oldest`)，則優先選擇最老的slot，防止餓死，否則，找一個文件讀寫偏移量最小的位置的slot(`SimulatedAIOHandler::select()`)； * 沒有任何請求時進入等待狀態； * 當找到一個未完成的slot時，會嘗試merge相鄰的IO請求（`SimulatedAIOHandler::merge()`），并將對應的slot加入到`SimulatedAIOHandler::m_slots`數組中，最多不超過64個slot； * 然而在5.7版本里，合并操作已經被禁止了，全部改成了一個個slot進行讀寫，升級到5.7的用戶一定要注意這個改變，或者改為使用更好的Native AIO方式； * 完成io后，釋放slot; 并選擇第一個處理完的slot作為隨后優先完成的請求。 從上一步獲得完成IO的slot后，調用函數`fil_node_complete_io`， 遞減`node->n_pending`。對于文件寫操作，需要加入到`fil_system->unflushed_spaces`鏈表上，表示這個文件修改過了，后續需要被sync到磁盤。 如果設置為`O_DIRECT_NO_FSYNC`的文件IO模式，則數據文件無需加入到`fil_system_t::unflushed_spaces`鏈表上。通常我們即時使用`O_DIRECT`的方式操作文件，也需要做一次sync，來保證文件元數據的持久化，但在某些文件系統下則沒有這個必要，通常只要文件的大小這些關鍵元數據沒發生變化，可以省略一次fsync。 最后在IO完成后，調用`buf_page_io_complete`，做page corruption檢查、change buffer merge等操作；對于寫操作，需要從flush list上移除block并更新double write buffer；對于LRU FLUSH產生的寫操作，還會將其對應的block釋放到free list上； 對于日志文件操作，調用`log_io_complete`執行一次fil_flush，并更新內存內的checkpoint信息（`log_complete_checkpoint`）。 ### IO 并發控制 由于文件底層使用pwrite/pread來進行文件I/O，因此用戶線程對文件普通的并發I/O操作無需加鎖。但在windows平臺下，則需要加鎖進行讀寫。 對相同文件的IO操作通過大量的counter/flag來進行并發控制。 當文件處于擴展階段時（`fil_space_extend`），將`fil_node_t::being_extended`設置為true，避免產生并發Extent，或其他關閉文件或者rename操作等。 當正在刪除一個表時，會檢查是否有pending的操作（`fil_check_pending_operations`）。 1. 將`fil_space_t::stop_new_ops`設置為true； 2. 檢查是否有Pending的change buffer merge (`fil_space_t::n_pending_ops`)；有則等待； 3. 檢查是否有pending的IO（`fil_node_t::n_pending`） 或者pending的文件flush操作（`fil_node_t::n_pending_flushes`）；有則等待。 當truncate一張表時，和drop table類似，也會調用函數`fil_check_pending_operations`，檢查表上是否有pending的操作，并將`fil_space_t::is_being_truncated`設置為true。 當rename一張表時（`fil_rename_tablespace`），將文件的stop_ios標記設置為true，阻止其他線程所有的I/O操作。 當進行文件讀寫操作時，如果是異步讀操作，發現`stop_new_ops`或者被設置了但`is_being_truncated`未被設置，會返回報錯；但依然允許同步讀或異步寫操作(`fil_io`)。 當進行文件flush操作時，如果發現`fil_space_t::stop_new_ops`或者`fil_space_t::is_being_truncated`被設置了，則忽略該文件的flush操作 （`fil_flush_file_spaces`）。 ### 文件預讀 文件預讀是一項在SSD普及前普通磁盤上比較常見的技術，通過預讀的方式進行連續IO而非帶價高昂的隨機IO。InnoDB有兩種預讀方式：隨機預讀及線性預讀；Facebook另外還實現了一種邏輯預讀的方式。 隨機預讀 入口函數：`buf_read_ahead_random` 以64個Page為單位(這也是一個Extent的大小)，當前讀入的page no所在的64個pagno 區域[ (page_no/64)*64, (page_no/64) *64 + 64]，如果最近被訪問的Page數超過`BUF_READ_AHEAD_RANDOM_THRESHOLD`（通常值為13），則將其他Page也讀進內存。這里采取異步讀。 隨機預讀受參數`innodb_random_read_ahead`控制 線性預讀 入口函數：`buf_read_ahead_linear` 所謂線性預讀，就是在讀入一個新的page時，和隨機預讀類似的64個連續page范圍內，默認從低到高Page no，如果最近連續被訪問的page數超過`innodb_read_ahead_threshold`，則將該Extent之后的其他page也讀取進來。 邏輯預讀 由于表可能存在碎片空間，因此很可能對于諸如全表掃描這樣的場景，連續讀取的page并不是物理連續的，線性預讀不能解決這樣的問題，另外一次讀取一個Extent對于需要全表掃描的負載并不足夠。因此Facebook引入了邏輯預讀。 其大致思路為，掃描聚集索引，搜集葉子節點號，然后根據葉子節點的page no (可以從非葉子節點獲取)順序異步讀入一定量的page。 由于Innodb Aio一次只支持提交一個page讀請求，雖然Kernel層本身會做讀請求合并，但那顯然效率不夠高。他們對此做了修改，使INNODB可以支持一次提交（`io_submit`）多個aio請求。 入口函數：`row_search_for_mysql --> row_read_ahead_logical` 具體參閱[這篇博文](http://planet.mysql.com/entry/?id=516236) 或者webscalesql上的幾個commit： ~~~ git show 2d61329446a08f85c89a4119317ae85baacf2bbb // 合并多個AIO請求，對所有的預讀邏輯（上述三種）采用這種方式 git show 9f52bfd2222403f841fe5fcbedd1333f78a70a4b // 邏輯預讀的主要代碼邏輯 git show 64b68e07430b50f6bff5ed67374b336623db24b6 // 防止事務在多個表上讀取操作時預讀帶來的影響 ~~~ ### 日志填充寫入 由于現代磁盤通常的block size都是大于512字節的，例如一般是4096字節，為了避免 “read-on-write” 問題，在5.7版本里添加了一個參數`innodb_log_write_ahead_size`，你可以通過配置該參數，在寫入redo log時，將寫入區域配置到block size對齊的字節數。 在代碼里的實現，就是在寫入redo log 文件之前，為尾部字節填充0（參考函數`log_write_up_to`）。 Tips：所謂READ-ON-WRITE問題，就是當修改的字節不足一個block時，需要將整個block讀進內存，修改對應的位置，然后再寫進去；如果我們以block為單位來寫入的話，直接完整覆蓋寫入即可。 ## buffer pool 內存管理 InnoDB buffer pool從5.6到5.7版本發生了很大的變化。首先是分配方式上不同，其次實現了更好的刷臟效率。對buffer pool上的各個鏈表的管理也更加高效。 ### buffer pool初始化 在5.7之前的版本中，一個buffer pool instance擁有一個chunk，每個chunk的大小為buffer pool size / instance個數。 而到了5.7版本中，每個instance可能劃分成多個chunk，每個chunk的大小是可定義的，默認為127MB。因此一個buffer pool instance可能包含多個chunk內存塊。這么做的目的是為了實現在線調整buffer pool大小([WL#6117](http://dev.mysql.com/worklog/task/?id=6117))，buffer pool增加或減少必須以chunk為基本單位進行。 在5.7里有個問題值得關注，即buffer pool size會根據instances * chunk size向上對齊，舉個簡單的例子，假設你配置了64個instance, chunk size為默認128MB，就需要以8GB進行對齊，這意味著如果你配置了9GB的buffer pool，實際使用的會是16GB。所以盡量不要配置太多的buffer pool instance。 ### buffer pool 鏈表及管理對象 出于不同的目的，每個buffer pool instance上都維持了多個鏈表，可以根據space id及page no找到對應的instance(`buf_pool_get`)。 一些關鍵的結構對象及描述如下表所示： | name | desc | | --- | --- | | buf_pool_t::page_hash | page_hash用于存儲已經或正在讀入內存的page。根據快速查找。當不在page hash時，才會去嘗試從文件讀取 | | buf_pool_t::LRU | LRU上維持了所有從磁盤讀入的數據頁，該LRU上又在鏈表尾部開始大約3/8處將鏈表劃分為兩部分，新讀入的page被加入到這個位置；當我們設置了innodb_old_blocks_time，若兩次訪問page的時間超過該閥值，則將其挪動到LRU頭部；這就避免了類似一次性的全表掃描操作導致buffer pool污染 | | buf_pool_t::free | 存儲了當前空閑可分配的block | | buf_pool_t::flush_list | 存儲了被修改過的page，根據oldest_modification（即載入內存后第一次修改該page時的Redo LSN）排序 | | buf_pool_t::flush_rbt | 在崩潰恢復階段在flush list上建立的紅黑數，用于將apply redo后的page快速的插入到flush list上，以保證其有序 | | buf_pool_t::unzip_LRU | 壓縮表上解壓后的page被存儲到unzip_LRU。 buf_block_t::frame存儲解壓后的數據，buf_block_t::page->zip.data指向原始壓縮數據。 | | buf_pool_t::zip_free[BUF_BUDDY_SIZES_MAX] | 用于管理壓縮頁產生的空閑碎片page。壓縮頁占用的內存采用buddy allocator算法進行分配。 | ### buffer pool 并發控制 除了不同的用戶線程會并發操作buffer pool外，還有后臺線程也會對buffer pool進行操作。InnoDB通過讀寫鎖、buf fix計數、io fix標記來進行并發控制。 讀寫并發控制 通常當我們讀取到一個page時，會對其加block S鎖，并遞增`buf_page_t::buf_fix_count`，直到mtr commit時才會恢復。而如果讀page的目的是為了進行修改，則會加X鎖。 當一個page準備flush到磁盤時(`buf_flush_page`)，如果當前Page正在被訪問，其`buf_fix_count`不為0時，就忽略flush該page，以減少獲取block上SX Lock的昂貴代價。 并發讀控制 當多個線程請求相同的page時，如果page不在內存，是否可能引發對同一個page的文件IO ？答案是不會。 從函數`buf_page_init_for_read`我們可以看到，在準備讀入一個page前，會做如下工作： 1. 分配一個空閑block； 2. `buf_pool_mutex_enter`； 3. 持有page_hash x lock； 4. 檢查page_hash中是否已被讀入，如果是，表示另外一個線程已經完成了io，則忽略本次io請求，退出； 5. 持有`block->mutex`，對block進行初始化，并加入到page hash中； 6. 設置IO FIX為`BUF_IO_READ`； 7. 釋放hash lock； 8. 將block加入到LRU上； 9. 持有block s lock； 10. 完成IO后，釋放s lock； 當另外一個線程也想請求相同page時，首先如果看到page hash中已經有對應的block了，說明page已經或正在被讀入buffer pool，如果`io_fix`為`BUF_IO_READ`，說明正在進行IO，就通過加X鎖的方式做一次sync（`buf_wait_for_read`），確保IO完成。 請求Page通常還需要加S或X鎖，而IO期間也是持有block x鎖的，如果成功獲取了鎖，說明IO肯定完成了。 ### Page驅逐及刷臟 當buffer pool中的free list不足時，為了獲取一個空閑block，通常會觸發page驅逐操作(`buf_LRU_free_from_unzip_LRU_list`)。 首先由于壓縮頁在內存中可能存在兩份拷貝：壓縮頁和解壓頁；InnoDB根據最近的IO情況和數據解壓技術來判定實例是處于IO-BOUND還是CPU-BOUND（`buf_LRU_evict_from_unzip_LRU`）。如果是IO-BOUND的話，就嘗試從unzip_lru上釋放一個block出來(`buf_LRU_free_from_unzip_LRU_list`)，而壓縮頁依舊保存在內存中。 其次再考慮從`buf_pool_t::LRU`鏈表上釋放block，如果有可替換的page(`buf_flush_ready_for_replace`)時，則將其釋放掉，并加入到free list上；對于壓縮表，壓縮頁和解壓頁在這里都會被同時驅逐。 當無法從LRU上獲得一個可替換的Page時，說明當前Buffer pool可能存在大量臟頁，這時候會觸發single page flush(`buf_flush_single_page_from_LRU`)，即用戶線程主動去刷一個臟頁并替換掉。這是個慢操作，尤其是如果并發很高的時候，可能觀察到系統的性能急劇下降。在RDS MySQL中，我們開啟了一個后臺線程， 能夠自動根據當前Free List的長度來主動做flush，避免用戶線程陷入其中。 除了single page flush外，在MySQL 5.7版本里還引入了多個page cleaner線程，根據一定的啟發式算法，可以定期且高效的的做page flush操作。