Home > Linux, 调优 > 大文件重定向和管道的效率对比

大文件重定向和管道的效率对比

December 20th, 2011 Leave a comment Go to comments

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: 大文件重定向和管道的效率对比

微博上的@拉风_zhang提出了个问题:

@淘宝褚霸 请教个问题,#1. cat huge_dump.sql | mysql -uroot ;#2. mysql -uroot < huge_dump.sql ;#1效率要高,在linux中通过管道传输 和 < 这种方式有什么差别呢?谢谢!#AskBaye#

这个问题挺有意思的,我的第一反应是:

没比较过,应该是一样的,一个是cat负责打开文件,一个是bash

这种场景在MySQL运维操作里面应该比较多,所以就花了点时间做了个比较和原理上的分析:
我们先构造场景:
首先准备一个程序b.out来模拟mysql对数据的消耗:

$ cat b.c
#include <stdio.h>
int main(int argc, char *argv[])
{
  char buf[4096];
  while(fread(buf, sizeof(buf), 1, stdin) > 0);
  return 0;
}
$  gcc  -o b.out b.c
$ ls|./b.out 

编译好再顺手我们的程序功能是正确的:纯消耗流。

再来写个systemtap脚本用来方便观察程序的行为。

$ cat test.stp
function should_log(){
  return (execname() == "cat" ||
      execname() == "b.out" ||
      execname() == "bash") ;
}
probe syscall.open,
      syscall.close,
      syscall.read,
      syscall.write,
      syscall.pipe,
      syscall.fork,
      syscall.execve,
      syscall.dup,
      syscall.wait4
{
  if (!should_log()) next;
  printf("%s -> %s\n", thread_indent(0), probefunc());
}

probe kernel.function("pipe_read"),
      kernel.function("pipe_readv"),
      kernel.function("pipe_write"),
      kernel.function("pipe_writev")
{
  if (!should_log()) next;
  printf("%s -> %s: file ino %d\n",  thread_indent(0), probefunc(), __file_ino($filp));
}
probe begin { println(":~") }

这个脚本重点观察几个系统调用的顺序和pipe的读写情况,

然后再准备个419M的大文件huge_dump.sql,在我们几十G内存的机器很容易在内存里放下:

$ sudo dd if=/dev/urandom of=huge_dump.sql bs=4096 count=102400
102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 63.9886 seconds, 6.6 MB/s

因为这个文件是用bufferio写的,所以它的内容都cache在pagecahce内存里面,不会涉及到磁盘。

好了,场景齐全了,我们接着来比较下二种情况下的速度:

$ time (cat huge_dump.sql|./b.out)

real    0m0.596s
user    0m0.001s
sys     0m0.919s

$ time (./b.out <huge_dump.sql)

real    0m0.151s
user    0m0.000s
sys     0m0.147s

从数字看出来速度有3倍左右的差别了,第二种明显快很多。

是不是有点奇怪?好吧我们来从原来上面分析下,还是继续用数据说话:

这次准备个很小的数据文件,方便观察然后在一个窗口运行stap

$ echo hello > huge_dump.sql
$ sudo stap test.stp
:~
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> do_fork
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> do_fork
     0 bash(13775): -> sys_close
     0 bash(13775): -> sys_read
     0 bash(13775): -> pipe_read: file ino 20906911
     0 bash(13775): -> pipe_readv: file ino 20906911
     0 bash(13776): -> sys_close
     0 bash(13776): -> sys_close
     0 bash(13776): -> sys_close
     0 bash(13776): -> do_execve
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(13775): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(13775): -> sys_close
     0 bash(13775): -> sys_close
     0 b.out(13776): -> sys_close
     0 b.out(13776): -> sys_close
     0 bash(13775): -> do_execve
     0 b.out(13776): -> sys_open
     0 b.out(13776): -> sys_close
     0 b.out(13776): -> sys_open
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> sys_close
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_close
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> pipe_read: file ino 20906910
     0 b.out(13776): -> pipe_readv: file ino 20906910
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_read
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_open
     0 cat(13775): -> sys_read
     0 cat(13775): -> sys_write
     0 cat(13775): -> pipe_write: file ino 20906910
     0 cat(13775): -> pipe_writev: file ino 20906910
     0 cat(13775): -> sys_read
     0 b.out(13776): -> sys_read
     0 b.out(13776): -> pipe_read: file ino 20906910
     0 b.out(13776): -> pipe_readv: file ino 20906910
     0 cat(13775): -> sys_close
     0 cat(13775): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_write

stap在收集数据了,我们在另外一个窗口运行情况1管道的情况:

$ cat huge_dump.sql|./b.out

我们从systemtap的日志可以看出: bash fork了2个进程,然后execve分别运行cat 和 b.out进程, 这二个进程用pipe通信,数据从由cat从 huge_dump.sql读出,写到pipe,然后b.out从pipe读出处理。

那么再看下情况二重定向的情况:

$ ./b.out < huge_dump.sql 

stap输出:
      0 bash(26570): -> sys_read
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_pipe
     0 bash(26570): -> do_fork
     0 bash(28926): -> sys_close
     0 bash(28926): -> sys_read
     0 bash(28926): -> pipe_read: file ino 20920902
     0 bash(28926): -> pipe_readv: file ino 20920902
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_close
     0 bash(26570): -> sys_wait4
     0 bash(28926): -> sys_close
     0 bash(28926): -> sys_open
     0 bash(28926): -> sys_close
     0 bash(28926): -> do_execve
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_open
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_open
     0 b.out(28926): -> sys_read
     0 b.out(28926): -> sys_close
     0 b.out(28926): -> sys_read
     0 b.out(28926): -> sys_read
     0 bash(26570): -> sys_wait4
     0 bash(26570): -> sys_write
     0 bash(26570): -> sys_read

bash fork了一个进程,打开数据文件,然后把文件句柄搞到0句柄上,这个进程execve运行b.out,然后b.out直接读取数据。
现在就非常清楚为什么二种场景速度有3倍的差别:
情况1. 读二次,写一次,外加一个进程上下文切换。
情况二:只读一次。

小结: 越简单的事情,有时候越有意思!
祝玩得开心!

Post Footer automatically generated by wp-posturl plugin for wordpress.

Categories: Linux, 调优 Tags:
  1. 路人
    December 20th, 2011 at 14:31 | #1

    能不能不用句柄这个词 -,-

    [Reply]

    Yu Feng Reply:

    那用什么比较合适?

    [Reply]

    hamilto Reply:

    文件指针

    [Reply]

    Yu Feng Reply:

    哈哈,那你还是真不懂。。。

    路人 Reply:

    fd, 或者文件描述符

    [Reply]

    依云 Reply:

    这个中文从来都是叫作文件描述符的呀,只有 Windows 才弄出一堆让人不明白的XX句柄。

  2. December 20th, 2011 at 15:01 | #2

    赞分析,我的第一反应是 2 要快。现在知道为什么了。

    [Reply]

    Yu Feng Reply:

    呵呵

    [Reply]

  3. December 20th, 2011 at 16:49 | #3

    这个早就有人分析过了,第一种情况被成为UUOC(Useless Usage of Cat)。。。

    [Reply]

    Yu Feng Reply:

    这么专业的名词?cool

    [Reply]

  4. December 22nd, 2011 at 15:03 | #4

    分析很精彩!看来pipe不能用于密集数据传输呵

    [Reply]

  5. December 24th, 2011 at 12:26 | #5

    BASH的手册中有这样的描述:
    The command substitution $(cat file) can be replaced by the equivalent but faster $(< file).

    [Reply]

    Yu Feng Reply:

    手册是个好东西~

    [Reply]

  6. December 26th, 2011 at 19:58 | #6

    虽然分析我觉得很有道理,不过测试的数据我表示怀疑……
    http://minus.com/mfNPsuJX4 这个是我的测试结果,这里文件是存放在磁盘上的,在 OS X Lion 下测试,huge 文件生成指令为
    dd if=/dev/zero of=huge bs=4096 count=102400

    [Reply]

    Yu Feng Reply:

    放在磁盘上本身就是个错误,磁盘的访问时间是10ms级别的,而整个pipe的开销相对是us级别的,当然你要表示怀疑了。

    [Reply]

    upsuper Reply:

    但是你在测试中声明是放在内存中的,为什么 time 的耗时比磁盘还大得多呢?

    [Reply]

    Yu Feng Reply:

    你的系统是osx, 我的是linux, 完全不同的实现,完全不同的硬件,有什么可以比较的。
    你自己的案例符合结论就好了~

  7. October 4th, 2012 at 20:54 | #7

    细致求证的方式很cool, 堪称linux性能分析的样板. 学习学习!

    [Reply]

    Yu Feng Reply:

    多谢鼓励!

    [Reply]

  8. May 1st, 2013 at 16:32 | #8

    看着很爽,

    [Reply]

  1. August 16th, 2012 at 20:12 | #1