最近的项目需要监控机器的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统计。
如有不对,请指正。