首页 > 代码库 > 磁盘 分区 lvm之间await util的统计关系

磁盘 分区 lvm之间await util的统计关系

最近的项目需要监控机器的IO负载, 提到IO负载,首当其冲的当然是await util这两个指标。
util: 过去的一段时间内,设备处理IO请求的时间占总时间的百分比。
await: 一个请求在IOscheduler里排队时间加上物理设备处理时间 (一个IO请求从通用块设备层提交到IOscheduler时开始计算,到底层处理完这个请求再次返回到通用块层的时间差)

  • iostat和/proc/diskstats

常见的iostat sar等工具都提供了这两个指标,当然它们提供的都是一段时间的平均值。但iostat只是负责换算,并不负责这些统计数据的采集。
IO栈在处理IO请求时,采集这些统计数据。/proc/diskstats文件中以行为单位展示了每个逻辑设备的统计信息。

技术分享

总共14个字段,解释如下:
第01列 : 主设备号major
第02列 : 次设备号minor
第03列 : 设备名name
第04列 : 读请求完成总数rio
第05列 : 合并读请求总数rmerge
第06列 : 读扇区总数rsect
第07列 : 读数据花费的时间rticks,单位是ms
第08列 : 写请求完成总数wio
第09列 : 合并写请求总数wmerge
第10列 : 写扇区总数wsect
第11列 : 写数据花费时间wticks,单位是ms
第12列 : 正在进行I/O数inFlight
第13列 : IO花费时间ioticks,单位ms
第14列 : IO花费时间time_in_queue,单位ms(加了权重的)
类似iostat的工具其实都是读取这个文件再经过计算后得出磁盘的util await iops 吞吐这些信息。这个文件所有的统计结果都是累加的,
因此iostat至少需要采集两次才能计算。以rio为例,(rio1 - rio0) / interval(采集间隔 s)  就是过去interval时间 平均每秒读iops。
技术分享
先给出iostat计算await util的算法。iostat代码就省略了,不是重点。
await = ((wticks1 - wticks0) + (rticks1 - rticks0)) / ((rio1 + wio1) - (rio0 + wio0))
就是采集两次diskstats,读写总共花费的时间 / 读写请求完成个数 = 每个请求平均花费的时间即await.

util = (ioticks1 - ioticks0) / interval
采集两次diskstats,interval是两次采集的时间间隔。很好理解,过去的interval毫秒里,有多少毫秒在处理IO。占比就是磁盘的繁忙程度即util。

本文的重点是磁盘 分区 lvm间await util的统计关系。以我的虚拟机为例:有块物理盘vdb,分成了两个分区vdb1 vdb2。vdb1 vdb2又组成vg后全部分给了逻辑卷dm-0。
上面我们看到vdb vdb1 vdb2 dm-0在diskstats中都有独立的统计。那么当我读写vdb2时,会更新vdb1的统计吗?会更新vdb吗?读写dm-0呢?

从上面iostat的分析我们发现,await util这两个指标的计算跟(w/r)ticks  (w/r)io  ioticks这几个统计数据相关。下面分析下内核代码,答案自然就浮现出来了。

  • 代码分析(内核版本:2.6.28)

这里直切主题,IO栈的相关介绍请查阅其他文章。

先看两个结构体:

struct disk_stats:存储每个块设备的IO统计数据。diskstats里统计相关的除了inFlight都在这里。
后面就用这个结构来描述,请自行对应到diskstats里的列。

struct disk_stats {
    unsigned long sectors[2];   /* READs and WRITEs */
    unsigned long ios[2];
    unsigned long merges[2];
    unsigned long ticks[2];
    unsigned long io_ticks;
    unsigned long time_in_queue;
};

struct hd_struct:分区结构体。一个物理盘会有多个分区,每个分区由一个hd_struct。包括物理盘自身也对应一个hd_struct。
struct hd_struct {
    sector_t start_sect;
    sector_t nr_sects;
    struct device __dev;
    struct kobject *holder_dir;
    int policy, partno;     //partno为分区编号,磁盘自身该值为0
    ...
    unsigned long stamp;    //一个时间戳,统计ioticks时用到
    int in_flight;          //该分区当前有多少个请求正在处理。对应diskstats里的inFlight
#ifdef  CONFIG_SMP
    struct disk_stats *dkstats; //包含一个disk_stats存储统计信息
#else
    struct disk_stats dkstats;
#endif
    struct rcu_head rcu_head;
};

 

 通用块设备层向IOscheduler提交IO请求时,需要把struct bio转换成struct request。然后调用IOscheduler队列的入队函数将request push进等待队列。入队函数注册为__make_request。

static int __make_request(struct request_queue *q, struct bio *bio)
{
    struct request *req;
get_rq:
    ...
    req = get_request_wait(q, rw_flags, bio);  //根据bio创建request
    ...
    init_request_from_bio(req, bio);        //初始化request
    ...
    add_request(q, req);                //将request add进queue
    ...
end_io:
    bio_endio(bio, err);
    return 0;
}

 __make_request简单来说就是根据传入的bio,首先判断能否merge,能则merge。否则创建新的request。然后将request 加进queue里。
当然merge部分的代码被省略了。
跟await相关的代码封装在init_request_from_bio里,看看:

void init_request_from_bio(struct request *req, struct bio *bio)
{
    ....
    req->errors = 0;
    req->hard_sector = req->sector = bio->bi_sector;
    req->ioprio = bio_prio(bio);
    req->start_time = jiffies;      //这个请求push进queue时的jiffies
    blk_rq_bio_prep(req->q, req, bio);
}

 init_request_from_bio在请求进入queue之前用req->start_time记录当前时间戳,等底层执行完该请求的时刻跟req->start_time求差,不就是该请求的await么。
但内核统计是以分区为单位的,所以只是将时间差累加到分区对应的disk_stats.ticks里。由iostat再去算出平均的await。
跟util相关的代码在add_request里。

static inline void add_request(struct request_queue *q, struct request *req)
{
    drive_stat_acct(req, 1);
    __elv_add_request(q, req, ELEVATOR_INSERT_SORT, 0);
}

static void drive_stat_acct(struct request *rq, int new_io)
{
    struct hd_struct *part;
    int rw = rq_data_dir(rq);
    int cpu;

    cpu = part_stat_lock();
    part = disk_map_sector_rcu(rq->rq_disk, rq->sector);    //用req找到分区part

    part_round_stats(cpu, part);        //更新分区统计
    part_inc_in_flight(part);

}

 drive_stat_acct函数里,通过req找到分区part,然后更新分区的统计数据。
其中part_round_stats函数更新disk_stats.io_ticks。part_inc_in_flight函数更新hd_struct.in_flight。

这两个指标还是息息相关的。通用块设备层每向下层下发一个request就给hd_struct.in_flight++,
底层每完成一个request,相应hd_struct.in_flight--。这样in_flight就代表当前有多少个请求正在处理。

而disk_stats.io_ticks的算法是:每次下发request或者request完成时,检查hd_struct.in_flight。如果hd_struct.in_flight=0,则认为设备这段时间空闲,否则(只要不是0,不管有多少request正在处理)就认为设备繁忙。这段时间怎么表示?上面已提到。用hd_struct.stamp记录。看下代码:

void part_round_stats(int cpu, struct hd_struct *part)
{
    unsigned long now = jiffies;    //获取当前时间戳

    if (part->partno)       //如果是分区,则同步更新主分区即物理盘的统计。
        part_round_stats_single(cpu, &part_to_disk(part)->part0, now);  
    part_round_stats_single(cpu, part, now);   //更新io_ticks
}

static void part_round_stats_single(int cpu, struct hd_struct *part,
                    unsigned long now)
{
    if (now == part->stamp)
        return;

    if (part->in_flight) {          //in_flight非0,需要更新。
        __part_stat_add(cpu, part, time_in_queue,
                part->in_flight * (now - part->stamp)); //将(now - part->stamp)*in_flight 累加到hd_struct.disk_stats.io_ticks上
        __part_stat_add(cpu, part, io_ticks, (now - part->stamp)); //将(now - part->stamp)累加到hd_struct.disk_stats.io_ticks上
    }
    part->stamp = now;      //stamp更新为当前时间
}
如果该设备是分区,同步更新其物理盘分区。in_flight非0时更新io_ticks和time_in_queue。time_in_queue累加时乘了in_flight。所以是加了权重的IO花费时间。

part_inc_in_flight函数就负责in_flight的自增了。
static inline void part_inc_in_flight(struct hd_struct *part)
{
    part->in_flight++;
    if (part->partno)       //物理盘同步自增
        part_to_disk(part)->part0.in_flight++;
}

 前面把request进入队列时的代码分析了,作为呼应,贴出request完成时的代码。
请求完成的函数栈也是很长,大概是scsi_softirq_done->...->blk_end_request->blk_end_io->end_that_request_last。

static void end_that_request_last(struct request *req, int error)
{
    struct gendisk *disk = req->rq_disk;
    ...
    if (disk && blk_fs_request(req) && req != &req->q->bar_rq) {
        unsigned long duration = jiffies - req->start_time;   //完成时间-请求时间=该请求的await
        const int rw = rq_data_dir(req);
        struct hd_struct *part;
        int cpu;

        cpu = part_stat_lock();
        part = disk_map_sector_rcu(disk, req->sector);

        part_stat_inc(cpu, part, ios[rw]);              //该分区完成读/写请求数+1
        part_stat_add(cpu, part, ticks[rw], duration);  //单个请求的await累加到分区的统计里。
        part_round_stats(cpu, part);                   //更新disk_stats.io_ticks
        part_dec_in_flight(part);                   //hd_struct.in_flight--

        part_stat_unlock();
    }

    ...
}

#define part_stat_inc(cpu, gendiskp, field)             \
    part_stat_add(cpu, gendiskp, field, 1)


#define part_stat_add(cpu, part, field, addnd)  do {            \   //addnd为1
    __part_stat_add((cpu), (part), field, addnd);               if ((part)->partno)                             __part_stat_add((cpu), &part_to_disk((part))->part0,    \       //物理盘同步+1
                field, addnd);              } while (0)

 这里除了part_stat_inc宏,其他代码跟前面的呼应,不重复展开了。每完成一个request,在part_stat_inc里将hd_struct.disk_stats.ios+1。对应到diskstats里就是wio rio了。当然物理盘也同步+1。

至此,与await util相关的统计指标都分析了。
util不管有多少请求在处理,只要in_flight非0,就认为磁盘忙碌。也就解释了很多博客都强调util 100%磁盘并不一定真的忙碌。

同时,分区和物理盘的统计关系也清晰了。更新分区统计时也会同步更新物理盘。所以物理盘的统计是其所有分区之和。

再分析下lvm。
lvm是靠Device Mapper实现的,有自己的hd_struct。其mapped_device只是一个逻辑设备,上层对lvm发起的IO请求,最终被转发到物理设备处理。
因此mapped_device的入队函数被注册为dm_request。dm_request做两件事,更新自己的IO统计,转发请求。

static int dm_request(struct request_queue *q, struct bio *bio)
{
    int r = -EIO;
    int rw = bio_data_dir(bio);
    struct mapped_device *md = q->queuedata;
    int cpu;

    cpu = part_stat_lock();             
    part_stat_inc(cpu, &dm_disk(md)->part0, ios[rw]);       //更新统计
    part_stat_add(cpu, &dm_disk(md)->part0, sectors[rw], bio_sectors(bio));
    part_stat_unlock();
    ...
    r = __split_bio(md, bio);
    up_read(&md->io_lock);
    return 0;
}

static int __split_bio(struct mapped_device *md, struct bio *bio)
{
    struct clone_info ci;
    int error = 0;
    ...
    start_io_acct(ci.io);       //更新统计
    while (ci.sector_count && !error)
        error = __clone_and_map(&ci);

    /* drop the extra reference count */
    dec_pending(ci.io, error);
    dm_table_put(ci.map);

    return 0;
}

static void start_io_acct(struct dm_io *io)
{
    struct mapped_device *md = io->md;
    int cpu;
    io->start_time = jiffies;
    cpu = part_stat_lock();
    part_round_stats(cpu, &dm_disk(md)->part0);
    part_stat_unlock();
    dm_disk(md)->part0.in_flight = atomic_inc_return(&md->pending);
}

 可以看出,lvm虽然是逻辑设备。但是IO统计是独立的。因此读写lvm时,首先更新lvm的IO统计,请求被转发到分区时更新该分区的IO统计,当然该分区所属的物理盘也会更新。

  • 总结:

读写lvm,更新lvmIO统计 更新该请求所属分区的IO统计(lvm可能由多个分区组成)  更新物理盘IO统计。
读写分区,更新分区IO统计  更新物理盘IO统计。
读写盘,只更新物理盘IO统计。

如有不对,请指正。

磁盘 分区 lvm之间await util的统计关系