溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Linux大文件重定向和管道的效率是怎樣的”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Linux大文件重定向和管道的效率是怎樣的”吧！
| 導讀 | 大家先看一下二個 命令，假如huge_dump.sql文件很大，然后猜測一下哪種導入方式效率會更高一些? |
# 命令1，管道導入 shell> cat huge_dump.sql | mysql -uroot;
# 命令2，重定向?qū)?nbsp; shell> mysql -uroot < huge_dump.sql;
大家先看一下上面二個命令，假如huge_dump.sql文件很大，然后猜測一下哪種導入方式效率會更高一些?
這個問題挺有意思的，我的第一反應是：沒比較過，應該是一樣的，一個是cat負責打開文件，一個是bash
這種場景在MySQL運維操作里面應該比較多，所以就花了點時間做了個比較和原理上的分析：
我們先構(gòu)造場景：
首先準備一個程序b.out來模擬mysql對數(shù)據(jù)的消耗：
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(":~") }這個 腳本重點觀察幾個系統(tǒng)調(diào)用的順序和pipe的讀寫情況，然后再準備個419M的大文件huge_dump.sql,在我們幾十G內(nèi)存的機器很容易在內(nèi)存里放下：
$ 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寫的，所以它的內(nèi)容都cache在pagecahce內(nèi)存里面，不會涉及到磁盤。
好了，場景齊全了，我們接著來比較下二種情況下的速度，第一種管道：
# 第一種管道方式 $ time (cat huge_dump.sql|./b.out) real 0m0.596s user 0m0.001s sys 0m0.919s
從執(zhí)行時間數(shù)看出來速度有3倍左右的差別了，第二種明顯快很多。
是不是有點奇怪?好吧我們來從原來上面分析下，還是繼續(xù)用數(shù)據(jù)說話：
這次準備個很小的數(shù)據(jù)文件，方便觀察然后在一個窗口運行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在收集數(shù)據(jù)了，我們在另外一個窗口運行管道的情況：
$ cat huge_dump.sql|./b.out
我們從systemtap的日志可以看出：
bash fork了2個進程。
然后execve分別運行cat 和 b.out進程, 這二個進程用pipe通信。
數(shù)據(jù)從由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
bash fork了一個進程，打開數(shù)據(jù)文件。
然后把文件句柄搞到0句柄上，這個進程execve運行b.out。
然后b.out直接讀取數(shù)據(jù)。
現(xiàn)在就非常清楚為什么二種場景速度有3倍的差別：
命令1，管道方式： 讀二次，寫一次,外加一個進程上下文切換。
命令2，重定向方式：只讀一次。
感謝各位的閱讀，以上就是“Linux大文件重定向和管道的效率是怎樣的”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對Linux大文件重定向和管道的效率是怎樣的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼