最近在TL的討論中忽然有人挑起了perl和python（一場(chǎng)關(guān)于c++的討論扯到腳步上還有不少的碰撞，倒是挺有意思），我則有感而發(fā)的想起了前幾天面試的時(shí)候問(wèn)別人的一個(gè)基本的shell問(wèn)題：
cat xxx.txt | grep "yyy" | wc –l
問(wèn)題是這個(gè)常見(jiàn)的pipeline操作一般最少會(huì)起多少個(gè)進(jìn)程？結(jié)果那位老兄倒是愣了半天然后目無(wú)表情。
我只好繼續(xù)嘮叨的解釋了一下一般pipe的操作需要讀取一個(gè)進(jìn)程的輸入，然后將輸出送給下一個(gè)進(jìn)程；其實(shí)我希望對(duì)方干脆利落的回答是有3個(gè)，這個(gè)問(wèn)題就算是可以了；我們主要不是用腳本開(kāi)發(fā)，但是如果有這個(gè)技能是能得到額外的認(rèn)可的。
TL上的大蝦們果然是想法眾多，立馬有人站出來(lái)問(wèn)：我想知道答案是幾個(gè)？直接讓我懷疑是不是我的腦袋有問(wèn)題。后來(lái)有人給出了可能是2個(gè)的情形：
某個(gè)變態(tài)的shell可能內(nèi)置了cat,使其成為一個(gè)builtin，然后自己越俎代庖的讀取標(biāo)準(zhǔn)輸入，并且將內(nèi)容文本輸出，那么進(jìn)程就少一個(gè)。
起初我覺(jué)得這個(gè)解釋并不能成立，但是經(jīng)過(guò)幾個(gè)老大的解釋還是明白了他所說(shuō)的情況是shell的builtin。
中間又討論起那些可能是builtin的command，舉出的例子是cd/kill/time，但是我查了一下Solaris上的，后兩個(gè)都是executable，cd找到一個(gè)/usr/bin/cd 的ksh，內(nèi)容如下：
#!/bin/ksh
command = `basename $0`
$command $@
這個(gè)結(jié)果本來(lái)還是挺出乎我的意料的，于是我也想當(dāng)然的認(rèn)為，shell里邊不能直接調(diào)用syscall；
很快就得證這個(gè)揣測(cè)純粹是錯(cuò)誤的；以前還真沒(méi)想過(guò)這個(gè)問(wèn)題，查了下wikipedia、google之后得到很多意料之外的收獲。
最后居然有人搬出了busybox這個(gè)大旗（做過(guò)嵌入式的大多都知道些），并聲稱它把vi也builtin了。
這下也很出乎我的意料，不顧我沒(méi)有仔細(xì)研究過(guò)，沒(méi)有什么發(fā)言權(quán)。
不過(guò)最后有人站出來(lái)說(shuō)，busybox并沒(méi)有內(nèi)置這些想當(dāng)然的vi，而是大部分也單獨(dú)起進(jìn)程了；在Unix的哲學(xué)里邊，做這些大而全的東西其實(shí)是不被鼓勵(lì)的，因?yàn)樗`反unix的哲學(xué)。
話說(shuō)回來(lái)，面試的時(shí)候，我之所以會(huì)問(wèn)到這樣的問(wèn)題，也是有很真實(shí)的background的。曾經(jīng)我們查過(guò)的一個(gè)很詭異的performance bottleneck就是由于shell腳步的問(wèn)題引起的。
====================================================================================================
問(wèn)題本身也是比較直觀的（當(dāng)然是“事后諸葛”了）：
某段程序的啟動(dòng)腳本使用如下的東東來(lái)檢測(cè)環(huán)境：
exists=`netstat -rn | grep "xx.xx.xx.xx" | wc -l`
if [ $exists -eq 0 ];then
idx=`ifconfig -an | grep bge0 | awk -F":" '{print $2}' | uniq | sort | tail`"
ifconfig bge0:`echo $idx + 1 | bc` plumb up
ifconfig bge0:`echo $idx + 1 | bc` xx.xx.xx.xx netmask 255.255.255.0
fi
當(dāng)有很多個(gè)同樣的進(jìn)程（>500)恰好于同一時(shí)刻跑到這個(gè)初始化點(diǎn)的時(shí)候，如果系統(tǒng)上已經(jīng)存在的IP地址很多（當(dāng)時(shí)的場(chǎng)景大概有2000+），那么netstat、ifconfig本身都變得非常耗時(shí)，加上多個(gè)進(jìn)程的原因，系統(tǒng)中會(huì)有N多個(gè)進(jìn)程在消耗著資源；
后果的嚴(yán)重程度是任何shell都停止響應(yīng)，數(shù)十分鐘都陷入假死，不得不重啟電源了事。
當(dāng)然的分析結(jié)果發(fā)現(xiàn)，真正占用的CPU都是處于kernel狀態(tài)的，并且使用率超過(guò)99%，長(zhǎng)長(zhǎng)的pipeline帶來(lái)的開(kāi)銷，相當(dāng)一部分可能來(lái)源于互相等待CPU的進(jìn)程的互相搶占。
解決的方法自然也很簡(jiǎn)單，這里不贅述了。
=========================================================================
當(dāng)時(shí)以為對(duì)這個(gè)問(wèn)題搞得算是比較明白了，結(jié)果拿出來(lái)一討論，發(fā)現(xiàn)自己不了解的還真不少。