解决Linux进程占用IO的问题 (linux 进程占用了io)

在Linux系统中，进程占用IO的问题是很常见的。当进程占用了过多的IO资源时，会导致系统变慢，甚至崩溃。因此，是非常重要的。本文将介绍常见的解决方法。

1. 使用iostat分析IO情况

iostat是一个常用的IO性能分析工具，它可以分析IO吞吐量、IO延迟和IO负载等指标。使用iostat可以帮助我们了解系统的IO使用情况，从而判断是否存在进程占用IO的问题。

使用iostat需要安装sysstat包。在Ubuntu系统中，可以通过以下命令安装：

“`

sudo apt-get update

sudo apt-get install sysstat

“`

安装完成后，可以使用以下命令查看IO情况：

“`

iostat -x 1

“`

该命令会每隔1秒输出一次IO情况。可以观察每个设备的平均IO响应时间（awt）、IO利用率（util）等指标，判断是否存在进程占用IO的问题。

2. 使用lsof查找占用文件的进程

lsof是一个常用的文件列表命令，可以列出系统中打开的文件和进程信息。使用lsof可以查找哪个进程占用了某个文件或目录。

例如，以下命令可以查找占用/dev/sda1文件系统的进程：

“`

sudo lsof /dev/sda1

“`

如果该命令返回结果，则说明存在占用/dev/sda1的进程。通过查找占用文件的进程，我们可以定位占用IO资源的进程，从而采取相应的措施。

3. 使用ionice限制进程IO优先级

ionice是一个用于限制进程IO优先级的工具。使用ionice可以调整进程对IO资源的使用权，从而避免某个进程占用过多的IO资源导致系统变慢。

ionice有三个命令：-c、-n和-p。其中，-c指定调度策略，可以是idle、batch、best-effort或realtime；-n指定IO优先级，可以是0到7的整数；-p指定进程ID。

例如，以下命令可以将进程ID为1234的进程的IO优先级调整为3：

“`

sudo ionice -c3 -p1234

“`

通过调整进程IO优先级，我们可以控制进程对IO资源的使用权，从而避免占用过多的IO资源。

4. 使用cgroups限制进程IO资源

cgroups是Linux内核提供的一种资源限制机制，可以限制进程的CPU、内存、IO等资源使用。使用cgroups可以限制某个进程的IO资源使用，避免进程占用过多的IO资源导致系统变慢。

在Ubuntu系统中，可以通过以下命令安装cgroups：

“`

sudo apt-get update

sudo apt-get install cgroup-tools

“`

安装完成后，可以使用以下命令创建一个名为test的cgroup，并限制该cgroup中的进程IO速率为50M/s：

“`

sudo cgcreate -g blkio:test

sudo cgset -r blkio.throttle.read_bps_device=/dev/sda1 50M test

“`

该命令会创建一个名为test的cgroup，并限制该cgroup中的进程在/dev/sda1设备上的读IO速率为50M/s。如果某个进程被加入到test cgroup，则其IO速率将被限制。

通过使用cgroups，我们可以灵活地限制进程的IO资源使用，从而避免进程占用过多的IO资源导致系统变慢。

是非常重要的。本文介绍了常见的解决方法，包括使用iostat分析IO情况、使用lsof查找占用文件的进程、使用ionice限制进程IO优先级和使用cgroups限制进程IO资源。通过采取合适的措施，我们可以避免进程占用过多的IO资源，保证系统的稳定性和可靠性。

相关问题拓展阅读：

• linux查看磁盘io的几种方法
• 如何提高Linux下块设备IO的整体性能

linux查看磁盘io的几种方法

linux查看磁盘io的几种方法

怎样才能快速的定位到并发高是由于磁盘io开销大呢?可以通过三种方式：

　　之一种：用 top 命令 中的cpu 信息观察

　　Top可以看到的cpu信息有：

　　Tasks: 29 total, 1 running, 28 sleeping, 0 stopped, 0 zombie

　　Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si

　　具体的解释如下：

　　Tasks: 29 total 进程总数

　　1 running 正在运行的进程数

　　28 sleeping 睡眠的进程数

　　0 stopped 停止的进程数

　　0 zombie 僵尸进程数

　　Cpu(s):

　　0.3% us 用户空间占用CPU百分比

　　1.0% sy 内核空间占用CPU百分比

　　0.0% ni 用户进程空间内改变过优先级的进程占用CPU百分比

　　98.7% id 空闲CPU百分比

　　0.0% wa 等待输入输出的CPU时间百分比

　　0.0% hi

　　0.0% si

　　0.0% wa 的百分比可以大致的体现出当前的磁盘io请求是否频繁。如果 wa的数量比较大，说明等待输入输出的的io比较多。

　　第二种：用vmstat

　　vmstat 命令报告关于线程、

虚拟内存

、磁盘、陷阱和 CPU 活动的统计信息。由 vmstat 命令生成的报告可以用于平衡系统负载活动。系统范围内的这些统计信息(所有的处理器中)都计算出以百分比表示的

平均值

，或者计算其总和。

　　输入命令：

　　vmstat 2 5

　　如果发现等待的进程和处在非中断睡眠状态的进程数非常多，并且发送到块设备的块数和从块设备接收到的块数非常大，那就说明磁盘隐缓io比较多。

　　vmstat参数解释：

　　Procs

　　r: 等待运行的进程数 b: 处在非中断睡眠状态的进程数 w: 被交换出去的可运行的进程慧信数。此数由 linux 计算得出，但 linux 并不耗尽交换空间

　　Memory

　　swpd: 虚拟内存使用情况，单位：KB

　　free: 空闲的内存，单位KB

　　buff: 被用来做为缓存的内存数，单位：KB

　　Swap

　　si: 从磁盘交换到内存的交换页数量，单位：KB/秒

　　so: 从内存交换到磁盘的灶碧模交换页数量，单位：KB/秒

　　IO

　　bi: 发送到块设备的块数，单位：块/秒

　　bo: 从块设备接收到的块数，单位：块/秒

　　System

　　in: 每秒的中断数，包括时钟中断

　　cs: 每秒的环境(上下文)切换次数

　　CPU

　　按 CPU 的总使用百分比来显示

　　us: CPU 使用时间

　　sy: CPU 系统使用时间

　　id: 闲置时间

　　准测

　　更多vmstat使用信息

　　第二种：用iostat

　　安装:

　　Iostat 是 sysstat 工具集的一个工具，需要安装。

　　Centos的安装方式是：

　　yum install sysstat

　　Ubuntu的安装方式是：

　　aptitude install sysstat

　　使用：

　　iostat -dx 显示磁盘扩展信息

　　root@fileapp:~# iostat -dx

　　r/s 和 w/s 分别是每秒的读操作和写操作，而rKB/s 和wKB/s 列以每秒千字节为单位显示了读和写的数据量

　　如果这两对数据值都很高的话说明磁盘io操作是很频繁。

+++++++++++++++++++++++++++++++++++++

linux wa%过高，iostat查看io状况

1, 安装  iostat  

　　yum install sysstat

之后就可以使用 iostat 命令了，

2，入门使用

　　iostat -d -k 2

参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；2表示，数据显示每隔2秒刷新一次。

tps：该设备每秒的传输次数（Indicate the number of transfers per second that were issued to the device.）。”一次传输”意思是”一次I/O请求”。多个逻辑请求可能会被合并为”一次I/O请求”。”一次传输”请求的大小是未知的。kB_read/s：每秒从设备（drive expressed）读取的数据量；

kB_wrtn/s：每秒向设备（drive expressed）写入的数据量；

kB_read：读取的总数据量；kB_wrtn：写入的总数量数据量；这些单位都为Kilobytes。

指定监控的设备名称为sda，该命令的输出结果和上面命令完全相同。

iostat -d sda 2

默认监控所有的硬盘设备，现在指定只监控sda。 

3, -x 参数

iostat还有一个比较常用的选项 -x ，该选项将用于显示和io相关的扩展数据。

iostat -d -x -k 1 10

输出信息的含义

。

4, 常见用法

iostat -d -k#查看TPS和

吞吐量

信息(磁盘读写速度单位为KB)

iostat -d -m#查看TPS和吞吐量信息(磁盘读写速度单位为MB)

iostat -d -x -k#查看设备使用率（%util）、响应时间（await） iostat -c 1 10 #查看cpu状态

5, 实例分析

iostat -d -k 1 | grep vda

Device:tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn

sda60…

sda99…

sda83…

sda18…

sda46…

sda27…

上面看到，磁盘每秒传输次数平均约400；每秒磁盘读取约5MB，写入约1MB。

iostat -d -x -k 1

Device:    rrqm/s wrqm/s  r/s  w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz  await  svctm  %util

sda.56  28.31  7.84 31……..80  2.61  10.29

sda.98  24.75 419.80  6……..70  2.00  85.25

sda.06  41.84 444.90 54……..21  1.85  92.24

可以看到磁盘的平均响应时间80。磁盘响应正常，但是已经很繁忙了。

可以看到磁盘的平均响应时间90。磁盘响应正常，但是已经很繁忙了。

await：  每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了

svctm    表示平均每次设备I/O操作的服务时间（以毫秒为单位）。如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，

如果await的值远高于svctm的值，则表示I/O队列等待太长，  系统上运行的

应用程序

将变慢。

%util： 在统计时间内所有处理IO时间，除以总共统计时间

所以该参数暗示了设备的繁忙程度

。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

也可以使用下面的命令，同时显示cpu和磁盘的使用情况

等待时间超过5ms, 磁盘io有问题

如何提高Linux下块设备IO的整体性能

前言：本文主要讲解Linux IO调度层的三种模式：cfp、deadline和noop，并给出各自的优化和适用场景建议掘历。

IO调度发生在Linux内核的IO调度层。租档这个层次是针对Linux的整体IO层次体系来说的。从read()或者write()系统调用的角度来说，Linux整体IO体系可以分为七层，它们分别是：

VFS层： 虚拟文件系统层。由于内核要跟多种文件系统打交道，而每一种文件系统所实现的数据结构和相关方法都可能不尽相同，所以，内核抽象了这一层，专门用来适配各种文件系统，并对外提供统一操作接口。

文件系统层： 不同的文件系统实现自己的操作过程，提供自己特有的特征，具体不多说了，大家愿意的话自己去看代码即可。

页缓存层： 负责真对page的缓存。

通用块层： 由于绝大多数情况的io操作是跟块设备打交道，所以Linux在此提供了一个类似vfs层的块设备操作抽象层。下层对接各种不同属性的块设备，对上提供统一的Block IO请求标准。

IO调度层 ：因为绝大多数的块设备都是类似磁盘这样的设备，所以有必要根据这类设备的特点以及应用的不同特点来设置一些不同的调度算法和队列。以便在不同的应用环境下有针对性的提高磁盘的读写效率，这里就是大名鼎鼎的Linux电梯所起作用的地方。针对机械硬盘的各种调度方法就是在这实现的。

块设备驱动层： 驱动层对外提供相对比较高级的设备操作接口，往往是C语言的，而下层对接设备本身的操作方法和规范。

块设备层： 这层就是具体的物理设备了，定义了各种真对设备操作方法和规范。

有一个已经整理好的，非常经典，一图胜千言：

我们今天要研究的内容主要在IO调度这一层。

它要解决的核心问题是，如何提高块设备IO的整体性能？这一层也主要是针对机械硬盘结构而设计的。

众所周知，机械硬盘的存储介质是磁盘，磁头在盘片上移动进行磁道寻址，行为类似播放一张唱片。

这种结构的特点是，顺序访问时吞吐量较高，但是如果一旦对盘片有随机访问，那么大量的时间都会浪费在磁头的移动上，这时候就会导致每次IO的响应时间变长，极大的降低IO的响应速度。

磁头在盘片上寻道的操作，类似电梯调度，实际上在最开始的时期，Linux把这个算法命名为Linux电梯算法，即：

如果在寻道的过程中，能把顺序路过的相关磁道的数据请求都“顺便”处理掉，那么就可以在比较小影响响应速度的前提下，提高整体IO的吞吐量。

这就是我们为什么要设计IO调度算法的原因。

目前在内核中默认开启了三种算法/模式：noop，cfq和deadline。严格算应该是两种：

因为之一种叫做noop，就是空操作调度算法，也就是没有任何调度操作，并不对io请求进行排序，仅仅做适当的io合并的一个fifo队列。

目前内核中默认的调度算法应该是cfq，叫做完全公平队列调度。这个调度算法人如其名，它试图给所有进程提供一个完全公平的IO操作环境。

注：请大家一定记住这个词语，cfq，完全公平队列调度，不然下文就没法看了。

cfq为每个进程创建一个同步IO调度队列，并默认以时间片和请求数限定的方式分配IO资源，以此保证每个进程的IO资源占用是公平的，cfq还实现了针对进程级别的优先级调度，这个我们后面会详细解释。

查看和修改IO调度算法的方法是：

cfq是通用服务器比较好的IO调度算法选择，对桌面用户也是比较好的选择。

但是对于很多IO压力较大的场景就并不是判型搜很适应，尤其是IO压力集中在某些进程上的场景。

因为这种场景我们需要更多的满足某个或者某几个进程的IO响应速度，而不是让所有的进程公平的使用IO，比如数据库应用。

deadline调度（最终期限调度）就是更适合上述场景的解决方案。deadline实现了四个队列：

其中两个分别处理正常read和write，按扇区号排序，进行正常io的合并处理以提高吞吐量。因为IO请求可能会集中在某些磁盘位置，这样会导致新来的请求一直被合并，可能会有其他磁盘位置的io请求被饿死。

另外两个处理超时read和write的队列，按请求创建时间排序，如果有超时的请求出现，就放进这两个队列，调度算法保证超时（达到最终期限时间）的队列中的请求会优先被处理，防止请求被饿死。

不久前，内核还是默认标配四种算法，还有一种叫做as的算法（Anticipatory scheduler），预测调度算法。一个高大上的名字，搞得我一度认为Linux内核都会算命了。

结果发现，无非是在基于deadline算法做io调度的之前等一小会时间，如果这段时间内有可以合并的io请求到来，就可以合并处理，提高deadline调度的在顺序读写情况下的数据吞吐量。

其实这根本不是啥预测，我觉得不如叫撞大运调度算法，当然这种策略在某些特定场景差效果不错。

但是在大多数场景下，这个调度不仅没有提高吞吐量，还降低了响应速度，所以内核干脆把它从默认配置里删除了。毕竟Linux的宗旨是实用，而我们也就不再这个调度算法上多费口舌了。

1、cfq：完全公平队列调度

cfq是内核默认选择的IO调度队列，它在桌面应用场景以及大多数常见应用场景下都是很好的选择。

如何实现一个所谓的完全公平队列（Completely Fair Queueing）？

首先我们要理解所谓的公平是对谁的公平？从操作系统的角度来说，产生操作行为的主体都是进程，所以这里的公平是针对每个进程而言的，我们要试图让进程可以公平的占用IO资源。

那么如何让进程公平的占用IO资源？我们需要先理解什么是IO资源。当我们衡量一个IO资源的时候，一般喜欢用的是两个单位，一个是数据读写的带宽，另一个是数据读写的IOPS。

带宽就是以时间为单位的读写数据量，比如，100Mbyte/s。而IOPS是以时间为单位的读写次数。在不同的读写情境下，这两个单位的表现可能不一样，但是可以确定的是，两个单位的任何一个达到了性能上限，都会成为IO的瓶颈。

从机械硬盘的结构考虑，如果读写是顺序读写，那么IO的表现是可以通过比较少的IOPS达到较大的带宽，因为可以合并很多IO，也可以通过预读等方式加速数据读取效率。

当IO的表现是偏向于随机读写的时候，那么IOPS就会变得更大，IO的请求的合并可能性下降，当每次io请求数据越少的时候，带宽表现就会越低。

从这里我们可以理解，针对进程的IO资源的主要表现形式有两个： 进程在单位时间内提交的IO请求个数和进程占用IO的带宽。

其实无论哪个，都是跟进程分配的IO处理时间长度紧密相关的。

有时业务可以在较少IOPS的情况下占用较大带宽，另外一些则可能在较大IOPS的情况下占用较少带宽，所以对进程占用IO的时间进行调度才是相对最公平的。

即，我不管你是IOPS高还是带宽占用高，到了时间咱就换下一个进程处理，你爱咋样咋样。

所以，cfq就是试图给所有进程分配等同的块设备使用的时间片，进程在时间片内，可以将产生的IO请求提交给块设备进行处理，时间片结束，进程的请求将排进它自己的队列，等待下次调度的时候进行处理。这就是cfq的基本原理。

当然，现实生活中不可能有真正的“公平”，常见的应用场景下，我们很肯能需要人为的对进程的IO占用进行人为指定优先级，这就像对进程的CPU占用设置优先级的概念一样。

所以，除了针对时间片进行公平队列调度外，cfq还提供了优先级支持。每个进程都可以设置一个IO优先级，cfq会根据这个优先级的设置情况作为调度时的重要参考因素。

优先级首先分成三大类：RT、BE、IDLE，它们分别是实时（Real Time）、更佳效果（Best Try）和闲置（Idle）三个类别，对每个类别的IO，cfq都使用不同的策略进行处理。另外，RT和BE类别中，分别又再划分了8个子优先级实现更细节的QOS需求，而IDLE只有一个子优先级。

另外，我们都知道内核默认对存储的读写都是经过缓存（buffer/cache）的，在这种情况下，cfq是无法区分当前处理的请求是来自哪一个进程的。

只有在进程使用同步方式（sync read或者sync wirte）或者直接IO（Direct IO）方式进行读写的时候，cfq才能区分出IO请求来自哪个进程。

所以，除了针对每个进程实现的IO队列以外，还实现了一个公共的队列用来处理异步请求。

当前内核已经实现了针对IO资源的cgroup资源隔离，所以在以上体系的基础上，cfq也实现了针对cgroup的调度支持。

总的来说，cfq用了一系列的数据结构实现了以上所有复杂功能的支持，大家可以通过源代码看到其相关实现，文件在源代码目录下的block/cfq-iosched.c。

1.1 cfq设计原理

在此，我们对整体数据结构做一个简要描述：首先，cfq通过一个叫做cfq_data的数据结构维护了整个调度器流程。在一个支持了cgroup功能的cfq中，全部进程被分成了若干个contral group进行管理。

每个cgroup在cfq中都有一个cfq_group的结构进行描述，所有的cgroup都被作为一个调度对象放进一个红黑树中，并以vdisktime为key进行排序。

vdisktime这个时间纪录的是当前cgroup所占用的io时间，每次对cgroup进行调度时，总是通过红黑树选择当前vdisktime时间最少的cgroup进行处理，以保证所有cgroups之间的IO资源占用“公平”。

当然我们知道，cgroup是可以对blkio进行资源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime时间增长较慢，分配比例小的vdisktime时间增长较快，快慢与分配比例成正比。

这样就做到了不同的cgroup分配的IO比例不一样，并且在cfq的角度看来依然是“公平“的。

选择好了需要处理的cgroup（cfq_group）之后，调度器需要决策选择下一步的service_tree。

service_tree这个数据结构对应的都是一系列的红黑树，主要目的是用来实现请求优先级分类的，就是RT、BE、IDLE的分类。每一个cfq_group都维护了7个service_trees，其定义如下：

其中service_tree_idle就是用来给IDLE类型的请求进行排队用的红黑树。

而上面二维数组，首先之一个维度针对RT和BE分别各实现了一个数组，每一个数组中都维护了三个红黑树，分别对应三种不同子类型的请求，分别是：SYNC、SYNC_NOIDLE以及ASYNC。

我们可以认为SYNC相当于SYNC_IDLE并与SYNC_NOIDLE对应。idling是cfq在设计上为了尽量合并连续的IO请求以达到提高吞吐量的目的而加入的机制，我们可以理解为是一种“空转”等待机制。

空转是指，当一个队列处理一个请求结束后，会在发生调度之前空等一小会时间，如果下一个请求到来，则可以减少磁头寻址，继续处理顺序的IO请求。

为了实现这个功能，cfq在service_tree这层数据结构这实现了SYNC队列，如果请求是同步顺序请求，就入队这个service tree，如果请求是同步随机请求，则入队SYNC_NOIDLE队列，以判断下一个请求是否是顺序请求。

所有的异步写操作请求将入队ASYNC的service tree，并且针对这个队列没有空转等待机制。

此外，cfq还对SSD这样的硬盘有特殊调整，当cfq发现存储设备是一个ssd硬盘这样的队列深度更大的设备时，所有针对单独队列的空转都将不生效，所有的IO请求都将入队SYNC_NOIDLE这个service tree。

每一个service tree都对应了若干个cfq_queue队列，每个cfq_queue队列对应一个进程，这个我们后续再详细说明。

cfq_group还维护了一个在cgroup内部所有进程公用的异步IO请求队列，其结构如下：

异步请求也分成了RT、BE、IDLE这三类进行处理，每一类对应一个cfq_queue进行排队。

BE和RT也实现了优先级的支持，每一个类型有IOPRIO_BE_NR这么多个优先级，这个值定义为8，数组下标为0-7。

我们目前分析的内核代码版本为Linux 4.4，可以看出，从cfq的角度来说，已经可以实现异步IO的cgroup支持了，我们需要定义一下这里所谓异步IO的含义，它仅仅表示从内存的buffer/cache中的数据同步到硬盘的IO请求，而不是aio(man 7 aio)或者linux的native异步io以及libaio机制，实际上这些所谓的“异步”IO机制，在内核中都是同步实现的（本质上冯诺伊曼计算机没有真正的“异步”机制）。

我们在上面已经说明过，由于进程正常情况下都是将数据先写入buffer/cache，所以这种异步IO都是统一由cfq_group中的async请求队列处理的。

那么为什么在上面的service_tree中还要实现和一个ASYNC的类型呢？

这当然是为了支持区分进程的异步IO并使之可以“完全公平”做准备喽。

实际上在最新的cgroup v2的blkio体系中，内核已经支持了针对buffer IO的cgroup限速支持，而以上这些可能容易混淆的一堆类型，都是在新的体系下需要用到的类型标记。

新体系的复杂度更高了，功能也更加强大，但是大家先不要着急，正式的cgroup v2体系，在Linux 4.5发布的时候会正式跟大家见面。

我们继续选择service_tree的过程，三种优先级类型的service_tree的选择就是根据类型的优先级来做选择的，RT优先级更高，BE其次，IDLE更低。就是说，RT里有，就会一直处理RT，RT没了再处理BE。

每个service_tree对应一个元素为cfq_queue排队的红黑树，而每个cfq_queue就是内核为进程（线程）创建的请求队列。

每一个cfq_queue都会维护一个rb_key的变量，这个变量实际上就是这个队列的IO服务时间（service time）。

这里还是通过红黑树找到service time时间最短的那个cfq_queue进行服务，以保证“完全公平”。

选择好了cfq_queue之后，就要开始处理这个队列里的IO请求了。这里的调度方式基本跟deadline类似。

cfq_queue会对进入队列的每一个请求进行两次入队，一个放进fifo中，另一个放进按访问扇区顺序作为key的红黑树中。

默认从红黑树中取请求进行处理，当请求的延时时间达到deadline时，就从红黑树中取等待时间最长的进行处理，以保证请求不被饿死。

这就是整个cfq的调度流程，当然其中还有很多细枝末节没有交代，比如合并处理以及顺序处理等等。

1.2 cfq的参数调整

理解整个调度流程有助于我们决策如何调整cfq的相关参数。所有cfq的可调参数都可以在/sys/class/block/sda/queue/iosched/目录下找到，当然，在你的系统上，请将sda替换为相应的磁盘名称。我们来看一下都有什么：

这些参数部分是跟机械硬盘磁头寻道方式有关的，如果其说明你看不懂，请先补充相关知识：

back_seek_max:磁头可以向后寻址的更大范围，默认值为16M。

back_seek_penalty:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的。

以上两个是为了防止磁头寻道发生抖动而导致寻址过慢而设置的。基本思路是这样，一个io请求到来的时候，cfq会根据其寻址位置预估一下其磁头寻道成本。

设置一个更大值back_seek_max，对于请求所访问的扇区号在磁头后方的请求，只要寻址范围没有超过这个值，cfq会像向前寻址的请求一样处理它。

再设置一个评估成本的系数back_seek_penalty，相对于磁头向前寻址，向后寻址的距离为1/2(1/back_seek_penalty)时，cfq认为这两个请求寻址的代价是相同。

这两个参数实际上是cfq判断请求合并处理的条件限制，凡事复合这个条件的请求，都会尽量在本次请求处理的时候一起合并处理。

fifo_expire_async:设置异步请求的超时时间。

同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。

当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理。

fifo_expire_sync:这个参数跟上面的类似，区别是用来设置同步请求的超时时间。

slice_idle:参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。

一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。

当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能。

group_idle:这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。

在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。

这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。

在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生。

low_latency:这个是用来开启或关闭cfq的低延时（low latency）模式的开关。

当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。

这将有利于对吞吐量的公平（默认是对时间片分配的公平）。

关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的。

我们已经知道cfq设计上有“空转”（idling）这个概念，目的是为了可以让连续的读写操作尽可能多的合并处理，减少磁头的寻址操作以便增大吞吐量。

如果有进程总是很快的进行顺序读写，那么它将因为cfq的空转等待命中率很高而导致其它需要处理IO的进程响应速度下降，如果另一个需要调度的进程不会发出大量顺序IO行为的话，系统中不同进程IO吞吐量的表现就会很不均衡。

就比如，系统内存的cache中有很多脏页要写回时，桌面又要打开一个浏览器进行操作，这时脏页写回的后台行为就很可能会大量命中空转时间，而导致浏览器的小量IO一直等待，让用户感觉浏览器运行响应速度变慢。

这个low_latency主要是对这种情况进行优化的选项，当其打开时，系统会根据target_latency的配置对因为命中空转而大量占用IO吞吐量的进程进行限制，以达到不同进程IO占用的吞吐量的相对均衡。这个开关比较合适在类似桌面应用的场景下打开。

target_latency:当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度。

quantum:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效。

slice_sync:当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为：time_slice = slice_sync + (slice_sync/5 * (4 – prio))。这个参数对同步请求有效。

slice_async:这个值跟上一个类似，区别是对异步请求有效。

slice_async_rq:这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的更大个数还跟相关进程被设置的io优先级有关。

1.3 cfq的IOPS模式

我们已经知道，默认情况下cfq是以时间片方式支持的带优先级的调度来保证IO资源占用的公平。

高优先级的进程将得到更多的时间片长度，而低优先级的进程时间片相对较小。

当我们的存储是一个高速并且支持NCQ（原生指令队列）的设备的时候，我们更好可以让其可以从多个cfq队列中处理多路的请求，以便提升NCQ的利用率。

此时使用时间片的分配方式分配资源就显得不合时宜了，因为基于时间片的分配，同一时刻最多能处理的请求队列只有一个。

这时，我们需要切换cfq的模式为IOPS模式。切换方式很简单，就是将slice_idle=0即可。内核会自动检测你的存储设备是否支持NCQ，如果支持的话cfq会自动切换为IOPS模式。

另外，在默认的基于优先级的时间片方式下，我们可以使用ionice命令来调整进程的IO优先级。进程默认分配的IO优先级是根据进程的nice值计算而来的，计算方法可以在man ionice中看到，这里不再废话。

2、deadline：最终期限调度

deadline调度算法相对cfq要简单很多。其设计目标是：

在保证请求按照设备扇区的顺序进行访问的同时，兼顾其它请求不被饿死，要在一个最终期限前被调度到。

我们知道磁头对磁盘的寻道是可以进行顺序访问和随机访问的，因为寻道延时时间的关系，顺序访问时IO的吞吐量更大，随机访问的吞吐量小。

如果我们想为一个机械硬盘进行吞吐量优化的话，那么就可以让调度器按照尽量复合顺序访问的IO请求进行排序，之后请求以这样的顺序发送给硬盘，就可以使IO的吞吐量更大。

但是这样做也有另一个问题，就是如果此时出现了一个请求，它要访问的磁道离目前磁头所在磁道很远，应用的请求又大量集中在目前磁道附近。

导致大量请求一直会被合并和插队处理，而那个要访问比较远磁道的请求将因为一直不能被调度而饿死。

linux 进程占用了io的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于linux 进程占用了io,解决Linux进程占用IO的问题,linux查看磁盘io的几种方法,如何提高Linux下块设备IO的整体性能的信息别忘了在本站进行查找喔。