系统技术非业余研究

我们在做数据库程序或者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…

我们在探索linux内核的时候，经常需要调整下变量的值，看它对系统的影响。如果这个值没有透过/proc来修改的话，那只能编译内核。这个步骤是非常繁琐的。现在我们有systemtap这个利器来帮忙了。

演示如下：
我们通过修改过
extern int sysctl_tcp_fin_timeout;的值来达到目的。是因为这个值是proc导出的 我们好验证是否成功。

root@localhost ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
15000
[root@localhost ~]# cat test.stp
probe begin
{
        printf("ready go\n");
}

probe kernel.function("do_tcp_setsockopt")
{
        $sysctl_tcp_fin_timeout = $1
        printf("sysctl_tcp_fin_timeout = %d\n", $sysctl_tcp_fin_timeout);
        exit()
}

[root@localhost ~]# stap -g test.stp 18000
ready go

这个时候 stap在运行， 只是还没有触发do_tcp_setsockopt.
现在我们来触发

[root@localhost ~]# erl
Erlang R13B02 (erts-5.7.3) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.7.3  (abort with ^G)
1> {ok, LSock} = gen_tcp:listen(0, []).
{ok,#Port<0.437>}
2>
2> inet:setopts(LSock, [{nodelay,true}]).
ok
3>

Ok,这时候回头可以看到stap打出来以下：
sysctl_tcp_fin_timeout = 18000

我们来验证下：

root@localhost ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
18000

OK,成功。

Tips：
1. stap对全局变量的写需要-g guru模式。
2. 全局变量必须在一个单元内的函数里面才可以修改， 而且必须是在内核上下文。

PS. 这样写的话会更好,因为这个变量是单元可见的,这个模块里面的任何函数被触发都可以看到这个变量. 因为这是tcp的核心模块随时都会被出发的,免除了以上的麻烦!

$ cat test.stp
probe begin
{
        printf("ready go\n");
}
probe kernel.function("*@net/ipv4/tcp.c") 
//probe kernel.function("do_tcp_setsockopt")
{
        $sysctl_tcp_fin_timeout = $1
        printf("sysctl_tcp_fin_timeout = %d\n", $sysctl_tcp_fin_timeout);
        exit()
}