Linux优化之IO子系统监控与调优

Linux优化之IO子系统

做为服务器主机来说，最大的两个IO类型 ：

1.磁盘IO 

2.网络IO

这是咱们调整最多的两个部分所在

 

磁盘IO是如何实现的

在内存调优中，一直在讲到为了加速性能，linux内核通常状况下都会尝试将磁盘上的慢速设备上的文件缓存至内存中，从而达到加速效果;

虚拟内存的概念：

读写都在内存中完成，当某一进程在cpu运行的时候，进程要访问本身地址空间中的某一内存页，当进程须要访问页面中的数据，而这个页面最终是要对应在物理内存中的某个物理页面，而进程只能看到本身的线性地址空间，而这个地址并不存在，一旦访问这个地址，那么会经过MMU（内存管理单元）机制中的存储当前进程的线性地址到物理地址的映射表

由此经过MMU实现对应的地址查询因而获得了其映射的地址，最终进程虽然访问的数据是来自于映射过的地址,这种访问访问咱们被称为虚拟地址或虚拟内存

 

若是因为咱们使用交换内存或其余方式有可能这个进程所打开的文件长时间没有被访问，这个文件所对应的内存已经被清出去了，因此使用mmu地址转换后的地址对应的数据在内存中不存在了，这时候会产生页错误，咱们也被称为缺页异常

 

缺页异常

缺页异常分为大异常和小异常：

    若是数据不存在使得不得不在磁盘中载入页面文件，这时CPU就会进入内核模式，访问磁盘，每次CPU访问内存就要3个周期，访问磁盘须要N个周期，首先须要定位数据的准确位置，然后定位物理内存中开辟数据空间，最后将数据总线贯通，从而将数据从磁盘转入到内存--blockin

 

    当咱们找一个空闲空间，而事实上当进程访问这段数据就须要访问新位置的数据，因此咱们要更新这个映射表，明确说明所要访问的逻辑地址所要对应的空间的转换的位置，而且让进程从新发起一次访问，这时须要先查找TLB（缓存缓冲器），再次进行查表

    而将磁盘装入内存的过程就会发生IO，若是进程修改了数据，最终数据还须要写到磁盘中去，而写到磁盘中去，过程使得数据比原来的文件更大了

具体是由文件系统模块根据进程发起的请求，内核指挥文件系统模块开辟更多的存储块然后将数据存储，这种过程被称为 block out

 

#缓冲器负责将以前缓冲过的缓存下来，那么若是N个条目，而缓冲器只能缓存有限的几个，那么命中率可能会很低，若是咱们使用大页面的话，那么命中率能够大大提升。

 

 

机械硬盘的特性

同一方向的操做是合并起来完成的，然后在这个方向结束以后则是另一方向的

对硬盘来说，读写是不一样类型的操做，读写是不能同时进行的

 

磁盘是如何操做的

将一个或多个进程的读操做合并到一块儿读

将一个或多个进程的写操做合并到一块儿写

 

因此读写操做是两类不一样的操做并且是同一方向合并的

若是是读文件，这个文件必定是来自于磁盘的

若是是写文件，那么写入到内存中，对于进程来说是已经完成的，那么用户对计算机性能感知是来自于读，由于读必定是与IO相交互

 

1.读是在同方向合并的

2.写也是须要合并的，并且二者是不一样方向的操做

由于在同一方向能够节省不少资源

读必须优先知足，而写也不能等过久，所以必须有一种良好的算法让其尽量都获得知足，而又不能让用户感到性能降低  

所以在IO系统上有个很是重要的模块---IO调度器

 

IO调度器

用来实现合并同一方向的读写操做而且将读写操做尽量理想的这种情况

IO调度器自己的完成，最终用户实现写的时候进程级别所看到的数据是文件接口

那么文件接口输出的时候就意味着将磁盘空间以文件接口的方式输出，其须要文件系统

也就意味着进程与磁盘上的数据打交道是依赖文件系统的

 

因此用户的请求先到文件系统，而文件系统经过内核输出是虚拟文件接口（VFS) 经过VFS找到各特定文件系统相关模块，固然对应的文件是哪一个那么则经过vfs转换成什么便可

文件系统将数据接下来以后，最终存储为磁盘块的方式保存在磁盘上，所以这些文件系统最终还要转换数据为磁盘块，因此接下来还要有块层

块层主要是将数据转换为磁盘块格式，然后再由磁盘块格式转换成调度之后存储在磁盘上

以下图所示：

（1）用户进程实现写操做 实现系统调用

（2）用户的写操做必定是跟VFS进行交互的

（3）VFS须要将其换换为特定的文件系统

（4）单个文件在虚拟文件系统存放都会转换成页面方式（page cache)

（5）写完以后经过block buffer快缓冲（知因此进行缓冲是由于磁盘太慢了，因此写的时候须要缓冲下来）

（6）而后由bio将每一个page cache转换成块，而且在块缓冲这个层次上缓存下来

这就是缓冲队列，而在块层实现缓冲以后每一个块最终都要交给块层来处理，块层中最重要的一个组件就是IO调度器，IO调度器接收blockbuffer中所发送过来的多个请求块，这多个请求块须要排序的：同方向合并，图中都是写操做的 

至于如何排序，必定是最靠近写请求的最优先知足

 

而IO调度器主要功能就是将随机IO尽量合并为顺序IO  本文来自http://yijiu.blog.51cto.com 转载请说明，翻版可耻

可是咱们有说过，尽量同一方向合并尽量会随机变为顺序，可是咱们又不得不读饥饿也不能写饥饿，因此要交替进行的

因此:

（10）由IO调度器调度完成以后，提交给Device Driver ,由Device Driver控制磁盘控制器，由控制器将电器信号转换为磁信号写入到磁盘中去

 

为什么随机读写比顺序读写要慢：

·随机读写：

咱们可能写任意一个磁道的任意一个扇区，那么硬盘磁头可能来回晃动才能完成一次写

·顺序读写：

在一个方向转动便可完成，不用再去移动磁臂的

磁头操做是电磁运动，而磁臂操做是机械运动，因此任什么时候候随机读写性能都比顺序读写都要差的不少

 

 

调度算法

IO调度器事实上是用程序完成的调度算法，对linux来说，2.6的内核一共有4个

1、CFQ

  彻底公平队列，比较适合于交互式场景      

2、Deadline

   最后期限，任何一个读写请求,都有本身的知足期限，当期限到来时以前，必须达到需求的知足（通常建议在数据库服务器上使用此调度算法）

3、anticpatory

   预期的,任何一个数据读完以后，有可能与其相邻的数据也可能被读到，因此它大体所实现的方法就是，读完以后先不知足，则不处理，需等一段时间后查看是否有相近数据访问过，若是有立刻先知足，因此这只能在行为预估的场景下可用

4、Noop

    不排队不合并，先到先得

    #像固态硬盘，由于它不是机械硬盘，它的读写就算是随机IO那么它的性能跟顺序IO差异也不是很大，反而若是想让调度器去调取它的算法，那么调度器自己运行会占用很高的CPU的时钟周期，有可能会得不偿失，因此noop在这种场景下是最好的算法

    #有些RAID设备控制器在硬件设备上本身就有读写操做排序的，也就意味着在硬件级别排好序以后在操做系统级别会将其打散从新排序，得不偿失，因此RAID设备有本身的调度器的话，最好也使用noop

通常来说，默认是CFQ的

 本文来自http://yijiu.blog.51cto.com 转载请说明，翻版可耻

有时候在不一样场景下，他们所最佳所适用的算法可能不同，好比：

若是是web服务器，这里只是访问放web上的分区的页面数据

若是是db数据库，访问的是db数据库的文件，他们最适用的算法未必会同样，由于他们的访问风格不一样，因此这时候咱们就须要修改他们的调度器算法

CFQ比较适合于交互式场景，因而在不少时候会将服务器设置为Deadline，固然只是一种假定，具体须要本身测试而后作决定

 

观测当前磁盘IO活动

通常 ethstatus iotio pt-ioprofile sar等查工具看哪些进程引发的io比较高等

这里咱们使用sar来观察其状态信息  本文 来自http://yijiu.blog.51cto.com 转载 请说明，翻版 可耻

例：

[root@node3 ~]# sar  -d 1 5

Linux2.6.32-431.20.3.el6.x86_64 (node3.test.com) 09/20/2014   _x86_64_(4 CPU)

 

09:16:00 PM       DEV      tps  rd_sec/s  wr_sec/s avgrq-sz  avgqu-sz     await    svctm     %util

09:16:01 PM  dev252-0    46.46      0.00  46795.96  1007.13      2.65    580.00     2.26     10.51

 

09:16:01 PM       DEV      tps  rd_sec/s  wr_sec/s avgrq-sz  avgqu-sz     await    svctm     %util

09:16:02 PM  dev252-0     3.00      0.00    144.00    48.00      0.00      1.33     1.00      0.30

 

09:16:02 PM       DEV      tps  rd_sec/s  wr_sec/s avgrq-sz  avgqu-sz     await    svctm     %util

09:16:03 PM  dev252-0     0.00      0.00      0.00     0.00      0.00      0.00     0.00      0.00

 

09:16:03 PM       DEV      tps  rd_sec/s  wr_sec/s avgrq-sz  avgqu-sz     await    svctm     %util

09:16:04 PM  dev252-0     0.00      0.00      0.00     0.00      0.00      0.00     0.00      0.00

 

09:16:04 PM       DEV      tps  rd_sec/s  wr_sec/s avgrq-sz  avgqu-sz     await    svctm     %util

09:16:05 PM  dev252-0    72.73      0.00  59967.68   824.56      2.61     35.88     1.21      8.79

用参数-p能够打印出sda,hdc等磁盘设备名称,若是不用参数-p,设备节点则有多是dev8-0,dev22-0

参数解释：

tps:每秒从物理磁盘I/O的次数.多个逻辑请求会被合并为一个I/O磁盘请求,一次传输的大小是不肯定的

rd_sec/s:每秒读扇区的次数. 

avgrq-sz:平均每次设备I/O操做的数据大小(扇区). 

avgqu-sz:磁盘请求队列的平均长度.

await:从请求磁盘操做到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间,单位是毫秒(1秒=1000毫秒).（一次完成的任务，它的IO完成的平均耗时）

svctm:系统处理每次请求的平均时间,不包括在请求队列中消耗的时间，

%util:I/O请求占CPU的百分比,比率越大,说明越饱,通常到95左右可能要引发关注

咱们一般经验值是：

svctm不超过0.5；

await不超过5；

主要看当前设备

核心要点：
一、tps(iops)越高，但%util越低，说明io能力容量越大
二、await、svctm越低越好，说明io响应延迟很低，iops能力很高

 

调整buffer，提升性能

无非就是调整队列数，以及增长预读数，下面咱们来手动作一下

·增长队列长度

格式：

/sys/block/vda(特定某设备)/queue/nr_requests

因为我这里跑的是kvm虚机，因此设备号默认都以vdx开头

默认队列为128个长度

[root@node3 ~]#  cat /sys/block/vda/queue/nr_requests

128

这个值是能够调大一点的

 

2.增长预读数

  /sys/block/vda(特定某设备)/queue/read_ahead_kb

表示事先预读数据的kb数，默认也是128

[root@node3 ~]# cat /sys/block/vda/queue/read_ahead_kb
128

这个值也是能够调大的，具体多少自行而定

 本文 来自http://yijiu.blog.51cto.com 转载 请说明，翻版 可耻

 

CFQ彻底公平队列

IO调度是在各进程之间平均分配的，主要是根据进程的IO需求来说IO能力平均分配调度

因此在交互式环境中，这种方式是比较实用的

 

可是在RHEL6.4上 它又提供了三个不一样的调度等级：

1.实时 RT

2.最佳效果 BE

3.闲置

 

咱们可使用ionice命令手动分配调度等级，或者使用iopro_set系统调用编程分配，固然涉及到开发层面了

在实时调度等级和最佳效果两个级别都有8个IO等级，

数字越小优先级越高，最佳效果是默认调度等级 也就是4，不用更改

 

修改CFQ，以调节其性能

涉及参数文件：/sys/block/vda/queue/iosched/

修改默认调度器算法：

[root@node3 ~]# cd /sys/block/vda/queue/

[root@node3 queue]# ls

add_random           hw_sector_size      max_hw_sectors_kb  minimum_io_size  physical_block_size  scheduler

discard_granularity  iosched             max_sectors_kb     nomerges         read_ahead_kb        unpriv_sgio

discard_max_bytes    iostats             max_segments       nr_requests      rotational

discard_zeroes_data  logical_block_size  max_segment_size   optimal_io_size  rq_affinity

而在其上层目录里，有一scheduler文件

查看scheduler文件

[root@node3 queue]# cat scheduler

noop anticipatory deadline [cfq]

所以更改磁盘IO调度器则去找这个目录下所对应的scheduler，注意的是，它只是针对每一个磁盘进行调整的，若是有多块磁盘的话则须要对应每一个磁盘进行修改

它没有办法使用sysctl进行控制，若是想开机生效，只能写到rc.local 或init脚本中

 

一旦更改调度算法以后，再来查看目录中的文件

[root@node3 queue]# ls /sys/block/vda/queue/iosched/

back_seek_max      fifo_expire_async  group_idle       low_latency  slice_async     slice_idle

back_seek_penalty  fifo_expire_sync   group_isolation  quantum     slice_async_rq  slice_sync

修改算法

[root@node3 queue]# echo deadline > scheduler

[root@node3 queue]# cat scheduler

noop anticipatory [deadline] cfq

再次观察iosched目录，并查看其是否有变化

[root@node3 queue]# ls/sys/block/vda/queue/iosched/

fifo_batch  front_merges read_expire  write_expire  writes_starved

因此咱们更改调度算法后，每一个调度算法在此目录都有不少可调整参数，每一个参数都有值，只不过都表现为其文件内容而已，而每一个调度器的值经过修改是能够优化调度器的工做特性的

 

好比对CFQ来说，有如下几个值能够调整：

back_seek_max

    反向寻道可能有负面影响，负载小的时候能够启用，不然不要使用反向寻道太多值

 

back_seek_penal

    反向寻道作惩罚，若是不得不使用反向寻道的话，那么必须对其作出必定惩罚，一旦作完惩罚以后，必需要正向寻道更屡次数

 

fifo_expire_async

    用来控制异步请求等待时间长度，默认是250毫秒，过时以后没法知足的异步请求将会被移动到调度队列中，也就意味着要从新调度。一般这些值不须要调整

 

fifo_expire_sync

    用于同步请求的,

严格来说写操做都是在内存中完成 过周期以后才会同步至硬盘中，站在计算机角度来讲这种操做都被称为异步，而同步则是为了尽量保证数据会被第一时间写到磁盘上来，数据不会在内存上逗留，直接写入磁盘

 

low_latecy

    低延迟，简单来说，每一个进程都有可能发起读写请求，也就意味着最终知足用户读写请求是按进程为单位划分，在知足这个前提下，须要考虑每一个进程都须要获得知足，因此必须关注每一个进程发起IO请求以后最多等待多长时间，若是启动此值就意味着每一个进程只要发起读写请求都要尽量快速获得知足，默认就启用了低延迟

    在桌面系统环境，低延迟是很是有必要的

 

quantum

    CFQ一次能够发出的IO请求数，一批最大能够调度的IO数，限制IO队列深度的，简单来讲就是定义设备一次能够接收的IO请求的队列长度，默认为8

    增长反而会有负面影响，所以谨慎调整

    若是随机IO请求数很是的多，这个值能够适当调大，若是顺序写很是多，那么不建议调整

 

设置IO容许消耗的时间

一次IO请求的操做，一次执行多久，应该执行多久，按理说硬盘只要是没有损坏，能正常运做，在正常范围内，那么它就应该写完、读完因此咱们要定义好每次读写请求所最大容许消耗的时间，那么就是如下几个参数的意义了：

slice_async

    定义异步写入的超时值，每次异步写操做最长时长是多少，默认值为40秒

slice_idle

    等待IO请求的闲置时长

slice_sync

    定义同步写入操做超时值，由于同步比较慢，因此其默认值是100秒，由于是从进程直接到磁盘的，因此超时时间会长一点

在桌面环境和在服务环境下，他们若是都使用CFQ调度器，他们工做特性不必定，也就意味着咱们关注其背后工做机制参数也不同，因此要调整某些值作一些测试的评判

 

 

Deadline最后期限调度

最后期限

如图所示，其分为了3个队列，分别是:

·读队列

·写对列

·排序队列

然后这些队列都被整合到派发队列中去然后由磁盘获得知足，咱们从中任何一队列中选出一个操做获得知足以前必需要保证这类操做不能超期

简单来说deadline就是将每一个读写操做放到队列的时候都给他一个倒计时的计时器，将倒计时的计时器消耗完以前须要赶忙放到派发队列中，然后再同步至硬盘

而对服务器来说，这种方式是比较理想的

 

经常使用可调参数

fifo_batch

    单批发出的读写数，在其最后期限知足以前将队列中的数据拿出并知足，但有写操做是须要排序的;默认为16，设置更多的值会得到更好的流量，可是会增长延迟

    好比一批读为16个，那么咱们讲其改成32个，那意味着写的时间会更高

    固然全部都取决于测试数据，不管怎么调都不如换一块SSD硬盘

 

front_merges

    能够将多个请求合并在一块儿，可是有些请求压根不连续，不可能被合并在一块儿，那么咱们能够禁止在知足IO以前进行合并的，禁止合并有可能会带来随机读写的特性的

    但容许合并也有必定的反作用，就是必须花时间去排序

 

read_expire

    每一个读操做必须在多少期限内获得知足，默认为半秒钟

 

write_expire

    每一个写操做必须在多久内获得知足，默认为5秒钟

 

#写操做是能够延迟知足的

 

writes_starved

    定义一批能够处理多少个读取批，这个值越高，读的效果就越好。默认为2，意味着2批读，一批写。若是服务器读多写少，内存缓冲足够大，那么能够将其调大

 

Noop

若是系统与cpu绑定，且使用高速存储（SSD），这就是最佳的IO调度程序

只要使用固态硬盘就要将其改成noop

 

若是调参数的话则须要直接去挑战/sys/block/vda/queue下的参数,而不是调度器的参数

 

add_random

    其做用是否使用商池

 

max_sectors_kb

    默认发送到磁盘的最大请求是多少，默认为512kb。咱们知道每一个扇区是512字节，那么每次发送512kb 意味着发送N个扇区，咱们能够调整或增大减少该值，对于固态硬盘来说不是所谓的扇区概念，由此可调。

    在此类状况下建议将max_hw_sectors_kb下降删除块大小

咱们可使用压力测试工具对其作测试，记录大小从512kb到1MB不等，哪一个值的效果好就设置为哪一个值，固然压力测试跟实际场景有出入的，因此要充分考虑环境尽量模拟真实场景，尽量要模拟随机读写

 

nr_request

    请求的队列的值，能够下降其值

rotational

    若是是SSD硬盘要将此值设置为0，禁用轮转模式

 

rq_affinity

    在触发IO不一样的CPU中处理IO，通常来说在同CPU上处理同IO是最好的

    由于CPU处理的仅仅是中断而已

 

所以对于SSD环境中经常使用的调整参数有：

max_sectors_kb

nr_requests

optimal_io_size

rotational

 

调整后如何测试性能是否提升

比较经常使用的硬盘压力测试工具

·aio-stress

·iozone

·fio

 

了解磁盘IO活动情况分析工具

blktrace

 

磁盘IO瓶颈分析工具

blkparse

gnuplot

 本文 来自http://yijiu.blog.51cto.com 转载 请说明，翻版 可耻

 

总结:IO优化大体思路

·最好换SSD

·调整raid级别

·选择IO调度器

·根据场景选择合适的文件系统

·配置选定调度器的参数

·优化结果是否理想，则使用工具进行分析

·写在开机启动项里