专栏首页CU技术社区Linux大文件重定向和管道的效率对比

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

作者:Yu Feng 链接:http://blog.yufeng.info/archives/1981

# 命令1,管道导入
shell> cat huge_dump.sql | mysql -uroot;
# 命令2,重定向导入
shell> mysql -uroot < huge_dump.sql;

大家先看一下上面二个命令,假如huge_dump.sql文件很大,然后猜测一下哪种导入方式效率会更高一些?

以下来自@阿里褚霸的分享:

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

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

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

int main(int argc, char *argv[])
  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在收集数据了,我们在另外一个窗口运行管道的情况:

$ cat huge_dump.sql|./b.out

我们从systemtap的日志可以看出:

  1. bash fork了2个进程。
  2. 然后execve分别运行cat 和 b.out进程, 这二个进程用pipe通信。
  3. 数据从由cat从 huge_dump.sql读出,写到pipe,然后b.out从pipe读出处理。

那么再看下命令2重定向的情况:

$ ./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
  1. bash fork了一个进程,打开数据文件。
  2. 然后把文件句柄搞到0句柄上,这个进程execve运行b.out。
  3. 然后b.out直接读取数据。

现在就非常清楚为什么二种场景速度有3倍的差别: 命令1,管道方式: 读二次,写一次,外加一个进程上下文切换。 命令2,重定向方式:只读一次。

结论:Linux下大文件重定向效率更高。

本文分享自微信公众号 - CU技术社区(ChinaUnix2013)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-02-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 超融合三年,用户对它的期待发生了哪些变化?

    从2016年开始,著名研究机构Evaluator Group就在全球范围内针对企业级超融合基础设施(Hyper-Converged Infrastructure...

    用户6543014
  • 今天介绍一个开源的视频转换工具——Handbrake

    简介:HandBrake是一个免费的开源视频转换工具。让我们看看它的主要功能是什么,以及如何使用它们将视频从一种格式转换为另一种格式。

    用户6543014
  • LWN: 在 Linux 上运行 macOS 程序

    目前有个名叫Darling的项目活跃度不断提升,这个项目是希望能在Linux上提供一个针对macOS软件的translation layer(翻译层),有点类似...

    用户6543014
  • 五分钟看懂Celery定时任务

    1, Web应用。 当用户触发的一个操作需要很长时间才能执行完成,那么就可以把它当做一个任务去交给Celery去异步执行, 执行完成之后再返回给用户,这短时间用...

    Wyc
  • Spark常用函数(源码阅读六)

      源码层面整理下我们常用的操作RDD数据处理与分析的函数,从而能更好的应用于工作中。

    用户3003813
  • 走起,带你操纵数据

    本文讲述的是基于Oracle Linux 5 update 2下 Oracle 11g 数据库的数据操纵语言(DML),Linux系统是由VMWare虚拟机创建...

    DataScience
  • python语音朗读

    github下载地址:https://github.com/westonpace/pyttsx

    py3study
  • 设计新宠(二)社会设计师

    长久以来,设计师一直在为全球10%的有购买能力的人群做设计,而90%真正需要设计的人和问题却被忽视了,我们今天面临的日益凸显的环境和社会问题,正是对设计师提出的...

    Shawn.W
  • 第9章 Kotlin与Java互操作(Interoperability)

    9.1 使用工具互相转换 9.1.1 将 Java 转换为 Kotlin 9.1.2 将 Kotlin 转换为 Java 9.1.3 兼容 Java 的缺...

    一个会写诗的程序员
  • 正本清源——敏捷的为什么

    我们可以思考一下,敏捷这一概念究竟存在了多久?如果追溯历史,我个人认为可能真的可以回归到远古的时代。进化论里的一个经典推断就是:物竞天择,适者生存。那么“唯一不...

    CODING研发管理系统

扫码关注云+社区

领取腾讯云代金券