【mysql】關於IO/內存方面的一些優化

時間 2019-11-30

標籤 mysql 關於內存方面一些優化欄目 MySQL 简体版

原文原文鏈接

這裏使用的是mysql Ver 14.14 Distrib 5.6.19, for Linux (i686) using EditLine wrapperhtml

1、mysql目錄文件

ibdata1:系統表空間包含數據字典、回滾日誌/undolog等mysql

（insert buffer segment/double write segment/rollback segment/index segment/dictionary segment/undo segment）sql

ib_logfile0/ib_logfile1：事務日誌/redolog數據庫

mysql-relay-bin：中繼日誌安全

binarylog：二進制日誌bash

general_log.log：常規日誌服務器

mysql_error.log：錯誤日誌網絡

slow_query.log：慢日誌併發

.ibd：用戶表空間-數據文件（insert buffer bitmap page/leaf page segment/none leaf page segment）app

Innodb buffer pool（內存）：undo page /insert buffer page/adaptive hash index/index page/lock info/data dictionary

2、mysql線程

FILE IO

--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
393 OS file reads, 5 OS file writes, 5 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s

innodb後臺全部線程

| thread/sql/main                        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/io_handler_thread        | BACKGROUND | YES          |
| thread/innodb/srv_master_thread        | BACKGROUND | YES          |
| thread/innodb/srv_purge_thread         | BACKGROUND | YES          |
| thread/innodb/srv_monitor_thread       | BACKGROUND | YES          |
| thread/innodb/srv_error_monitor_thread | BACKGROUND | YES          |
| thread/innodb/srv_lock_timeout_thread  | BACKGROUND | YES          |
| thread/innodb/page_cleaner_thread      | BACKGROUND | YES          |
| thread/sql/signal_handler              | BACKGROUND | YES          |
| thread/sql/slave_sql                   | BACKGROUND | YES          |
| thread/sql/slave_io                    | BACKGROUND | YES          |

IO線程分別是insert buffer thread、log thread、read thread、write thread。

在MySQL 5.6.10以後，默認線程處理模型使用執行每一個客戶端鏈接一個線程語句。隨着愈來愈多的客戶端鏈接到服務器和執行語句，總體性能下降。線程池插件的提供旨在減小開銷，提升性能的其餘線程的處理模式。該插件實現了經過有效地管理語句執行線程的大量客戶端鏈接的提升服務器性能的線程池。

InnoDB Plugin版本開始增長了默認IO thread的數量，默認的read thread和write thread分別增大到了4個，而且再也不使用innodb_file_io_threads參數，而是分別使用innodb_read_io_threads和innodb_write_io_threads參數。

線程池解決每一個鏈接模型解決單線程的幾個問題

Too many thread stacks make CPU caches almost useless in highly parallel execution workloads. The thread pool promotes thread stack reuse to minimize the CPU cache footprint.
With too many threads executing in parallel, context switching overhead is high. This also presents a challenging task to the operating system scheduler. The thread pool controls the number of active threads to keep the parallelism within the MySQL server at a level that it can handle and that is appropriate for the server host on which MySQL is executing.
Too many transactions executing in parallel increases resource contention. In InnoDB, this increases the time spent holding central mutexes. The thread pool controls when transactions start to ensure that not too many execute in parallel.

3、mysql訪問文件流程

Transaction 來自網絡

3、影響IO/內存的一些參數

`一、innodb_flush_log_at_trx_commit 設置爲2`

這參數是指事務log（ib_logfile0、ib_logfile1）以怎樣的方式寫入到log buffer

=0 mysql crash 就丟失了，性能最好

buffer pool -> log buffer 每秒 wirte os cache & flush磁盤

=1 不會丟失，效率低

buffer pool -> log buffer 每次 write os cache & flush磁盤

=2 即便mysql崩潰也不會丟數據

buffer pool -> os cache 每秒flush 磁盤

注意：因爲進程調度策略問題,這個「每秒執行一次 flush(刷到磁盤)操做」並非保證100%的「每秒

二、sync_binlog

二進制日誌（binary log）同步到磁盤的頻率。binary log 每寫入 sync_binlog 次後，刷寫到磁盤。

若是 autocommit 開啓，每一個語句都寫一次 binary log，不然每次事務寫一次。

默認值是 0，不主動同步，而依賴操做系統自己不按期把文件內容 flush 到磁盤

設爲 1 最安全，在每一個語句或事務後同步一次 binary log，即便在崩潰時也最多丟失一個語句或事務的日誌，但所以也最慢。

大多數狀況下，對數據的一致性並無很嚴格的要求，因此並不會把 sync_binlog 配置成 1，爲了追求高併發，提高性能，能夠設置爲 100 或直接用 0

三、write/read thread

異步IO線程數

innodb_write_io_threads=16
innodb_read_io_threads=16

(該參數須要在配置文件中添加，重啓mysql實例起效)髒頁寫的線程數，加大該參數能夠提高寫入性能

`四、innodb_max_dirty_pages_pct`

最大髒頁百分數，當系統中髒頁所佔百分比超過這個值，INNODB就會進行寫操做以把頁中的已更新數據寫入到磁盤文件中。默認75，通常如今流行的SSD硬盤很難達到這個比例。可依據實際狀況在75-80之間調節

`五、innodb_io_capacity=5000`

從緩衝區刷新髒頁時，一次刷新髒頁的數量。根據磁盤IOPS的能力通常建議設置以下：

SAS 200
SSD 5000
PCI-E 10000-50000

`六、innodb_flush_method=O_DIRECT(該參數須要重啓mysql實例起效)`

控制innodb 數據文件和redo log的打開、刷寫模式。有三個值：fdatasync(默認)，O_DSYNC，O_DIRECT。

fdatasync模式：寫數據時，write這一步並不須要真正寫到磁盤纔算完成（可能寫入到操做系統buffer中就會返回完成），真正完成是flush操做，buffer交給操做系統去flush,而且文件的元數據信息也都須要更新到磁盤。
O_DSYNC模式：寫日誌操做是在write這步完成，而數據文件的寫入是在flush這步經過fsync完成。
O_DIRECT模式：數據文件的寫入操做是直接從mysql innodb buffer到磁盤的，並不用經過操做系統的緩衝，而真正的完成也是在flush這步,日誌仍是要通過OS緩衝。

經過圖能夠看出O_DIRECT相比fdatasync的優勢是避免了雙緩衝，自己innodb buffer pool就是一個緩衝區，不須要再寫入到系統的buffer，可是有個缺點是因爲是直接寫入到磁盤，因此相比fdatasync的順序讀寫的效率要低些。

在大量隨機寫的環境中O_DIRECT要比fdatasync效率更高些，順序寫多的話，仍是默認的fdatasync更高效。

`七、innodb_adaptive_flushing 設置爲 ON （使刷新髒頁更智能）`

影響每秒刷新髒頁的數目

規則由原來的「大於innodb_max_dirty_pages_pct時刷新100個髒頁到磁盤」變爲「經過buf_flush_get_desired_flush_reate函數判斷重作日誌產生速度肯定須要刷新髒頁的最合適數目」，即便髒頁比例小於 innodb_max_dirty_pages_pct時也會刷新必定量的髒頁。

`八、innodb_adaptive_flushing_method 設置爲 keep_average`

影響checkpoint，更平均的計算調整刷髒頁的速度，進行必要的flush.（該變量爲mysql衍生版本Percona Server下的一個變量，原生mysql不存在）

`九、innodb_stats_on_metadata=OFF`

關掉一些訪問information_schema庫下表而產生的索引統計。

當重啓mysql實例後，mysql會隨機的io取數據遍歷全部的表來取樣來統計數據，這個實際使用中用的很少，建議關閉.

`十、innodb_change_buffering=all`

當更新/插入的非彙集索引的數據所對應的頁不在內存中時（對非彙集索引的更新操做一般會帶來隨機IO），會將其放到一個insert buffer中，當隨後頁面被讀到內存中時，會將這些變化的記錄merge到頁中。當服務器比較空閒時，後臺線程也會作merge操做。

因爲主要用到merge的優點來下降io，但對於一些場景並不會對固定的數據進行屢次修改，此處則並不須要把更新/插入操做開啓change_buffering，若是開啓只是多餘佔用了buffer_pool的空間和處理能力。這個參數要依據實際業務環境來配置。

`十一、innodb_old_blocks_time=1000`

使Block在old sublist中停留時間長爲1s，不會被轉移到new sublist中,避免了Buffer Pool被污染BP能夠被認爲是一條長鏈表。被分紅young 和 old兩個部分，其中old默認佔37%的大小（由innodb_old_blocks_pct 配置）。靠近頂端的Page表示最近被訪問。靠近尾端的Page表示長時間未被訪問。而這兩個部分的交匯處成爲midpoint。每當有新的Page須要加載到BP時，該page都會被插入到midpoint的位置，並聲明爲old-page。當old部分的page，被訪問到時，該page會被提高到鏈表的頂端，標識爲young。

因爲table scan的操做是先load page，而後當即觸發一次訪問。因此當innodb_old_blocks_time =0 時，會致使table scan所須要的page不讀的做爲young page被添加到鏈表頂端。而一些使用較爲不頻繁的page就會被擠出BP，使得以後的SQL會產生磁盤IO，從而致使響應速度變慢。

這時雖然mysqldump訪問的page會不斷加載在LRU頂端，可是高頻度的熱點數據訪問會以更快的速度把page再次搶佔到LRU頂端。從而致使mysqldump加載入的page會被迅速刷下，並當即被evict（淘汰）。所以，time=0或1000對這種壓力環境下的訪問不會形成很大影響，由於dump的數據根本搶佔不過熱點數據。不僅dump，當大數據操做的時候也是如此。

十二、binlog_cache_size

二進制日誌緩衝大小：一個事務，在沒有提交（uncommitted）的時候，產生的日誌，記錄到Cache中；等到事務提交（committed）須要提交的時候，則把日誌持久化到磁盤。

設置太大的話，會比較消耗內存資源（Cache本質就是內存），更加須要注意的是：binlog_cache是否是全局的，是按SESSION爲單位獨享分配的，也就是說當一個線程開始一個事務的時候，Mysql就會爲這個SESSION分配一個binlog_cache

怎麼判斷咱們當前的binlog_cache_size設置的沒問題呢？

mysql> show status like 'binlog_%';                       
+-----------------------+-----------+
| Variable_name         | Value     |
+-----------------------+-----------+
| Binlog_cache_disk_use | 1425      |
| Binlog_cache_use      | 126945718 |
+-----------------------+-----------+
2 rows in set (0.00 sec)

mysql> select @@binlog_cache_size;                        
+---------------------+
| @@binlog_cache_size |
+---------------------+
|             1048576 |
+---------------------+
1 row in set (0.00 sec)

運行狀況Binlog_cache_use 表示binlog_cache內存方式被用上了多少次，Binlog_cache_disk_use表示binlog_cache臨時文件方式被用上了多少次

1三、innodb_file_per_table

innodb_file_per_table=1

獨立表空間

優勢：

每一個表的數據和索引都會存在自已的表空間中
能夠實現單表在不一樣的數據庫中移動
空間能夠回收（除drop table操做）
刪除大量數據後能夠經過:alter table TableName engine=innodb;回縮不用的空間
使用turncate table也會使空間收縮
對於使用獨立表空間的表，無論怎麼刪除，表空間的碎片不會太嚴重的影響性能

缺點：單表增長過大，如超過100個G

結論：共享表空間在Insert操做上少有優點。其它都沒獨立表空間表現好。當啓用獨立表空間時，請合理調整一下：innodb_open_files ，InnoDB Hot Backup（冷備）的表空間cp不會面對不少無用的copy了。並且利用innodb hot backup及表空間的管理命令能夠實現單現移動。