LinuxIO性能优化基础工具和实践

LinuxIO性能优化基础工具和实践基础篇-Linux

IO

stackoverview基础篇-readsyscallIOstack工具篇-iostat数据可靠吗工具篇-blktrace原理和应用工具篇-debugfs应用Cacheserver机械盘IO性能瓶颈分析实践篇-IO性能优化之文件压缩实践篇-IO性能优化之shortstroking实践篇-IO性能优化之减小元数据写入实践篇-IO性能优化之SSD减少机械盘的IOPSLinuxIOstackoverviewP1Linux

IOstackoverviewP2Linux

IOstackoverviewP3Linux

IOstackoverviewP4readsyscallIOstackblockcorelayerblk-core.c/elevator.cblk_queue_bioIOstack(blockcore)blk_partition_remapblk_queue_bio__generic_make_requestelv_queue_empty?blk_plug_deviceelv_mergeBACK_MERGEFRONT_MERGEget_request_wait__elv_add_requestq->request_fn__generic_unplug_deviceelv_insertscsi_request_fnblk_peek_requestblktraceabstract功能：blktrace是一个针对Linux内核块设备I/O层的跟踪工具，可以获取I/O请求队列的各种详细的情况，如IO请求提交，入队，合并，完成等等一些列的信息：进行读写的进程名称、进程号、执行时间、读写的物理块号、块大小等。架构：blktrace分内核空间和用户空间两部分实现，内核空间里面主要是给块层IO路径上的关键点添加tracepoint,再通过debugfs输出。工具组成：blktrace：收集原始信息blkparse：格式化输出blktrace

eventsblktrace状态含义及所属tracepointblktraceeventsatIOstackQblk_partition_remapblk_queue_bio__generic_make_requestelv_queue_empty?blk_plug_deviceelv_mergeAPBACK_MERGEFRONT_MERGENO_MERGEget_request_wait__elv_add_requestq->request_fn__generic_unplug_deviceFMtrace_block_sleeprqget_requestSGelv_insertIUnplugduetoTimeoutorthrottlescsi_request_fnscsi_end_requestblk_end_requestblk_peek_requestopen_softirq(BLOCK_SOFTIRQ,blk_done_softirq)scsi_softirq_doneCDblktrace

usageBlktrace使用(CONFIG_BLK_DEV_IO_TRACE)#mount-tdebugfsnone/sys/kernel/debug#blktrace-d/dev/sdb-o-|blkparse-i--oblk.parsedblktrace

outputBlktrace输出解析Blktrace输出解析数值说明8,64major/minor1CPUID1Sequence0.000000000Tiemstamp6936PidAActionidentifitorRR/Wtype(opt:R|W|D|B|S)646562863+16<-(8,65)646562800Sectorremap(basedontracepoint)blktrace:blkiomon

blktrace实时监控IO#blktrace/dev/sde-aissue-acomplete-w50-o-|blkiomon-I10-h-blktrace

filter(shell)#!/bin/bashforpatternin`catsde.log.trim|grep"C"|awk'{print$8}'`do catsde.log.trim|grep$pattern>tmp_trunk s_time=`cattmp_trunk|head-n1|awk'{print$4}'` e_time=`cattmp_trunk|tail-n1|awk'{print$4}'` diff_time=`echo"$e_time-$s_time"|bc` diff_time=`printf"%.2f"$diff_time` if[`echo"$diff_time>0.5"|bc`-eq1];then cattmp_trunk echo"======duration(s):$diff_time" fidoneblktrace分析性能IO性能由好变差的blktrace信息，筛选'issued'，对比发送到驱动队列IO的大小#catblk.parsed-ok2bad|grepDblktrace分析性能IO性能由好变差的blktrace信息，筛选‘Complete'，对比驱动完成请求的大小#catblk.parsed-ok2bad|grepCblktrace分析性能IO差IO不能合并的blktrace信息IO好IO可以合并的blktrace信息blktrace分析性能debugfs

usageblktrace有感兴趣的sectorNo.?根据sectorNo.找到文件(sector:1305783464)注意：输出的文件路径不包含挂载目录。sectorNo.是分区内部的偏移量(blktrace看到的'Aevent'的'<-'右边部分)。$catfind_blkparse_A_block.shforsectorin`cattxt|grepA|awk'{print$NF}'|sort|uniq`do block=`echo$sector/8|bc`; inode=`debuge4fs-R"icheck$block"/dev/sda32>&1|tail-n1|awk'{print$2}'` echo-n"inode$inode\t" debuge4fs-R"ncheck$inode"/dev/sda32>&1|tail-n1doneiostat

abstract几个问题：iostat磁盘数据源头：/proc/diskstats/proc/diskstats何时更新iostat如何计算输出/proc/diskstats信息iostat靠谱？哪些指标存在疑问基本使用：-t打印时间戳，-xextended模式输出，-k吞吐率以KB为单位(-mMB)/proc/diskstats前三个字段，主次设备号以及盘符。有统计意义的是后面11个域：域1-4表示读请求累计统计值；域5-8表示写请求统计值；域9-11表示磁盘（分区）的累计统计值。第1个域：读请求成功完成总数。

=>r/s,avgrq-sz第2个域：读请求合并的总数，即邻近的请求合并成一个请求，一次IO操作。

=>rrqm/s第3个域：读扇区的总数(512B)。

=>rsec/s=>rkB/s,avgrq-sz第4个域：读请求花费的总毫秒数。

=>r_await第5-8域：同1-4，表示写请求的统计。第9个域：当前(实时)未完成的I/O请求个数。

=>不直接输出，但用于估算avgqu-sz第10个域：磁盘或分区花在I/O操作上的毫秒数，表示磁盘或者分区忙碌的时间。

=>%util,svctm第11个域：磁盘或分区花在I/O操作上的毫秒数的加权(域9*域10的增量)

=>avgqu-sz/proc/diskstats何时更新structdisk_stats{unsignedlongsectors[2];/*READs/WRITEs,increaseonIOrequestfinish

@blk_end_request<-blk_account_io_completion

*/unsignedlongios[2];/*increaseonIOrequestfinish

@blk_end_request<-blk_account_io_done*/unsignedlongmerges[2];/*increaseonIOblock-layerentry

@q->make_request_fni.e.blk_queue_bio*/unsignedlongticks[2];/*increaseonIOrequestfinish

@blk_end_request<-blk_account_io_done.INCREMENT:jiffies-req->start_time*/unsignedlongio_ticks;/*increaseonI/Ostart/merge/finish/diskstats_show

INCREMENT:now-part->stamp

*/unsignedlongtime_in_queue;/*thesameasio_ticksupdatebutwith

INCREMENT:

part_in_flight(part)*(now-part->stamp)

*/};未完成的请求(IO调度器队列或者devicequeue)：part->in_flight[rw]++;/*increaseonIOrequestblock-layerentry

@q->make_request_fni.e.blk_queue_bio

*/part->in_flight[rw]--;/*decreaseonIOrequestfinish,i.e.

@blk_end_request<-blk_account_io_done*/IO活跃点采样iostat计算输出/proc/diskstatsiostat计算输出/proc/diskstatsrrqm/s:IO调度器层面读请求每秒被merge的次数#rd_merges[1]-rd_merges[0]r/s:磁盘每秒完成读请求的次数#rd_ios[1]-rd_ios[0]avgrq-sz:磁盘每秒完成的读请求平均大小(512B)#(rd_sec+wr_sec)/nr_iosavgqu-sz:平均队列长度(IO调度层以及驱动队列所有未完成请求个数加权平均)#(rq_ticks[1]-rq_ticks[0])/1000await:请求的平均等待时间(请求创建(进入块层)到请求完成(磁盘返回)的时间)#((rd_ticks[1]-rd_ticks[0])+(wr_ticks[1]-wr_ticks[0]))/nr_iosutil:磁盘使用率，准确意思是磁盘驱动忙碌的时间(块层或以下有活跃的request)#(tot_ticks[1]-tot_ticks[0])/1000*100%svctm:请求被磁盘服务的平均时间(根据磁盘驱动活跃时间的计算平均值)#util/nr_iosiostat靠谱？哪些指标存在疑问svctm：请求被磁盘服务的平均时间(仅仅根据块层的驱动活跃时间计算，实际上没有准确记录磁盘物理上处理请求的具体时间)manpage：Theaverageservicetime(svctmfield)valueismeaningless,asI/Ostatisticsarenowcalculatedatblocklevel,andwedon'tknowwhenthediskdriverstartstoprocessarequest.Forthisreason,thisfieldwillberemovedinafuturesysstatversion.%util：磁盘使用率，传统意义上单队列的机械盘，100%表示满负荷。但对于SSD或者raid磁盘阵列可以并行处理多个请求的，100%不一定意味着跑满。比如串行的每个jiffies都有请求到来，按iostat的计算方法，驱动服务时间就是跑满的(每个时间点都有活跃的请求)。但是实际上每个jiffiesSSD或者raid可以并发多个请求。manpage：PercentageofelapsedtimeduringwhichI/Orequestswereissuedtothedevice(bandwidthutilizationforthedevice).Devicesaturationoccurswhenthisvalueiscloseto100%fordevicesservingrequestsserially.Butfordevicesservingrequestsinparallel,suchasRAIDarraysandmodernSSDs,thisnumberdoesnotreflecttheirperformancelimits.Forsuchdevices%utilessentiallyindicatesthepercentageoftimethatthedevicewasbusyservingatleastonerequest.Unfortunately,thistellsusnothingaboutthemaximumnumberofrequestssuchadevicecanhandle,andassuchthisvalueisuselessasasaturationindicatorforSSDsandRAIDarrays.绝大部分时候这两个指标还是有参考意义的。iostat

await/svctm异常解析Time:03:48:23PMDevice:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitsvctm%utilsda30.000.000.000.000.000.000.000.000.000.000.00Time:03:48:28PMDevice:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitsvctm%utilsda30.0021.720.004.100.0038.5218.8033.7878.30243.9099.96Time:03:48:29PMDevice:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitsvctm%utilsda30.0022.000.0045.000.00584.0025.961.733666.8010.5647.50分析：await超级大(大于1秒)：观察iostat时间戳，iostat输出因未知原因卡住5秒(实际服务器非网络原因很卡)。推测请求在很早前(如5秒前)发出，但因卡顿没有得到服务，5秒后批量完成，await接近卡顿时间。svctm(几百毫秒，根据现代磁盘的IOPS能力，正常最多20左右)超级大：svctm是某个时间段磁盘“有未完成的IO请求计时”累计的每秒平均，当前的统计interval之间只要有完成的IO，如这里4.1w/s，即按计算值输出，没有IO完成不输出。实际请求完成的时间到达不均匀(这里还可能磁盘软中断返回处理的问题)。比如磁盘一秒中发出52个请求，假设导致磁盘持续2秒忙碌，但第一秒实际只完成了2个请求，则svctm=500(1000/2=500)。第二秒完成50个，svctm=20(1000/50=20)PS.上次那批未知原因的svctm超标的机器，用dd加压读写，svctm看起来不会有问题，是因为dd产生很多的IO请求，所以svctm的指标被平均了，看起来就不高。是否因为某些特殊的SCSI磁盘指令无法及时完成？IO性能瓶颈(磁盘跑满)Throughput和IOPS两个参数是衡量存储性能的主要指标，都有上限。Throughput表示每秒数据的传输总量，即IO带宽。IOPS表示存储每秒传输IO的数量，即IO次数(主要是磁头seek)。1.磁盘跑满throughput瓶颈[root@pj16mnt]#ddif=/dev/zeroof=/mnt/test.datbs=8Mcount=256oflag=direct256+0recordsin256+0recordsout2147483648bytes(2.1GB)copied,10.772seconds,199MB/s2.磁盘跑满IOPS瓶颈[root@pj16mnt]#./seeker/dev/sdb1Seekerv2.0,2007-01-15,/how_fast_is_your_disk.htmlBenchmarking/dev/sdb1[953869MB],wait30secondsResults:69seeks/second,14.49msrandomaccesstime影响机械盘IOPS的因子IO_Time=Seek_Time+Rotation_Delay+Transfer_TimeSeek_Time磁头寻道时间(最坏情况最内圈<->最外圈)，7200rmp硬盘的平均一般4.5ms(希捷ST2000DM001读取：<8.5ms,写入：<9.5ms)。Rotation_Delay磁头旋转到目标扇区，最坏完整一圈，7200rpm硬盘平均(60s/7200)*(1/2)=4.2ms。Transfer_Time数据传输时间=IOChunkSize/MaxTransferRate，实际测试顺序度速度平均在140~150MB。IOPS=1/IO_Time=1/(SeekTime+60sec/RotationalSpeed/2+IOChunkSize/TransferRate)Seek_time和Rotaion_Delay实际和读写并发数以及数据存放是否连续有关。假设Seek_time和Rotaion_Delay按平均取值，给定不同的IO大小，IOPS：4K(1/8.73ms=114IOPS)4.5ms+4.2ms+4KB/140MB=4.5+4.2+0.03=8.73128K(1/9.6ms=104IOPS)

4.5ms+4.2ms+128KB/140MB=4.5+4.2+0.9

=9.6

512K(1/12.4ms=80IOPS)

4.5ms+4.2ms+512KB/140MB=4.5+4.2+3.7

=12.4

(512KB预读依据，传输时间和seek时间同一量级)1MB(1/15.8ms=63IOPS)

4.5ms+4.2ms+1MB/140MB=4.5+4.2+7.1=15.88MB(1/65.7ms=15IOPS)

4.5ms+4.2ms+MB/140MB=4.5+4.2+57=65.7SSD与机械盘IOPS/ThroughputCDNcacheserverIO性能瓶颈CDNcacheserver磁盘跑高iostat的通常情况(svctm正常磁盘没坏)throughput远远没有达到磁盘IO的最大吞吐量(100MB以上)，而IOPS(r/s+w/s)基本上达到SATA机械盘的IOPS上限。结论是cacheserverIO的瓶颈是存储的IOPS，IO性能优化的主要方向是减少磁盘IOPS，减少上层应用/文件系统每个请求的引发磁盘IOseek的次数。IO性能优化1-文件压缩数据压缩思想是通过CPU运算压缩数据，节省存储空间，牺牲CPU时间来换空间。首要问题是，文本信息之外的cacheobject都很难压缩(图片、视频)，线上验证过btrfs的数据压缩的效果，压缩率很低(~3%)，IO总体情况没有明显的改善。其次ext4上实现太复杂，尤其文件不是一次性写入的情况，比如分段缓存的情况(涉及到原来存储的数据读出解压，再组合一起，然后压缩写入)，如果文件原来的位置没有预留合理的空间，会引发更多的文件碎片。另外，从机械盘的IO瓶颈来看，机械磁盘绝对的吞吐量还是够强的，只要数据存储物理上是连续的，性能还是够高的。碎片引发的seek代价会更大。IO性能优化2-shortstrokeShortstroking思想ShortstrokingisatermusedinenterprisestorageenvironmentstodescribeanHDDthatispurposelyrestrictedintotalcapacitysothattheactuatoronlyhastomovetheheadsacrossasmallernumberoftotaltracks.[17]Thislimitsthemaximumdistancetheheadscanbefromanypointonthedrivetherebyreducingitsaverageseektime,butalsorestrictsthetotalcapacityofthedrive.ThisreducedseektimeenablestheHDDtoincreasethenumberofIOPSavailablefromthedrive.大意是分区限制磁盘磁头的最大可以移动的范围，可以减少seektime，提高IOPS。另外一个就是机械磁盘的外道容量大，同样的角速度扫过的面积更大，吞吐量越高。IO性能优化2-shortstrokeShortstroking

主要靠分区实现，比如分成两个区，并且第二个分区空置不用。对于那种只有一块1T系统盘的有大量空间浪费的可以考虑。文件系统修改基本不管用，因为无法保证高LBA的扇区完全不被使用，除非完全屏蔽，这个和分区也没多大区别了。ext4的维护者曾经也发过类似的patch，但是很快被否决了：IO性能优化3-减少ext4元数据写入

ext4文件系统布局IO性能优化3-减少ext4元数据写入

Squid的目录结构cache0cache1cache2cache3cache0...cache9000102...3F000102...FEFF2TDISK总共4*10*64*256=65万个底层目录65万个底层目录在磁盘中基本散开，每个子目录下的文件也跟随目录在磁盘中散开：线上的机器实际存放文件个数200万到-1000万之间IO性能优化3-减少ext4元数据写入

ext4inode/block分配inode总体原则：数据局部性1.磁盘顶层目录inode参考flex_bg的(avefreei/avefreeb/used_dirs)指标找一个的最优(空文件系统可选flex_bg不止一个，随机生成散开)2.子目录inode从父目录所在的flex_bg开始(优先)，找一个符合(min_blocks/min_inodes/max_dirs)指标范围flex_bg3.文件inode尽可能分配在父目录inode的所在的flex_bg(依据是同一个目录下的文件是相关)文件数据块分配1.delaywrite&基于extent的multi-block分配(减少碎片)，vfswriteback每次最大触发2048个block(8MB)的回写2.从文件inode所在的blockgroup分配(减少seek)，但这个hint会被下面3覆盖。3.根据文件大小选择groupprealloc或者inodeprealloc策略(减少碎片).3.1>64K(16block)的文件物理块分配共享全局的EXT4_MB_STREAM_ALLOC游标，因此有多个并发写入，会相互交叉，但是对于8MB大小的碎片认为可以忽略。3.2<=64K的文件使用percpu预分配的2MB的空间，用光了根据2来指定初始分配位置IO性能优化3-减少ext4元数据写入

activeinodespacktogether写入/删除涉及文件系统目录信息及各种元数据的更新，包括目录dentry/groupdesc/blockbitmap/inodebitmap/inodetable更新思路：需要写入的inode尽可能放在一起，包括脏目录以及文件的inode结果：没明显效果推测可能原因：aCDNcachedisk读的量更多得多，

IOPS主要主要用在读上b因为目录是预先分配的，目录创建后inode位置固定，而文件inode

根据目录来分配，并且各个底层目录inode写入很难保持步调一致，无法达到预期IO性能优化4-减少磁盘的IOPS

元数据/目录/间接块/小文件放入SSD/碎片1.CDNcache主要是读，并且多个进程同时读写，因为目录存放的文件没有相关性，读请求随机(seek多)，读文件(内存没命中)至少三次磁盘查找：

a文件目录项检索(上级dentry不在内存，则逐级查找读盘)

b文件inode信息读取(dentry->inode)

c文件数据读入(是否有碎片)，涉及访问文件间接块(index)思路：SSD的IOPS很强，正适合上述随机信息的读入，对于减缓机械盘的IOPS压力应该比较有效果。2.减少碎片，尽可能顺序读写，也能减轻磁