當(dāng)前位置：首頁 > 嵌入式培訓(xùn) > 嵌入式學(xué)習(xí) > 學(xué)習(xí)筆記 > 進(jìn)程與線程棧大小的調(diào)整
進(jìn)程與線程棧大小的調(diào)整
時間：2018-08-17 來源：未知
問題現(xiàn)象
首先看一個現(xiàn)象，最近在嵌入式項目開發(fā)中發(fā)現(xiàn)的，下面是設(shè)備的內(nèi)存總量及使用：
總量是24M左右，項目主程序大小1M不到，但是在默認(rèn)的系統(tǒng)環(huán)境設(shè)置下，程序運行起來后的top看起來是這樣：
VSZ的大小是221MB，所以計算出來的內(nèi)存使用百分比是935.4% = 221MB/24MB.VSZ表示程序使用的總虛擬內(nèi)存空間大小。在很久之前也曾遇到過同樣的現(xiàn)象，只是當(dāng)時沒有去深入了解為什么。剛開始發(fā)現(xiàn)這個221MB時，非常地吃驚，無論如何也想不通為什么1M大小不到的程序會需要使用到200M以上的內(nèi)存空間。
現(xiàn)象分析
程序是一個多線程的程序，而且有不少的線程是由線程再次創(chuàng)建的，系統(tǒng)環(huán)境是linux2.6.32的內(nèi)核。通過對其它單進(jìn)程的VSZ大小觀察，發(fā)現(xiàn)VSZ的大小好像與程序使用的線程數(shù)目成正比關(guān)系。因此想到可以通過使用Posix Pthread庫的pthread_attr_setstacksize接口來修改線程棧的大小，于是將20多個線程的棧的大小修改為512KB，雖然有點麻煩，但是再次運行，VSZ的確大幅地減少為30MB左右。
在分析解決問題的過程中，了解到另一個影響應(yīng)用程序運行棧大小的系統(tǒng)設(shè)置： ulimit -s。通過這個命令可以查看系統(tǒng)默認(rèn)的棧大小以及修改應(yīng)用運行時的棧大小，默認(rèn)的8192KB。這里再次分析上面的現(xiàn)象。linux系統(tǒng)中使用clone機制來實現(xiàn)線程，實際上線程就是一個輕量的進(jìn)程，因此其棧大小依然是遵循系統(tǒng)的ulimit設(shè)置來配置的。所以20多個線程的程序在默認(rèn)8M的棧大小設(shè)置下，會使用
到200M左右的虛擬內(nèi)存空間，包括程序的所有棧空間以及數(shù)據(jù)內(nèi)存、堆內(nèi)存和代碼內(nèi)存。
那么，就可以通過ulimit -s命令修改默認(rèn)的棧大小，從而達(dá)到與調(diào)用
pthread_attr_setstacksize接口一樣的目的和效果。使用ulimit -s 512后，主程序使用的VSZ降低為25M左右，這是因為主線程使用的棧大小也被降低。
但是使用ulimit的一個后果就是它會影響到同一環(huán)境(同一shell或者終端)下后續(xù)啟動的所有程序，如果修改成啟動時設(shè)置的話就會影響到整個系統(tǒng)，這顯然不是想要的。有兩個方法可以能消除這個影響：
1. 為需要修改棧大小的程序單獨編寫一個shell腳本，在程序啟動前調(diào)用ulimit -s。因為子shell的環(huán)境不會影響到父shell，所以設(shè)置不會改變外部環(huán)境。
2. 在程序運行前執(zhí)行ulimit -s修改需要的棧大小，在程序運行后再次執(zhí)行ulimit -s修改回原來的棧大小。
PS：雖然降低了程序使用的虛擬內(nèi)存的大小，但是我還是有一個很大的疑問：
程序使用200M多的虛擬內(nèi)存和使用20M多的虛擬內(nèi)存，運行效果沒有什么變化，好像沒有帶來什么有用的性能改善。我能想要的“好處”就是系統(tǒng)在進(jìn)行地址轉(zhuǎn)換和頁面管理時會高效一點，但難道不應(yīng)該有一些更重要的性能提升嗎，不然除了讓top內(nèi)容中的VSZ和%MEM欄更好看合理點外，沒必要去費精力調(diào)整?期待有人能幫忙解惑。
