磁盘IO过高时的处理办法

针对系统中磁盘IO负载过高的指导性操作

主要命令：echo deadline > /sys/block/sda/queue/scheduler

注：以下的内容仅是提供参考，如果磁盘IO确实比较大的话，是数据库，可以进行读写分离或者分库操作，减小磁盘压力，文件的话，可以利用raid来减轻压力

一)I/O调度程序的总结:

1)当向设备写入数据块或是从设备读出数据块时,请求都被安置在一个队列中等待完成.
2)每个块设备都有它自己的队列.
3)I/O调度程序负责维护这些队列的顺序,以更有效地利用介质.I/O调度程序将无序的I/O操作变为有序的I/O操作.
4)内核必须首先确定队列中一共有多少个请求,然后才开始进行调度.

二)I/O调度的4种算法

1)CFQ(完全公平排队I/O调度程序)

特点:
在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.
CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.
CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.
CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级.

工作原理:
CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,
以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求.

2)NOOP(电梯式调度程序)----适用于SSD固态硬盘。

在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而固态硬盘没有所谓的寻道时间且IO响应时间非常短。

特点:
在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.
NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.
NOOP倾向饿死读而利于写.
NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.

电梯算法饿死读请求的解释:
因为写请求比读请求更容易.
写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.
读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.

3)Deadline(截止时间调度程序)

特点:
通过时间以及硬盘区域进行分类,这个分类和合并要求类似于noop的调度程序.
Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.
Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择.

4)AS(预料I/O调度程序)

特点:
本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度.
可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价.
它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量.
AS适合于写入较多的环境,比如文件服务器
AS对数据库环境表现很差.

三)I/O调度方法的查看与设置

1)查看当前系统的I/O调度方法:

[root@test1 tmp]# cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq]

2)临地更改I/O调度方法:
例如:想更改到noop电梯调度算法:
echo deadline > /sys/block/sda/queue/scheduler

3)想永久的更改I/O调度方法: 如下
修改内核引导参数,加入elevator=调度程序名

[root@test1 tmp]# vi /boot/grub/menu.lst
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

重启之后,查看调度方法:
[root@test1 ~]# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq 
已经是deadline了

四)I/O调度程序的测试

本次测试分为只读,只写,读写同时进行.
分别对单个文件600MB,每次读写2M,共读写300次.

1)测试磁盘读:
[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.81189 seconds, 92.4 MB/s

real    0m6.833s
user    0m0.001s
sys     0m4.556s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.61902 seconds, 95.1 MB/s

real    0m6.645s
user    0m0.002s
sys     0m4.540s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 8.00389 seconds, 78.6 MB/s

real    0m8.021s
user    0m0.002s
sys     0m4.586s
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/sda1 f=/dev/null bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 29.8 seconds, 21.1 MB/s

real    0m29.826s
user    0m0.002s
sys     0m28.606s
结果:
第一 noop:用了6.61902秒,速度为95.1MB/s
第二 deadline:用了6.81189秒,速度为92.4MB/s
第三 anticipatory:用了8.00389秒,速度为78.6MB/s
第四 cfq:用了29.8秒,速度为21.1MB/s

2)测试写磁盘:
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.93058 seconds, 90.8 MB/s

real    0m7.002s
user    0m0.001s
sys     0m3.525s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.79441 seconds, 92.6 MB/s

real    0m6.964s
user    0m0.003s
sys     0m3.489s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 9.49418 seconds, 66.3 MB/s

real    0m9.855s
user    0m0.002s
sys     0m4.075s
[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# time dd if=/dev/zero f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 6.84128 seconds, 92.0 MB/s

real    0m6.937s
user    0m0.002s
sys     0m3.447s

测试结果:
第一 anticipatory,用了6.79441秒,速度为92.6MB/s
第二 deadline,用了6.84128秒,速度为92.0MB/s
第三 cfq,用了6.93058秒,速度为90.8MB/s
第四 noop,用了9.49418秒,速度为66.3MB/s

3)测试同时读/写

[root@test1 tmp]# echo deadline > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 15.1331 seconds, 41.6 MB/s
[root@test1 tmp]# echo cfq > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 36.9544 seconds, 17.0 MB/s
[root@test1 tmp]# echo anticipatory > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 23.3617 seconds, 26.9 MB/s
[root@test1 tmp]# echo noop > /sys/block/sda/queue/scheduler 
[root@test1 tmp]# dd if=/dev/sda1 f=/tmp/test bs=2M count=300
300+0 records in
300+0 records out
629145600 bytes (629 MB) copied, 17.508 seconds, 35.9 MB/s

测试结果:
第一 deadline,用了15.1331秒,速度为41.6MB/s
第二 noop,用了17.508秒,速度为35.9MB/s
第三 anticipatory,用了23.3617秒,速度为26.9MS/s
第四 cfq,用了36.9544秒,速度为17.0MB/s

五)ionice

ionice可以更改任务的类型和优先级,不过只有cfq调度程序可以用ionice.
有三个例子说明ionice的功能:
采用cfq的实时调度,优先级为7
ionice -c1 -n7  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
采用缺省的磁盘I/O调度,优先级为3
ionice -c2 -n3  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&
采用空闲的磁盘调度,优先级为0
ionice -c3 -n0  -ptime dd if=/dev/sda1 f=/tmp/test bs=2M count=300&

ionice的三种调度方法,实时调度最高,其次是缺省的I/O调度,最后是空闲的磁盘调度.
ionice的磁盘调度优先级有8种,最高是0,最低是7.

注意,磁盘调度的优先级与进程nice的优先级没有关系。一个是针对进程I/O的优先级,一个是针对进程CPU的优先级。

总结：

1、CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足。

IO调度器算法的选择，既取决于硬件特征，也取决于应用场景。

在传统的SAS盘上，CFQ、DEADLINE、ANTICIPATORY都是不错的选择；对于专属的数据库服务器，DEADLINE的吞吐量和响应时间都表现良好。

然而在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而固态硬盘没有所谓的寻道时间且IO响应时间非常短。

2、对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL默认的 IO 调度器设置为 cfq

磁盘IO过高时的处理办法 针对系统中磁盘IO负载过高的指导性操作的更多相关文章

  1. 针对系统中磁盘IO负载过高的指导性操作

    针对系统中磁盘IO负载过高的指导性操作 主要命令:echo deadline > /sys/block/sda/queue/scheduler 注:以下的内容仅是提供参考,如果磁盘IO确实比较大 ...

  2. 磁盘IO过高时的处理办法

    针对系统中磁盘IO负载过高的指导性操作 主要命令:echo deadline > /sys/block/sda/queue/scheduler 注:以下的内容仅是提供参考,如果磁盘IO确实比较大 ...

  3. 针对Properties中实时性要求不高的配置参数，用Java缓存起来

    Properties常用于项目中参数的配置,当项目中某段程序需要获取动态参数时,就从Properties中读取该参数,使程序是可配置的.灵活的. 有些配置参数要求立即生效,有些则未必: 一.实时性要求 ...

  4. Linux系统中磁盘block和windos中的簇一个意思

    block就是几个连续扇区组成一个block,每个分区可以设置block大小,好比一个txt只有2字节,但是这个分区的block为4K,那么其实这个txt需要4k来存储(所以大文件block设置大比较 ...

  5. Win7系统中wmiprvse.exe占用CPU高如何解决

    该进程的详细路径是在:C:\WINDOWS\System32\Wbem  我们可以在任务管理器中“wmiprvse.exe”进程上单击右键,选择“打开文件位置”即可看到,如果该文件不在该文件夹中,那么 ...

  6. 浅谈计算机中的IO模型

    IO模型一共有5种: blocking IO #阻塞IO nonblocking IO #非阻塞IO IO myltiplexing #IO多路复用 signal driven IO #信号驱动IO ...

  7. 系统学习 Java IO ---- 目录，概览

    Java IO 类的系统教程,原创.主要参考自英文教程 Java IO Tutorial 和 Java Doc. http://tutorials.jenkov.com/java-io/index.h ...

  8. AIX 中 Paging Space 使用率过高的分析与解决

    AIX操作系统中Paging Space是很重要的设备,当系统中Paging Space使用率过高.系统内存不足时,将影响系统的整体性能,甚至会造成系统的挂起.针对这种情况,通常可以靠增加Paging ...

  9. (转)AIX 中 Paging Space 使用率过高的分析与解决

    AIX 中 Paging Space 使用率过高的分析与解决 原文:https://www.ibm.com/developerworks/cn/aix/library/au-cn-pagingspac ...

随机推荐

  1. PAT (Advanced Level) Practice 1006 Sign In and Sign Out (25 分) 凌宸1642

    PAT (Advanced Level) Practice 1006 Sign In and Sign Out (25 分) 凌宸1642 题目描述: At the beginning of ever ...

  2. jq分页功能。

    最近在写官网的分页功能.在网上找了很多案例都太复杂也太重.所以准备写一个简单一点的分页. 需求:把请求到的数据做分页. 准备:使用了网上一个简单的分页插件. 思路:分页相当于tab切换功能.具体实操把 ...

  3. 【Azure 微服务】Service Fabric中微服务在升级时，遇见Warning - System.Collections.Generic.KeyNotFoundException 服务无法正常运行

    问题描述 使用.Net Framework 4.5.2为架构的Service Fabric微服务应用,在升级后发布到Azure Fabric中,服务无法运行.通过Service Fabric Expl ...

  4. go中控制goroutine数量

    控制goroutine数量 前言 控制goroutine的数量 通过channel+sync 使用semaphore 线程池 几个开源的线程池的设计 fasthttp中的协程池实现 Start Sto ...

  5. CIE标准色度系统（下）

    四.色温与相关色温 根据绝对黑体光谱分布特性的普朗克定律,由普朗克公式可以计算出黑体对应于某一温度的光谱分布,并由此应用CIE标准色度系统可获得该温度下黑体发光的三刺激值和色品坐标,从而在色品图上得到 ...

  6. 了解什么是redis的雪崩和穿透？redis崩溃之后会怎么样？系统该如何应对这种情况？如何处理redis的穿透？

    缓存雪崩发生的现象 缓存雪崩的事前事中事后的解决方案 事前:redis高可用,主从+哨兵,redis cluster,避免全盘崩溃 事中:本地ehcache缓存 + hystrix限流&降级, ...

  7. SpringBoot - yml写法

    1 #区分大小写 2 server: 3 port: 8081 4 path: hello 5 6 #字面量:普通的值(数字,字符串,布尔): 7 #字符串:双引号 - 不转义 单引号 - 转义 8 ...

  8. Pytorch系列:（二）数据加载

    DataLoader DataLoader(dataset,batch_size=1,shuffle=False,sampler=None, batch_sampler=None,num_worker ...

  9. 前端缓存API请求数据

    1. 背景 在一些项目中,有时候会出现不同模块重复请求大量相同api接口的情况,特别是在一些功能相似的后台管理页面中.以下面这几个页面为例,每次进入页面都需要请求等大量重复的下拉框数据,下拉框数据短时 ...

  10. k8s 使用nfs做provisioner

    官方的nfs provisoner,serviceAccount RABC相关 请在这里下载https://raw.githubusercontent.com/kubernetes-incubator ...