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

博主：安安
发布时间：2020 年 04 月 03 日
1748 次浏览
暂无评论
5641字数
分类： Linux

<div class="tip share">请注意，本文编写于 1693 天前，最后修改于 1693 天前，其中某些信息可能已经过时。</div>

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

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

这个问题挺有意思的，我的第一反应是：

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

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

```bash
$ 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脚本用来方便观察程序的行为。

```bash
$ 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内存的机器很容易在内存里放下：

```bash
$ 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内存里面，不会涉及到磁盘。

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

```bash
$ 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

```bash
$ 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管道的情况：

```bash
$ cat huge_dump.sql|./b.out
```

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

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

```bash
$ ./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. 读二次，写一次,外加一个进程上下文切换。
情况二：只读一次。

> 转载于http://blog.yufeng.info/archives/1981

最后修改：2020 年 04 月 03 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

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

安安 • 2020 年 04 月 03 日

<div class="tip share">请注意，本文编写于 1693 天前，最后修改于 1693 天前，其中某些信息可能已经过时。</div>

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

这个问题挺有意思的，我的第一反应是：

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

```bash
$ 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脚本用来方便观察程序的行为。

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

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

```bash
$ 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内存里面，不会涉及到磁盘。

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

```bash
$ 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

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

```bash
$ cat huge_dump.sql|./b.out
```

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

```bash
$ ./b.out < huge_dump.sql

> 转载于http://blog.yufeng.info/archives/1981

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

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

PHP 7.2.11 安装

浏览器提示“你的连接不是专用连接”无法使用解决方案

关于SSD硬盘的指标DWPD、TBW 、P/E

python 3.8.1 编译报错 Could not import runpy module 问题

ESXI更新到6.7后CVE-2018-3646警告的处理

FTP传输超大文件假死问题

信息安全等级保护三级要求--安全管理机构

kettle使用spoon.sh打开报错问题解决

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

浏览器提示“你的连接不是专用连接”无法使用解决方案

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

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

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

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款