Hard disk test

I. Introduction disk scheduling algorithm

View disk scheduling algorithm used
[root @ localhost ~] # CAT / SYS / Block / sda / Queue / Scheduler
NOOP [DEADLINE] the CFQ

1.CFQ
　　the CFQ the I / O request corresponding to the process according to the process were placed in the queue, the process A and the process B issued I / O requests in the two queues. The merger is still used various internal queue and sorting methods differ only in the process of submitting each I / O request has its own I / O queue.

　　CFQ "fair" is for the purposes of the process, it is time-sliced arithmetic premise, round-robin scheduling queue, the default fetch request processing from the four currently in the queue, then process the next four request queues. This ensures that each process enjoyed by the I / O resources are balanced.

　　The disadvantage is the first to CFQ IO requests may not be in time to meet the hunger situation may arise.

　　WKI CFQ

2.Deadline
　　with CFQ, except to maintain a merger has a request queue and sorting capabilities, it also maintains two additional queues, queues are read requests and write requests queue, they are with a timeout FIFO queue. When a new I / O request, will be inserted into a normal queue and simultaneously read / write queue, then normal processing request queue. When the dispatcher finds a read / write requests in the request queue timeout time, will give priority to these requests, to ensure that no request hunger as much as possible

　　in Deadline algorithm, each I / O request has a timeout, the default is a read request 500ms, write request is 5s.

　　Wiki DEADLINE

3.Noop
　　Noop to do is very simple, it is not the sort of request I / O will not make any other optimizations (except consolidation). Noop request other than the combined addition, no longer any treatment, in the order of FIFO-like submit I / O requests directly.

　　Noop is not an ordinary block-oriented device, but random access devices (such as SSD), for such a device, the conventional seek time does not exist, so long it is not necessary to do those extra things in order to reduce seek time taken the

　　Noop Wiki
understanding ====================== ===================== ginger teacher ===
the CFQ some requests in accordance with the order of the comparison access, there may be some delay is relatively large for other requests.

NOOP not be sorted, the order is sent, in what order, to ask for the order. More in line with the characteristics of the SSD. Because SSD randomness is good enough no need to be sorted. Once the operation there will be some sort of competition, the emergence of hunger.

Deadline improve the CFQ, is placed in the respective read and write access request queue, depending on the comparison of the request in order to be sorted, a read request is higher priority than the write request.

Deadline NOOP and can be selected, CFQ is definitely impossible. CFQ higher performance than about 30%. Deadline NOOP and not much difference, a difference of about 1% of it. Database perspective, then both.
==============================================

Two .iostat (lower)

rrqm / s and wrqm / S
　　the Merge several consecutive addresses the IO request to merge. To improve the efficiency of the IO
　　rrqm / s per second is the number of read (Read) requests the combined
　　number wrqm / s per second is the write (write) requests merged

　　The combined means: For example: the data is stored on the storage 4K blocks, sent to the two upper layer request, a request block directly next to these two together, the kernel will request these two merged into a requested to be 8K chunks, so that it only takes one IO, the IO without taking up twice. From a performance point would be good. After all, there are indicators of IOPS per second, so that performance is improved.

r / s and w / s
　　frequency and after merging (alter merge) IO request
　　number of read IO per second after the r / s combined
　　w / s after the merger of write IO times per second
　　r / s + w / s = IOPS

Rsec / s (rKB / s, rMB / s) and Wsec / S (WKB / S, WMB / S)
　　sec is sector (sector), a sector on the disk size is fixed, 512-byte
　　rsec / s how many sectors per second read
　　wsec / s per second, the number of sectors to write
　　because a sector is 512 bytes, the number of reads and writes can be converted into the sector number KB / MB number of bytes.

avgrq-sz
　　while a disk may be stored in the log storage data further, so that the size of the IO request is not the same as
　　the parameter is the average number of requests, Note: This value is 512 bytes * required final result, since the value is in sectors units.

avgqu-sz
　　average queue length IO requests (more important)
　　an HDD may be about 4, SSD 30 may be, it may be even higher.

the await, r_await, w_await
　　IO request time average wait, in units of MS
　　r_await and w_await correspond read IO request wait and write IO requests waiting

svctm
　　serve the IO request Average time
　　man document Tip Do not believe the value, the future will removed

% util
　　the disk is idle, not simply equal to the IO usage, this value can be interpreted as the disk is busy.
　　If the value of 100% can not simply equate to load the disk is full, reached a bottleneck
　　requires a comprehensive avgqu-sz, await other indicators to determine whether a comprehensive disk bottleneck reached

Three, MySQL's IO usage

1.iotop
yum -y install iotop

iotop -u mysql ##### -u user which means that the process of monitoring, so the premise is your MySQL MySQL service is user-initiated

Note: The above command only see MySQL thread ID (Thread ID) can not see what the specific thread in operation.

2.performance_schema.threads

use performance_schema;

select name,type,thread_id,thread_os_id from threads;
+----------------------------------------+------------+-----------+--------------+
| name | type | thread_id | thread_os_id |
+----------------------------------------+------------+-----------+--------------+
| thread/sql/main | BACKGROUND | 1 | 3611 |
| thread/sql/thread_timer_notifier | BACKGROUND | 2 | 3662 |
| thread/innodb/io_ibuf_thread | BACKGROUND | 3 | 3687 |
| thread/innodb/io_log_thread | BACKGROUND | 4 | 3688 |
| thread/innodb/io_read_thread | BACKGROUND | 5 | 3689 |
| thread/innodb/io_read_thread | BACKGROUND | 6 | 3690 |
| thread/innodb/io_read_thread | BACKGROUND | 7 | 3691 |
| thread/innodb/io_read_thread | BACKGROUND | 8 | 3692 |
| thread/innodb/io_write_thread | BACKGROUND | 9 | 3693 |
| thread/innodb/io_write_thread | BACKGROUND | 10 | 3694 |
| thread/innodb/io_write_thread | BACKGROUND | 11 | 3695 |
| thread/innodb/io_write_thread | BACKGROUND | 12 | 3696 |
| thread/innodb/page_cleaner_thread | BACKGROUND | 13 | 3697 |
| thread/innodb/srv_error_monitor_thread | BACKGROUND | 15 | 3740 |
| thread/innodb/srv_monitor_thread | BACKGROUND | 16 | 3741 |
| thread/innodb/srv_lock_timeout_thread | BACKGROUND | 17 | 3739 |
| thread/innodb/srv_master_thread | BACKGROUND | 18 | 3742 |　　 -- MySQL 主线程和ID
| thread/innodb/srv_purge_thread | BACKGROUND | 19 | 3743 |
| thread/innodb/srv_worker_thread | BACKGROUND | 20 | 3744 |
| thread/innodb/srv_worker_thread | BACKGROUND | 21 | 3745 |
| thread/innodb/srv_worker_thread | BACKGROUND | 22 | 3746 |
| thread/innodb/dict_stats_thread | BACKGROUND | 23 | 3748 |
| thread/innodb/buf_dump_thread | BACKGROUND | 24 | 3747 |
| thread/semisync/Ack_receiver | BACKGROUND | 25 | 3752 |
| thread/sql/signal_handler | BACKGROUND | 26 | 3773 |
| thread/sql/compress_gtid_table | FOREGROUND | 28 | 3774 |
| thread/sql/one_connection | FOREGROUND | 29 | 4991 |　　 -- FOREGROUND 前台线程
+----------------------------------------+------------+-----------+--------------+
27 rows in set (0.00 sec)

---- thread / sql / one_connection is my connection thread

---- processlist_id corresponding show processlist is the id

mysql> select connection_id (); - view the current connection of the above mentioned id
+ ----------------- +
| connection_id () |
+ ----------- + ------
| 3 |
+ ----------------- +
1 Row in the SET (0.04 sec)

Through information threads of the table, the combined output iotop -u mysql, you can know that a thread IO usage.
MySQL5.6 version does not thread_os_id this column.
Job: How iotop in association with information Thread ID and MySQL5.6 in the threads of the table?

Note:
If you have users on this table each row is updated, it will have a case lock, other threads will wait for the lock to release this table, this time by IO to see if it will not see the lock problem. So be sure to pay attention to this issue.

SSD sector size is typically 4K or 8K, but in order to be compatible HDD, SSD by converting Translation layer (FTL) Flash manner to 512B

4.O_DIRECT
　　fwrite / the fsync
　　fwrite to write data to a file system layer (Filesystem), (probably there cache), it does not guarantee written into the memory.
　　fsync guarantees to refresh the data to store. (Data off disk)

　　only by fwrite writes data very fast (because of cache), but subsequent calls fsync will be very slow, depending on the speed of disk IOPS
　　if not performed manually fsync, OS operating system of its own to control. When a filesystem is used to cache the operating system cache 10%, the operating system before the data into the disk brush. So there may be risk of data loss, such as power outages.
　　Inside the database each time fwrite will use fsync, to ensure data security.

Redo Log: If you turn O_DIRECT redo log, then performance will drop. So do not open O_DIRECT this option.

Four, sysbench

1. Install

[root@localhost ~]# git clone https://github.com/akopytov/sysbench.git
[root@localhost ~]# cd sysbench
[root@localhost ~]# ./autogen.sh
[root@localhost ~]# ./configure --with-mysql-includes=/usr/local/mysql/include/ --with-mysql-libs=/usr/local/mysql/lib/
[root@localhost ~]# make
[root@localhost ~]# make install
[root@localhost ~]# echo "export LD_LIBRARY_PATH=/usr/local/mysql/lib/:$LD_LIBRARY_PATH" >> ./.bashrc
[root@localhost ~]# source .bashrc
[root@localhost ~]# sysbench --version
sysbench 1.1.0-dcf0275

2.测试

生成测试文件

[root@localhost ~]# sysbench --test=fileio \ 　　　　 ##File IO测试
> --file-num=4 \ 　　　　　　　　　　　　　　　　 ##测试文件数是4个
> --file-block-size=16384 \ 　　　　　　　　　　　 ##block size是16k
> --file-total-size=100G \　　　　　　　　　　　　 ##4个文件的总大小是100G
> --file-test-mode=rndrd \ 　　　　　　　　　　　　##测试方法是随机读
> --file-extra-flags=direct \ 　　　　　　　　　　　 ##direct io，跳过缓存
> --max-requests=0 \ 　　　　　　　　　　　　　 ##一共发起多少请求，0表示任意请求
> --max-time=3600 \　　　　　　　　　　　　　　##测试3600s
> --num-threads=4 \ 　　　　　　　　　　　　　　##使用4个线程
> prepare # run or cleanup 　　　　　　　　　　　##prepare：生成文件
　　　　　　　　　　　　　　　　　　　　　　　##run：开始测试
　　　　　　　　　　　　　　　　　　　　　　　##cleanup：删除测试文件

[root@localhost ~]# sysbench --test=fileio \
--file-num=4 \
--file-block-size=16384 \
--file-total-size=2G \
--file-test-mode=rndrd \
--file-extra-flags=direct \
--max-requests=0 \
--max-time=300 \
--num-threads=4 \
prepare

WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
WARNING: --max-time is deprecated, use --time instead
sysbench 1.1.0-dcf0275 (using bundled LuaJIT 2.1.0-beta3)

4 files, 524288Kb each, 2048Mb total
Creating files for the test...
Extra file open flags: 3
Extending existing file test_file.0
Creating file test_file.1
Creating file test_file.2
Creating file test_file.3
2018525184 bytes written in 72.13 seconds (26.69 MiB/sec).

[root@localhost ~]# sysbench --test=fileio help
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
sysbench 1.1.0-dcf0275 (using bundled LuaJIT 2.1.0-beta3)

1. fileio options:
2. --file-num=N number of files to create [128]
3. --file-block-size=N block size to use in all IO operations [16384]
4. --file-total-size=SIZE total size of files to create [2G]
5. --file-test-mode=STRING test mode {seqwr, seqrewr, seqrd, rndrd, rndwr, rndrw}
6. --file-io-mode=STRING file operations mode {sync,async,mmap} [sync]
7. --file-async-backlog=N number of asynchronous operatons to queue per thread [128]
8. --file-extra-flags=STRING additional flags to use on opening files {sync,dsync,direct} []
9. --file-fsync-freq=N do fsync() after this number of requests (0 - don't use fsync()) [100]
10. --file-fsync-all[=on|off] do fsync() after each write operation [off]
11. --file-fsync-end[=on|off] do fsync() at the end of test [on]
12. --file-fsync-mode=STRING which method to use for synchronization {fsync, fdatasync} [fsync]
13. --file-merged-requests=N merge at most this number of IO requests if possible (0 - don't merge) [0]
14. --file-rw-ratio=N reads/writes ratio for combined test [1.5]

--file-num=N                       创建测试文件数量，默认是 [128]
--file-block-size=N                测试时文件块大小，默认是[16384]，即16K
--file-total-size=SIZE           测试文件的总大小，默认是 [2G]
--file-test-mode=STRING            测试模式 {seqwr（顺序写）, seqrewr（顺序读写）, seqrd（顺序读）, rndrd（随机读）, rndwr（随机写）, rndrw（随机读写）}
--file-io-mode=STRING              文件操作模式{sync,async,mmap} [sync]
--file-extra-flags=STRING        使用额外的标志打开文件 {sync,dsync,direct} []
--file-fsync-freq=N                执行fsync()频率，0表示不使用，默认100
--file-fsync-all=[on|off]         每执行一次写操作执行一次fsync(),默认 [off]
--file-fsync-end=[on|off]        测试结束执行fsync(),默认 [on]
--file-fsync-mode=STRING           同步方法 {fsync, fdatasync} [fsync]
--file-merged-requests=N           如果可以，则合并IO请求数，默认0表示不合并
--file-rw-ratio=N                  测试读写比例，默认[1.5] ，即读写比例 3:2

seqwr 顺序写入
seqrewr 顺序重写
seqrd 顺序读取
rndrd 随机读取
rndwr 随机写入
rndrw 混合随机读/写

开始测试
sysbench --test=fileio \
--file-num=4 \
--file-block-size=8k \
--file-total-size=1G \
--file-test-mode=rndrd \
--file-extra-flags=direct \
--max-requests=0 \
--max-time=30 \ ###简单测试，测试30秒
--num-threads=4 \
--report-interval=3 \ ###每3秒产生报告
run

WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
WARNING: --max-time is deprecated, use --time instead
sysbench 1.1.0-dcf0275 (using bundled LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Report intermediate results every 3 second(s)
Initializing random number generator from current time

Extra file open flags: 3
4 files, 256MiB each
1GiB total file size
Block size 8KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random read test
Initializing worker threads...

Threads started!

[ 3s ] reads: 0.27 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 196.894
[ 6s ] reads: 1.10 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 292.601
[ 9s ] reads: 0.51 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 142.387
[ 12s ] reads: 0.49 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 158.632
[ 15s ] reads: 0.51 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 158.632
[ 18s ] reads: 0.44 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 215.443
[ 21s ] reads: 0.45 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 176.731
[ 24s ] reads: 0.49 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 183.211
[ 27s ] reads: 0.50 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 147.608
[ 30s ] reads: 0.45 MiB/s writes: 0.00 MiB/s fsyncs: 0.00/s latency (ms,95%): 193.380

Throughput:
read: IOPS=58.37 0.46 MiB/s (0.48 MB/s)
write: IOPS=0.00 0.00 MiB/s (0.00 MB/s)
fsync: IOPS=0.00

Latency (ms):
min: 6.95
avg: 68.18
max: 593.60
95th percentile: 183.21
sum: 119787.46

上述测试随机读的速度在0.48MB/S 左右，
（0.46MB/s * 1024 / 8KB = 58.88）换算后得到的值58.88就是IOPS值，越等于上面的58.37。

测试完成后执行cleanup

如果是真实的测试 max-time设置成一周的时间
run期间可以使用iotop或者iostat进行观察

先生成测试文件，然后进行测试，测试完成后要通过cleanup删除文件。

I. Introduction disk scheduling algorithm

Two .iostat (lower)

Three, MySQL's IO usage

Four, sysbench

Guess you like