系统技术非业余研究

fio是个非常强大的IO性能测试工具，可以毫不夸张的说，如果你把所有的fio参数都搞明白了，基本上就把IO协议栈的问题搞的差不多明白了，原因在于作者Jens Axboe是linux内核IO部分的maintainer. 但是这个工具有个很大的缺点就是没有图形界面，单靠输出的数字很难看出来IO的趋势变化，所以急需一个图形前端.

幸运的是Jens也认识到这个问题，2012年2月15号在google plus上说：

Once complete, this will be a great addition to fio. It can be quite tricky to get a good overview of all the various job controlling options that fio has, presenting them graphically has some advantages over a basic 80-line text cli.

可是Jens是写linux内核代码的，对于图形终端的编程不是很熟悉。 大牛毕竟是大牛，发扬革命不怕苦精神，自己学图形编程，于是在最近的2.1版本给我们带来了这个图形终端。有了这个东西使用起来就方便许多。

我给大家演示下如何编译，运行这个gfio. 在这之前需要给大家说下fio的server/client模式。 fio一旦进入server模式就会在8765 tcp端口上监听，等待客户端来连接。 一旦客户端连接上来，会发上来比如运行job等任务，服务端把运行结果推送到客户端。所以这个图形前端实际上是fio的一个client, 名字叫gfio. 具体参见 README里面的描述。

新版本的支持gfio的fio可以在这里下载 git clone git://git.kernel.dk/fio.git,编译gfio源码的时候, 由于它依赖于gtk库，需要先安装libgtk2.0开发包，演示开始：

$ uname -a
Linux yufeng-Latitude-E6400 3.0.0-30-generic #47-Ubuntu SMP Wed Jan 2 23:16:29 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ sudo apt-get -y install libgtk2.0-dev
$ git clone git://git.kernel.dk/fio.git
$ cd fio
$ ./configure --enable-gfio
...
gtk 2.18 or higher            yes
...

$ make fio
$ make gfio
$ ./fio -S
fio: server listening on 0.0.0.0,8765

这样fio就编译好了，同时进入server模式。 在另外一个终端运行 gfio 就可以看到图形界面，打开examples/aio-read.fio 这个脚本把玩下（注意这个脚本里面文件的路径是/data1, 最好改成/tmp之类的），如下图：

有图有真像！

祝玩得开心！

Fio 是个强大的IO压力测试工具，我之前写过不少fio的使用和实践，参见 这里。

随着块设备的发展，特别是SSD盘的出现，设备的并行度越来越高。利用好这些设备，有个诀窍就是提高设备的iodepth, 一把喂给设备更多的IO请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。

应用使用IO通常有二种方式：同步和异步。 同步的IO一次只能发出一个IO请求，等待内核完成才返回，这样对于单个线程iodepth总是小于1，但是可以透过多个线程并发执行来解决，通常我们会用16-32根线程同时工作把iodepth塞满。 异步的话就是用类似libaio这样的linux native aio一次提交一批，然后等待一批的完成，减少交互的次数，会更有效率。

io队列深度通常对不同的设备很敏感，那么如何用fio来探测出合理的值呢？

让我们先来看下和iodepth相关的参数：

iodepth=int
Number of I/O units to keep in flight against the file. Note that increasing iodepth beyond 1 will not affect synchronous ioengines
(except for small degress when verify_async is in use). Even async engines my impose OS restrictions causing the desired depth not to be
achieved. This may happen on Linux when using libaio and not setting direct=1, since buffered IO is not async on that OS. Keep an eye on
the IO depth distribution in the fio output to verify that the achieved depth is as expected. Default:
1.

iodepth_batch=int
Number of I/Os to submit at once. Default: iodepth.

iodepth_batch_complete=int
This defines how many pieces of IO to retrieve at once. It defaults to 1 which
means that we’ll ask for a minimum of 1 IO in the retrieval process from the kernel. The IO retrieval will go on until we hit the limit
set by iodepth_low. If this variable is set to 0, then fio will always check for completed events before queuing more IO. This helps
reduce IO latency, at the cost of more retrieval system calls.

iodepth_low=int
Low watermark indicating when to start filling the queue again. Default: iodepth.

direct=bool
If true, use non-buffered I/O (usually O_DIRECT). Default: false.

fsync=int
How many I/Os to perform before issuing an fsync(2) of dirty data. If 0, don’t sync. Default: 0.

这几个参数在libaio的引擎下的作用，文档写的挺明白，但容我再罗嗦下IO请求的流程：

libaio引擎会用这个iodepth值来调用io_setup准备个可以一次提交iodepth个IO的上下文，同时申请个io请求队列用于保持IO。 在压测进行的时候，系统会生成特定的IO请求，往io请求队列里面扔，当队列里面的IO个数达到iodepth_batch值的时候，就调用io_submit批次提交请求，然后开始调用io_getevents开始收割已经完成的IO。 每次收割多少呢？由于收割的时候，超时时间设置为0，所以有多少已完成就算多少，最多可以收割iodepth_batch_complete值个。随着收割，IO队列里面的IO数就少了，那么需要补充新的IO。 什么时候补充呢？当IO数目降到iodepth_low值的时候，就重新填充，保证OS可以看到至少iodepth_low数目的io在电梯口排队着。

注意：这些参数在文档里面描述的有点小问题，比如说默认值什么的是不太对的，所以我的建议是这些参数要去显示的写。

如何确认fio安装我们的配置在工作呢？ fio提供了诊断办法 --debug=io ，我们来演示下：

Read more…

随着包括存储设备在内服务器的能力越来越高，特别是用上了PCIe存储卡后，IOPS能力通常有10几万，马上过剩。在这种情况下，一台服务器可以干很多事情，在上面跑很多服务。那么如何保证系统的服务质量是个很重要的事情了。

我们在下来的的项目中倾向于用cgroup来做资源的隔离和限制，原因是cgroup的开销很小，而且很易用。cgroup 可以参考这里

我们特别关心cgroup的blkio子模块，他有2种限制模式:
1. throttle，限制每个进程能使用的IOPS或者吞吐量。
2. weight，现在每个进程能使用的IOPS的能力的比例，必须通过CFQ调度器来实现。
文档和具体的参数可以看上面提到的cgroup文档。

Read more…

fio是个非常好用的io压力模拟工具，功能非常齐全， 有兴趣的同学参看 这里。
这里我用fio模拟我们线上mysql服务器的压力来为厂家送来的pci-ssd卡做压力测试，底下是脚本(已经测试正确)，也许有的同学有用。
Read more…

我们在做块设备调优的时候, 我们关心的是块设备是如何被访问的,也就是访问模式(比如说每次从什么地方读,每次读多少块,热点在哪里等),至于每次读写的什么数据我们并不关心. 这些模式当然可以自己去构造,但是如果能把真实应用的访问模式记录下来,并且在调优的时候能重放,我们就可以一遍又一遍的调试直到达到最佳的性能.

这个事情听起来貌似很麻烦,对吧? 幸运的是fio配合blktrace可以作这样的事情. 流程是blktrace负责录制真实应用对设备的访问模式, fio负责读入这些模式, 同时重放模拟对设备的访问.

背景资料:
blktrace使用可以参看这里
fio使用可以参看这里

在做演示前需要强调的是: 对设备的读写是模拟它的模式, 所以会破坏原来的数据,请谨慎, 我也是用虚拟的设备作演示的:

我们要演示的设备是 /dev/ram0, 设备大小128M:
Read more…

我们在做数据库程序或者IO密集型的程序的时候，通常在更新的时候，比如说数据库程序，希望更新有一定的安全性，我们会在更新操作结束的时候调用fsync或者fdatasync来flush数据到持久设备去。而且通常是以页面为单位，16K一次或者4K一次。 安全性保证了，但是性能就有很大的损害。而且我们更新的时候，通常是更新文件的某一个页面，那么由于是更新覆盖操作，对文件系统的元数据来讲的话，无需变更，所以我们通常不大关心元数据是否写入。 当更新非常频繁的时候，我们时候能够有其他方法减少性能损失。sync_file_range同学出场了。

Linux下系统调用sync_file_range只在内核2.6.17及更高版本是可用的, 我们常用的RHEL 5U4是支持的。
这篇文章有他的介绍： http://lwn.net/Articles/178199/
也可以man sync_file_range下他的具体作用, 但是请注意，sync_file_range是不可移植的。

sync_file_range – sync a file segment with disk

sync_file_range() permits fine control when synchronising the open file referred to by the file descriptor fd with disk.

offset is the starting byte of the file range to be synchronised. nbytes specifies the length of the range to be synchronised, in bytes; if nbytes is zero, then all bytes from offset through to the end of file are synchronised. Synchronisation is in units of the system page size: offset is rounded down to a page boundary; (offset+nbytes-1) is rounded up to a page boundary.

sync_file_range可以让我们在做多个更新后，一次性的刷数据，这样大大提高IO的性能。 具体的实现在fs/sync.c里面，有兴趣的同学可以围观下。

著名的fio测试工具支持sync_file_range来做sync操作，我们在决定在我们的应用中使用该syscall之前不妨先fio测试一把。

祝大家玩的开心。

我们在Linux上总是要保存数据的，数据要么保存在文件系统里(如ext3)，要么就在裸设备里面。我们在使用这些数据的时候都是通过文件这个抽象来访问的，操作系统会把我们需要的数据给我们，我们通常无需和块设备打交道。

从下图我们可以很清楚的看到：

我们会发现IO是个层次很深的子系统，有很复杂的数据流动线路。

至于操作系统如何去存储和获取这些数据对我们完全是黑盒子的，这通常不是问题。但是如果我们的IO很密集，我们就需要搞清楚IO具体是如何运作的，免的滥用IO和导致设计问题。

这时候你就需要blktrace这样的工具。

blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space.

它的作者Jens Axboe， 是内核IO模块的维护者，目前就职于FusionIO, 是个很nice的家伙，同时他还是著名IO评测工具fio的作者。

相关的文档：
users guide: http://pdfedit.petricek.net/bt/file_download.php?file_id=17&type=bug

HP的人写的指南： http://www.gelato.org/pdf/apr2006/gelato_ICE06apr_blktrace_brunelle_hp.pdf

CU上的小伙子写的： http://linux.chinaunix.net/bbs/viewthread.php?tid=1115851&extra=&ordertype=2

目前blktrace在大部分的Linux发行版都支持的，我们可以轻松的安装使用：
Read more…