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