一、安裝需要的命令：iostat
yum install -y sysstat
二、常用的命令：
1：一秒刷新一次，總共刷新10次(磁盤讀寫速度單位爲KB)
iostat -d -x -k 1 10
2：查看TPS和吞吐量信息(磁盤讀寫速度單位爲KB) 1秒刷新一次，共刷新10次
iostat -d -k 1 10
3：查看TPS和吞吐量信息(磁盤讀寫速度單位爲MB) 2秒刷新一次，一直刷
iostat -d -m 2
4：一秒刷新一次，總共刷新10次(磁盤讀寫速度單位爲KB)
iostat -d -x -k 1 10
三、命令使用詳解
這個值await>15,這個值%util接近100那就說明，磁盤現在是整個系統性能的瓶頸了
3.1：命令1
[root@xwah]# iostat -d -x -k 1 10
Linux 3.10.0-514.el7.x86_64 (xjq6-db) 05/08/2019 _x86_64_ (16 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.68 20.39 65.59 687.50 1865.75 10244.61 32.16 0.13 0.17 0.91 0.10 0.24 17.90
dm-0 0.00 0.00 66.63 412.82 1865.75 10244.59 50.52 0.06 0.12 0.93 0.62 0.37 17.93
dm-1 0.00 0.00 0.00 0.00 0.00 0.02 8.01 0.00 373.85 2.58 380.00 0.69 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 7.00 594.00 104.00 10061.00 33.83 0.38 0.63 0.57 0.63 0.12 7.30
dm-0 0.00 0.00 7.00 335.00 104.00 9997.00 59.07 0.38 1.12 0.57 1.13 0.22 7.40
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.00 732.00 36.00 10773.50 29.41 0.43 0.59 0.67 0.59 0.13 9.30
dm-0 0.00 0.00 3.00 395.00 36.00 10773.50 54.32 0.43 1.08 0.67 1.09 0.23 9.10
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 2.00 1061.00 8.00 16602.00 31.25 0.99 0.94 0.50 0.94 0.16 17.10
dm-0 0.00 0.00 2.00 580.00 8.00 16602.00 57.08 1.00 1.72 1.00 1.72 0.30 17.70
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 以上命令的詳解 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
查看主要參數：
avgqu-sz 數值越小越好
await 等待時間的數值<5,正常,數值>10偏高了
svctm svctm與await的值越接近越好，如果await減去svctm的值，值越大隊列時間越長，說明系統出了問題
%util 值越大，設備越繁忙，接近100%表示設備接近滿負荷運行了
r/s w/s 表示每秒讀的次數，寫的次數
avgqu-sz 值越小越好，該數值很重要
磁盤的 avgqu-sz數值很大；await數值很高；%util數值很高；都可能預示着磁盤存在瓶頸或者磁盤出現問題或者故障。
參數說明：
rrqm/s 每秒這個設備相關的讀取請求有多少被Merge了（當系統調用需要讀取數據的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合併Merge）
wrqm/s 每秒這個設備相關的寫入請求有多少被Merge了
r/s w/s 表示每秒讀的次數，寫的次數
rsec/s 每秒讀取的扇區數
wsec/ 每秒寫入的扇區數
rKB/s 每秒發送到設備的讀取請求數
wKB/s 每秒發送到設備的寫入請求數
avgrq-sz 平均請求扇區的大小
avgqu-sz 是平均請求隊列的長度。毫無疑問，隊列長度越短越好，該數值很重要
await 每一個IO請求的處理的平均時間（單位是微秒毫秒）,這裏可以理解爲IO的響應時間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了。
這個時間包括了隊列時間和服務時間，也就是說，一般情況下，await大於svctm，它們的差值越小，則說明隊列時間越短，反之差值越大，隊列時間越長，說明系統出了問題。
svctm 表示平均每次設備I/O操作的服務時間（以毫秒爲單位）,如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，如果await的值遠高於svctm的值，
則表示I/O隊列等待太長系統上運行的應用程序將變慢
%util 該參數暗示了設備的繁忙程度，一般地，如果該參數是100%表示設備已經接近滿負荷運行了
（當然如果是多磁盤，即使%util是100%，因爲磁盤的併發能力，所以磁盤使用未必就到了瓶頸）
await 每一個IO請求的處理的平均時間（單位是微秒毫秒）,這裏可以理解爲IO的響應時間，一般地系統IO響應時間應該低於5ms，如果大於10ms就比較大了
svctm 表示平均每次設備I/O操作的服務時間（以毫秒爲單位）,如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，
如果await的值遠高於svctm的值，則表示I/O隊列等待太長,系統上運行的應用程序將變慢
3.2；命令2
iostat -d -k 1 10 #查看TPS和吞吐量信息(磁盤讀寫速度單位爲KB) 1秒刷新一次，共刷新10次
iostat -d -m 2 #查看TPS和吞吐量信息(磁盤讀寫速度單位爲MB) 2秒刷新一次，一直刷
[root@xwah]# iostat -d -m 2
Linux 3.10.0-514.el7.x86_64 (xjq6-db) 05/08/2019 _x86_64_ (16 CPU)
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 753.10 1.82 10.00 29746804 163323047
dm-0 479.46 1.82 10.00 29746770 163322744
dm-1 0.00 0.00 0.00 5 300
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 1349.00 2.92 22.29 5 44
dm-0 1301.50 2.93 22.16 5 44
dm-1 0.00 0.00 0.00 0 0
命令輸出的詳解：
kB_read/s：每秒從設備（drive expressed）讀取的數據量
kB_wrtn/s：每秒向設備（drive expressed）寫入的數據量
kB_read： 讀取的總數據量
kB_wrtn： 寫入的總數量數據量
三、查看mysqld的IO：
iotop -k -u mysql (-k 表示KB，-u mysql表示顯示mysql用戶的所有進程的IO)
四、對於mysql的簡單優化
4.1：對db系統的調優，調節的IO調度算法（如果是SSD固態硬盤，選擇noop調度算法，如果是磁盤，那麼選擇deadline調度算法）
[root@xwah]# lsscsi
[1:0:0:0] disk ATA SanDisk SD8SBBU2 6000 /dev/sda
[root@xwah]# iostat -d -m 1 1 |awk '{print $1}' | grep -v Linux
Device:
sda
dm-0
dm-1
dm-2
1：調節磁盤調度算法
echo deadline > /sys/block/dm-0/queue/scheduler
echo deadline > /sys/block/dm-1/queue/scheduler
echo deadline > /sys/block/dm-2/queue/scheduler
2：在線調整InnoDB緩衝池大小 8G（5.7之前不能動態調整，要修改配置文件重啓mysql生效）
mysql> SET GLOBAL innodb_buffer_pool_size = 8589934592;
查看：
mysql> show variables like '%innodb_buffer_pool%';
3：在關係到磁盤IO的參數還有兩個，分別是：innodb_log_buffer_size和innodb_log_file_size
innodb_log_buffer_size
表示InnoDB寫入到磁盤上的日誌文件時使用的緩衝區的字節數，默認值爲8M。
一個大的日誌緩衝區允許大量的事務在提交之前不寫日誌到磁盤。
因此，如果你有很多事務的更新，插入或刪除很多操作，通過這個參數會大量的節省了磁盤I/O。
innodb_log_file_size 不能超過最高值512GB，通常來說32M~128M這樣的配置就可以了
表示在一個日誌組每個日誌文件的字節大小。
日誌文件的總大小（innodb_log_file_size* innodb_log_files_in_group）。
例如一對255 GB的日誌文件，已經接近了極限，不能超過它。默認值是48M。
比較合適的值的範圍是從1MB到1 / N個的緩衝池大小，其中N是該組中的日誌文件的數量。
該值越大，緩衝池中必要的檢查點刷新活動就會越少，節省磁盤I/O。但是越大的日誌文件，mysql的崩潰恢復就越慢
innodb_log_files_in_group = 3 控制事務日誌文件的個數，一般我們可以用２－３個日值組。默認爲兩個
4： 如果系統 讀>寫，可以設置innodb_read_io_threads值相對大點，反之也可以，設置成cpu核數就行，最大cpu核數*2
innodb_read_io_threads = 4
innodb_write_io_threads = 4
5：mysql內執行如下指令：
set global sync_binlog=500; 默認爲 0
當每進行500次事務提交之後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。
set global innodb_flush_log_at_trx_commit=2; 之前爲 1
默認值1代表每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬盤，這是很費時的。特別是使用電池供電緩存（Battery backed up cache）時。
設置爲2代表不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬盤，所以你一般不會丟失超過1-2秒的更新。
設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值設置爲2只會在整個操作系統宕機時纔可能丟數據。
注：重新開機後，該指令失效。可在服務啓動時，設置如上兩項
5.1參數sync_binlog和innodb_flush_log_at_trx_commit的詳解
寫入性能最好
innodb_flush_log_at_trx_commit=2
sync_binlog=1000
寫入性能一般
innodb_flush_log_at_trx_commit=1
sync_binlog=1000
寫入性能最差
innodb_flush_log_at_trx_commit=1
sync_binlog=1
5.2安全
1）當innodb_flush_log_at_trx_commit和sync_binlog 都爲 1 時是最安全的，但也是最慢的一種方式。在mysqld 服務崩潰或者服務器主機crash的情況下，
binary log 只有可能丟失最多一個語句或者一個事務。但是魚與熊掌不可兼得，雙11 會導致頻繁的io操作，因此該模式也是最慢的一種方式。
2）當innodb_flush_log_at_trx_commit設置爲0，該模式速度最快，但不太安全，mysqld進程的崩潰會導致上一秒鐘所有事務數據的丟失。
3）當innodb_flush_log_at_trx_commit設置爲2，該模式速度較快，也比0安全，只有在操作系統崩潰或者系統斷電的情況下，上一秒鐘所有事務數據纔可能丟失。
5.3磁盤IO無法滿足業務需求時（雙1適合數據安全性要求非常高）
推薦 innodb_flush_log_at_trx_commit=2 ，sync_binlog=N (N爲500 或1000 或者 > 1)
6：開啓並分析慢日誌：優化sql語句
cat /tmp/mysql-slow.log
SET timestamp=1548075938;
update xy_member_session set accessTime= 1548075935 where id=188444;
# User@Host: root[root] @ [192.168.134.102] Id: 1286945
# Query_time: 2.840616 Lock_time: 0.000074 Rows_sent: 0 Rows_examined: 1
執行時間 等待鎖的時間
7：mysql配置文件如下：
vim /etc/my.cnf
[mysqld] #此模塊下增加以下參數
innodb_log_buffer_size = 50M
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 8G #專門的db服務器使用內存的80%，不是專門的使用40%
innodb_read_io_threads = 16 #cpu的核數,均勻使用cpu
innodb_write_io_threads = 16 #cpu的核數,均勻使用cpu
sync_binlog = 10
innodb_log_files_in_group = 3
slow_query_log = ON #開啓慢日誌
slow_query_log_file = /tmp/mysql-slow.log #設置慢日誌的路徑和名稱
long_query_time = 2 #設置慢日誌的時間（超時2s的sql語句就記錄下來）
~~~~~~~~~~~~~~~~~~ 其他的優化 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1：讀寫分離進行磁盤IO優化
2：在前端加上memcache/redis緩存
3：選擇正確的文件系統也能提高磁盤的tps，mysql數據庫推薦使用XFS文件系統
~~~~~~~~~~~~~~ 系統配置和mysql配置優化的總結 ~~~~~~~~~~~~
1：調節磁盤調度算法
echo deadline > /sys/block/dm-0/queue/scheduler
echo deadline > /sys/block/dm-1/queue/scheduler
echo deadline > /sys/block/dm-2/queue/scheduler
2：mysql配置文件如下：
vim /etc/my.cnf
[mysqld] #此模塊下增加以下參數
innodb_log_buffer_size = 50M
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 8G #專門的db服務器使用內存的80%，不是專門的使用40%
innodb_read_io_threads = 16 #cpu的核數,均勻使用cpu
innodb_write_io_threads = 16 #cpu的核數,均勻使用cpu
sync_binlog = 10
innodb_log_files_in_group = 3
slow_query_log = ON #開啓慢日誌
slow_query_log_file = /tmp/mysql-slow.log #設置慢日誌的路徑和名稱
long_query_time = 2 #設置慢日誌的時間（超時2s的sql語句就記錄下來）
是在沒有辦法就，購買更好的服務器，把站點搬遷吧
