<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                ## 綜述 在[前一篇](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操作。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看