Skip to content

Instantly share code, notes, and snippets.

@prtitrz
Created May 16, 2012 03:06
Show Gist options
  • Save prtitrz/2706994 to your computer and use it in GitHub Desktop.
Save prtitrz/2706994 to your computer and use it in GitHub Desktop.
浅析trace的处理

#浅析trace的处理 由于作者见识有限,本文仅对WebSearch2.spc这一trace进行讲解分析。

##What is trace trace这个词有着很多的含义,在英文维基中计算机科学分类中就有5个代指。而实验室平常所说到的trace应该是特指IO trace。说来惭愧,一直在网上找不到实验室用的IO trace的权威定义,根据之前跟诸位学长的探讨,自己的拙见如下:

IO trace就是一些真实在线系统的运行数天的磁盘所接受的IO请求记录。

而IO trace也有着许多格式,例如本文提到的WebSearch2就来自于一个流行的搜索引擎,是真实的工作实际负载,它的格式定义遵循SPC trace文本规范[1]。厂商之所以将其真实的负载公布出来,也是为了让学术界对这些数据进行分析科研,让学术界和工业界紧密的结合,达到双赢的目的。

##Download

$ wget http://skuld.cs.umass.edu/traces/storage/WebSearch2.spc.bz2
$ bunzip2 WebSearch2.spc.bz2

这样,我们就得到本文要分析的trace文件WebSearch2.spc

##Cognize 拿到一个trace,首先要了解它的基本格式:

$ head WebSearch2.spc
0,21741712,24576,R,0.000774
1,18960512,24576,R,0.000938
1,32558896,8192,R,0.008117
2,21841504,24576,R,0.008252
2,21841568,8192,R,0.008388
0,18600896,8192,R,0.011178
0,30860080,8192,R,0.012703
0,30503312,8192,R,0.016801
1,32558944,8192,R,0.020748
1,20802624,8192,R,0.025710
$ wc -l WebSearch2.spc
4579809 WebSearch2.spc

可以看到trace由400w多行的数据构成,每一行都反映了一次IO请求。每行用,号作为分隔符构成5个自然域。 将每个自然域以$i来标识,则每个自然域分别代表:

  • $1 Application specific unit (ASU) 设备号
  • $2 Logical block address (LBA) 逻辑块地址
  • $3 Size 请求的数据长度
  • $4 Opcode 读请求或者写请求,WebSearch2中只有读请求
  • $5 Timestamp 请求下达的时间戳

##Analysis 对trace及其格式有了基本的认识之后,我们再来做进一步的分析探讨。我们研究的意义是对trace进行重播,让我们研究的系统模拟真实负载下的性能。那么原先的trace并不一定适合我们想要测试研究的系统,我们要使用这一trace的时候就要对其进行重新组织。

就让我们一步步的从每个自然域来分析下WebSearch2.spc这一trace文件吧。首先来看下这个trace访问设备的频率:

$ awk 'BEGIN{FS=","};{print $1}' WebSearch2.spc| sort |uniq -c
1544375 0
1517218 1
1515918 2
    765 3
    795 4
    738 5

可以看到这个trace的IO请求主要集中于前三个设备,而且请求是均匀分布的。至于后3个设备那稀疏的请求次数,跟具体的系统有关,我们便不得而知了。

第二个作用域我们需要关心的是每个设备系统的请求的最大的逻辑块地址,这关系到我们trace重播的设计:

$ awk 'BEGIN{FS=",";max=0};{if($1==0&&$2>max){max=$2}};END{print max}' WebSearch2.spc
34967808
$ awk 'BEGIN{FS=",";max=0};{if($1==1&&$2>max){max=$2}};END{print max}' WebSearch2.spc
34662560
$ awk 'BEGIN{FS=",";max=0};{if($1==2&&$2>max){max=$2}};END{print max}' WebSearch2.spc
25949392
$ awk 'BEGIN{FS=",";max=0};{if($1==3&&$2>max){max=$2}};END{print max}' WebSearch2.spc
25949312
$ awk 'BEGIN{FS=",";max=0};{if($1==4&&$2>max){max=$2}};END{print max}' WebSearch2.spc
34643200
$ awk 'BEGIN{FS=",";max=0};{if($1==5&&$2>max){max=$2}};END{print max}' WebSearch2.spc
34951264

可以看到最大的LBA为3kw多,我们至少需要35000000×512B的磁盘空间才能满足trace的需求。

第三个作用域是请求块的大小:

$ awk 'BEGIN{FS=","};{print $3}' WebSearch2.spc| sort |uniq -c
 495744 16384
 406838 24576
 912770 32768
2764457 8192

根据SPC文档的规范,size的单位是byte,于是可以看到请求块的大小只有4种分别是8KB,16KB,24KB,32KB。而8KB的请求占大多数,32KB紧随其后。

第四个作用域是读请求或者写请求,WebSearch2的trace大部分为读请求,固不做分析处理。

第五个作用域是时间戳:

$ awk 'BEGIN{FS=",";max=0};{if($5>max){max=$5}};END{print max}' WebSearch2.spc
15395.556800
$ tail -1 WebSearch2.spc
2,25487520,8192,R,15395.556800

时间戳是按照请求到达的顺序排列的,最大的时间也是最后一条请求到达的时间。根据SPC文档的规范,时间的单位为s,可以看到这个trace实际上只是系统运行4个多小时的记录。

##Refactoring 我们对trace君的百般玩弄主要的目的是在于在我们自己的系统下重放trace的负载,分析系统的性能,主要是其平均响应时间。

但是我们的系统几乎不太可能与原先trace的工作系统一致,于是我们就需要对trace进行重构处理。

###Single Disk 如果仅对单盘进行trace重放,有两种方法。

  • 第一种方法,直接忽视设备号,每个请求都视为访问同一设备。

优点:实现简单

缺点:丧失了原先的局部性,可以造成性能下降

  • 第二种方法,将磁盘扩展,第二个设备视为直接第一个设备的衍生,并依次类推。即新的逻辑块地址=块设备号×总块数+旧逻辑块地址

优点:可能保留了局部性

缺点:需要进行换算,实现会比较复杂,需要比较大的磁盘

###Multiple Disk 对于多盘进行trace重放,如果盘数恰好相等,则无用多说。

如若不等,则类似Single Disk的第二种方法,先将磁盘扩展为单盘,再进行切分。

###Question

  • 如果想要测试磁盘的容量比trace的最大偏移地址大很多呢?

  • 类RAID5的测试:盘内存在校验块

##Replay trace的重放也有着两种方式:

  • 第一种,压力重放,无视时间戳的存在,直接循环中无间断执行每条请求

  • 第二种,守时重放,控制每条请求不能早于时间戳的时间执行

##Future Work

  • 多种trace的对比

  • tools: disksim

  • etc..

##Rant

  • 实验室的文档,传承

  • 引用出处,参考文献

##Reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment