[導(dǎo)讀]大家好，我是小林。前幾天基金還大漲了一波，結(jié)果今天一早上打開支付寶，發(fā)現(xiàn)昨天的基金收益直接-3000多。。。你說不心疼是假的，但是我短期內(nèi)也不會(huì)賣出，所以在我不賣出的時(shí)候，它就是個(gè)數(shù)字，而且現(xiàn)在總體收益還是正數(shù)的，不慌！老讀者應(yīng)該知道，我是今年年初入坑基金的韭零后，選了幾個(gè)基金后...
大家好，我是小林。前幾天基金還大漲了一波，結(jié)果今天一早上打開支付寶，發(fā)現(xiàn)昨天的基金收益直接 -3000多。。。你說不心疼是假的，但是我短期內(nèi)也不會(huì)賣出，所以在我不賣出的時(shí)候，它就是個(gè)數(shù)字，而且現(xiàn)在總體收益還是正數(shù)的，不慌！老讀者應(yīng)該知道，我是今年年初入坑基金的韭零后，選了幾個(gè)基金后，就一直無腦定投，風(fēng)雨無阻。在 3 月份的時(shí)候，總體收益最低的時(shí)候是 -10000，不過由于一直在持續(xù)定投，在 5 月份收益已經(jīng)從負(fù)數(shù)變成正數(shù)了，收益也不算多，就小幾千。這玩意漲跌每天都在發(fā)生，我就偶爾打開看看收益的情況，每次打開驚喜筆比較少，驚嚇到是比較多些。好了，基金的事情就說到這了，我也算個(gè)反面教材，大家看個(gè)樂就好。身為技術(shù)博主，那肯定還是得說說技術(shù)的事情。昨天有位讀者被坑了，問了我這么個(gè)問題：大致意思就是，他看了一個(gè)面經(jīng)，說虛擬內(nèi)存是 2G 大小，然后他看了我的圖解系統(tǒng) PDF 里說虛擬內(nèi)存是 4G，然后他就懵逼了。其實(shí)他看這個(gè)面經(jīng)很有問題，沒有說明是什么操作系統(tǒng)，以及是多少位操作系統(tǒng)。因?yàn)椴煌牟僮飨到y(tǒng)和不同位數(shù)的操作系統(tǒng)，虛擬內(nèi)存可能是不一樣多。Windows 系統(tǒng)我不了解，我就說說 Linux 系統(tǒng)。?在 Linux 操作系統(tǒng)中，虛擬地址空間的內(nèi)部又被分為內(nèi)核空間和用戶空間兩部分，不同位數(shù)的系統(tǒng)，地址 空間的范圍也不同。比如最常?的 32 位和 64 位系統(tǒng)，如下所示:通過這里可以看出:
- 32 位系統(tǒng)的內(nèi)核空間占用 1G ，位于最高處，剩下的 3G 是用戶空間;
- 64 位系統(tǒng)的內(nèi)核空間和用戶空間都是 128T ，分別占據(jù)整個(gè)內(nèi)存空間的最高和最低處，剩下的中
間部分是未定義的。
- 進(jìn)程的虛擬內(nèi)存空間上限，因?yàn)閯?chuàng)建一個(gè)線程，操作系統(tǒng)需要為其分配一個(gè)?？臻g，如果線程數(shù)量越多，所需的?？臻g就要越大，那么虛擬內(nèi)存就會(huì)占用的越多。
- 系統(tǒng)參數(shù)限制，雖然 Linux 并沒有內(nèi)核參數(shù)來控制單個(gè)進(jìn)程創(chuàng)建的最大線程個(gè)數(shù)，但是有系統(tǒng)級(jí)別的參數(shù)來控制整個(gè)系統(tǒng)的最大線程個(gè)數(shù)。
$?ulimit?-s?512
說完 32 位系統(tǒng)的情況，我們來看看 64 位系統(tǒng)里，一個(gè)進(jìn)程能創(chuàng)建多少線程呢？我的測(cè)試服務(wù)器的配置：- 64 位系統(tǒng)；
- 2G 物理內(nèi)存；
- 單核 CPU。
- /proc/sys/kernel/threads-max，表示系統(tǒng)支持的最大線程數(shù)，默認(rèn)值是?
14553； - /proc/sys/kernel/pid_max，表示系統(tǒng)全局的 PID 號(hào)數(shù)值的限制，每一個(gè)進(jìn)程或線程都有 ID，ID 的值超過這個(gè)數(shù)，進(jìn)程或線程就會(huì)創(chuàng)建失敗，默認(rèn)值是?
32768； - /proc/sys/vm/max_map_count，表示限制一個(gè)進(jìn)程可以擁有的VMA(虛擬內(nèi)存區(qū)域)的數(shù)量，具體什么意思我也沒搞清楚，反正如果它的值很小，也會(huì)導(dǎo)致創(chuàng)建線程失敗，默認(rèn)值是?
65530。
threads-max?內(nèi)核參數(shù)，它是限制系統(tǒng)里最大線程數(shù)，默認(rèn)值是 14553。我們可以運(yùn)行那個(gè)測(cè)試線程數(shù)的程序后，看下當(dāng)前系統(tǒng)的線程數(shù)是多少，可以通過?top -H?查看。左上角的 Threads 的數(shù)量顯示是 14553，與?threads-max?內(nèi)核參數(shù)的值相同，所以我們可以認(rèn)為是因?yàn)檫@個(gè)參數(shù)導(dǎo)致無法繼續(xù)創(chuàng)建線程。那么，我們可以把 threads-max 參數(shù)設(shè)置成?99999:echo?99999?>?/proc/sys/kernel/threads-max
設(shè)置完 threads-max 參數(shù)后，我們重新跑測(cè)試線程數(shù)的程序，運(yùn)行后結(jié)果如下圖：可以看到，當(dāng)進(jìn)程創(chuàng)建了 32326 個(gè)線程后，就無法繼續(xù)創(chuàng)建里，且報(bào)錯(cuò)是無法繼續(xù)申請(qǐng)內(nèi)存。此時(shí)的上限個(gè)數(shù)很接近?pid_max?內(nèi)核參數(shù)的默認(rèn)值（32768），那么我們可以嘗試將這個(gè)參數(shù)設(shè)置為 99999：echo?99999?>?/proc/sys/kernel/pid_max
設(shè)置完 pid_max 參數(shù)后，繼續(xù)跑測(cè)試線程數(shù)的程序，運(yùn)行后結(jié)果創(chuàng)建線程的個(gè)數(shù)還是一樣卡在了 32768 了。當(dāng)時(shí)我也挺疑惑的，明明 pid_max 已經(jīng)調(diào)整大后，為什么線程個(gè)數(shù)還是上不去呢？后面經(jīng)過查閱資料發(fā)現(xiàn)，max_map_count?這個(gè)內(nèi)核參數(shù)也是需要調(diào)大的，但是它的數(shù)值與最大線程數(shù)之間有什么關(guān)系，我也不太明白，只是知道它的值是會(huì)限制創(chuàng)建線程個(gè)數(shù)的上限。然后，我把 max_map_count 內(nèi)核參數(shù)也設(shè)置成后 99999：echo?99999?>?/proc/sys/kernel/pid_max?
繼續(xù)跑測(cè)試線程數(shù)的程序，結(jié)果如下圖：當(dāng)創(chuàng)建差不多 5 萬個(gè)線程后，我的服務(wù)器就卡住不動(dòng)了，CPU 都已經(jīng)被占滿了，畢竟這個(gè)是單核 CPU，所以現(xiàn)在是 CPU 的瓶頸了。我只有這臺(tái)服務(wù)器，如果你們有性能更強(qiáng)的服務(wù)器來測(cè)試的話，有興趣的小伙伴可以去測(cè)試下。接下來，我們換個(gè)思路測(cè)試下，把創(chuàng)建線程時(shí)分配的?？臻g調(diào)大，比如調(diào)大為 100M，在大就會(huì)創(chuàng)建線程失敗。ulimit?-s?1024000
設(shè)置完后，跑測(cè)試線程的程序，其結(jié)果如下：總共創(chuàng)建了 26390 個(gè)線程，然后就無法繼續(xù)創(chuàng)建了，而且該進(jìn)程的虛擬內(nèi)存空間已經(jīng)高達(dá) 25T，要知道這臺(tái)服務(wù)器的物理內(nèi)存才 2G。為什么物理內(nèi)存只有 2G，進(jìn)程的虛擬內(nèi)存卻可以使用 25T 呢？因?yàn)樘摂M內(nèi)存并不是全部都映射到物理內(nèi)存的，程序是有局部性的特性，也就是某一個(gè)時(shí)間只會(huì)執(zhí)行部分代碼，所以只需要映射這部分程序就好。你可以從上面那個(gè) top 的截圖看到，雖然進(jìn)程虛擬空間很大，但是物理內(nèi)存（RES）只有使用了 400M 。好了，簡單總結(jié)下：- 32 位系統(tǒng)，用戶態(tài)的虛擬空間只有 3G，如果創(chuàng)建線程時(shí)分配的?？臻g是 10M，那么一個(gè)進(jìn)程最多只能創(chuàng)建 300 個(gè)左右的線程。
- 64 位系統(tǒng)，用戶態(tài)的虛擬空間大到有 128T，理論上不會(huì)受虛擬內(nèi)存大小的限制，而會(huì)受系統(tǒng)的參數(shù)或性能限制。
下載文檔
