進程與線(xian)程棧大小的調整
時間：2018-08-17 來源(yuan)：未知
問題現象
首先看一個(ge)現象，最近(jin)在嵌(qian)入式項目開(kai)發中(zhong)發現的，下面(mian)是設備(bei)的內(nei)存總量及使(shi)用(yong)：
總量是24M左右，項目主程序大小1M不到，但是在默認的(de)系(xi)統環(huan)境設置下，程序運(yun)行起(qi)來(lai)后(hou)的(de)top看起(qi)來(lai)是這樣：
VSZ的(de)大小(xiao)是221MB，所以計算出來的(de)內存(cun)(cun)使(shi)用百分比(bi)是935.4% = 221MB/24MB.VSZ表示程序(xu)使(shi)用的(de)總(zong)虛擬(ni)內存(cun)(cun)空間大小(xiao)。在(zai)很久之前也曾遇到過(guo)同樣的(de)現象，只(zhi)是當時(shi)沒有去深入了解為什么(me)。剛開始(shi)發現這個221MB時(shi)，非常地吃驚，無論如何也想(xiang)不通為什么(me)1M大小(xiao)不到的(de)程序(xu)會需要使(shi)用到200M以上的(de)內存(cun)(cun)空間。
現象分析
程序是(shi)(shi)一個多線(xian)(xian)(xian)(xian)(xian)程的(de)(de)(de)(de)(de)程序，而且有不(bu)少(shao)(shao)的(de)(de)(de)(de)(de)線(xian)(xian)(xian)(xian)(xian)程是(shi)(shi)由(you)線(xian)(xian)(xian)(xian)(xian)程再次創建的(de)(de)(de)(de)(de)，系(xi)統環境是(shi)(shi)linux2.6.32的(de)(de)(de)(de)(de)內(nei)核(he)。通過對其(qi)它單進程的(de)(de)(de)(de)(de)VSZ大(da)(da)(da)小(xiao)觀(guan)察，發現VSZ的(de)(de)(de)(de)(de)大(da)(da)(da)小(xiao)好像與程序使用的(de)(de)(de)(de)(de)線(xian)(xian)(xian)(xian)(xian)程數目成正(zheng)比關系(xi)。因此想到可以通過使用Posix Pthread庫的(de)(de)(de)(de)(de)pthread_attr_setstacksize接口來(lai)修改線(xian)(xian)(xian)(xian)(xian)程棧(zhan)的(de)(de)(de)(de)(de)大(da)(da)(da)小(xiao)，于是(shi)(shi)將(jiang)20多個線(xian)(xian)(xian)(xian)(xian)程的(de)(de)(de)(de)(de)棧(zhan)的(de)(de)(de)(de)(de)大(da)(da)(da)小(xiao)修改為512KB，雖(sui)然有點麻煩，但是(shi)(shi)再次運(yun)行(xing)，VSZ的(de)(de)(de)(de)(de)確大(da)(da)(da)幅地(di)減少(shao)(shao)為30MB左(zuo)右(you)。
在分(fen)析解(jie)決問題的(de)過程(cheng)(cheng)(cheng)(cheng)(cheng)中，了解(jie)到另一個(ge)影響應用(yong)程(cheng)(cheng)(cheng)(cheng)(cheng)序(xu)(xu)運行(xing)棧(zhan)(zhan)大小(xiao)的(de)系統(tong)設置(zhi)： ulimit -s。通過這個(ge)命令可(ke)以(yi)查(cha)看系統(tong)默認(ren)的(de)棧(zhan)(zhan)大小(xiao)以(yi)及(ji)修改應用(yong)運行(xing)時的(de)棧(zhan)(zhan)大小(xiao)，默認(ren)的(de)8192KB。這里再次分(fen)析上(shang)面(mian)的(de)現象(xiang)。linux系統(tong)中使用(yong)clone機制來實(shi)現線程(cheng)(cheng)(cheng)(cheng)(cheng)，實(shi)際(ji)上(shang)線程(cheng)(cheng)(cheng)(cheng)(cheng)就是一個(ge)輕量的(de)進(jin)程(cheng)(cheng)(cheng)(cheng)(cheng)，因此其棧(zhan)(zhan)大小(xiao)依然是遵循系統(tong)的(de)ulimit設置(zhi)來配置(zhi)的(de)。所(suo)以(yi)20多個(ge)線程(cheng)(cheng)(cheng)(cheng)(cheng)的(de)程(cheng)(cheng)(cheng)(cheng)(cheng)序(xu)(xu)在默認(ren)8M的(de)棧(zhan)(zhan)大小(xiao)設置(zhi)下，會使用(yong)
到200M左右的虛擬內存(cun)(cun)(cun)空間(jian)，包(bao)括(kuo)程序的所(suo)有棧(zhan)空間(jian)以及數(shu)據內存(cun)(cun)(cun)、堆內存(cun)(cun)(cun)和代碼(ma)內存(cun)(cun)(cun)。
那么，就可以通過ulimit -s命令修改默(mo)認(ren)的(de)棧大小，從而達到與調用(yong)
pthread_attr_setstacksize接口一樣的(de)目的(de)和效果。使用(yong)ulimit -s 512后，主(zhu)程序使用(yong)的(de)VSZ降(jiang)低為25M左(zuo)右，這是因為主(zhu)線程使用(yong)的(de)棧(zhan)大小也被降(jiang)低。
但是(shi)(shi)使用(yong)ulimit的(de)一個后果就(jiu)是(shi)(shi)它會影(ying)響到(dao)同一環境(同一shell或(huo)者(zhe)終端)下(xia)后續啟動(dong)的(de)所(suo)有(you)程序，如果修改成啟動(dong)時設(she)置的(de)話就(jiu)會影(ying)響到(dao)整(zheng)個系(xi)統，這顯然不是(shi)(shi)想(xiang)要的(de)。有(you)兩個方法可以能(neng)消除這個影(ying)響：
1. 為需要修改(gai)棧大小的(de)程序(xu)單(dan)獨(du)編寫一個(ge)shell腳本，在程序(xu)啟動前調用(yong)ulimit -s。因為子shell的(de)環境(jing)不會影響到(dao)父shell，所以設置(zhi)不會改(gai)變外部環境(jing)。
2. 在(zai)程序運(yun)行前(qian)執行ulimit -s修改需(xu)要的棧(zhan)大小(xiao)，在(zai)程序運(yun)行后(hou)再次執行ulimit -s修改回(hui)原來的棧(zhan)大小(xiao)。
PS：雖然降低(di)了程序使(shi)用的虛擬(ni)內存的大小，但是(shi)我還是(shi)有一個很大的疑問：
程序使用(yong)200M多(duo)的虛擬(ni)內存和(he)使用(yong)20M多(duo)的虛擬(ni)內存，運(yun)行(xing)(xing)效果沒(mei)有(you)(you)什(shen)么變化，好像沒(mei)有(you)(you)帶來什(shen)么有(you)(you)用(yong)的性能(neng)改善。我能(neng)想要(yao)的“好處”就是系(xi)統在進行(xing)(xing)地址(zhi)轉(zhuan)換和(he)頁面管理(li)時會高(gao)效一(yi)點(dian)，但難道不應該有(you)(you)一(yi)些更重要(yao)的性能(neng)提升嗎，不然除了讓top內容中的VSZ和(he)%MEM欄(lan)更好看合理(li)點(dian)外，沒(mei)必要(yao)去(qu)費精力調整?期待(dai)有(you)(you)人能(neng)幫(bang)忙解(jie)惑。
