前幾天寫了篇《gen_server tasting 之超簡(jiǎn)單名稱服務(wù)（續(xù)） 》東西，親身體驗(yàn)了 erlang otp 的強(qiáng)悍威力。這周正好有時(shí)間對(duì) vsns/erlang 做個(gè)性能測(cè)試，驗(yàn)證傳說(shuō)中的 erlang 強(qiáng)大威力，其中包括了容錯(cuò)測(cè)試用例，關(guān)注在大并發(fā)壓力下（13000tps）時(shí)，服務(wù) oops 后通過(guò) supervisor restart 時(shí)對(duì)整體性能的影響。在最后還包括了一些對(duì)服務(wù)容錯(cuò)設(shè)計(jì)上的一些思考。

 

測(cè)試用例設(shè)計(jì)

設(shè)計(jì)兩個(gè)場(chǎng)景，都配置 200 并發(fā)壓力：

 

1. Complex： 通過(guò) socket 混合調(diào)用 vsns 服務(wù)的 load_all、remove_all、remove、save、load 請(qǐng)求。無(wú) Think time 迭代執(zhí)行5分鐘。用來(lái)取得服務(wù)滿負(fù)載情況下吞吐量、響應(yīng)時(shí)間及資源利用率性能指標(biāo)。
2. Crash： 在執(zhí)行 Complex 場(chǎng)景過(guò)程中通過(guò) kernel_oops 調(diào)用來(lái) crash 名稱服務(wù)。啟用“continue on error” LoadRunner run-time 選項(xiàng)。用來(lái)取得服務(wù)滿負(fù)載情況下，執(zhí)行容錯(cuò)對(duì)吞吐量、響應(yīng)時(shí)間及資源利用率性能指標(biāo)的影響。

環(huán)境配置

 

          環(huán)境是很簡(jiǎn)單的，精力有限，呵呵。需要說(shuō)明的是，由于手上只有 Global 100 的 LoadRunner License，所以計(jì)劃的 200 并發(fā)平均分配到兩個(gè)測(cè)試機(jī)上，而且是啟的獨(dú)立 Controller，因此下邊的吞吐量和響應(yīng)時(shí)間結(jié)果也只能分別給出了。

 

“服務(wù)器”主機(jī)配置

          說(shuō)是服務(wù)器，實(shí)際是我的辦公機(jī)器，HP 商用機(jī)。手頭機(jī)器有限，呵呵。倒不是沒(méi)有其他資源，只是考慮本次測(cè)試很原始，純屬個(gè)人娛樂(lè)，而且自己的機(jī)器調(diào)調(diào)配配、修修改改不麻煩。

 

 

          測(cè)試機(jī)這里就不例了，兩臺(tái)也是 HP 商用機(jī)，不過(guò)配置很好 Intel Core 2 Duo 2.8GHz，2G 內(nèi)存，呵呵夠用。

 

測(cè)試執(zhí)行

執(zhí)行的力工細(xì)節(jié)就不說(shuō)了，總之是負(fù)載很大，服務(wù)器飽和，有圖為證。

 

 

 

測(cè)試結(jié)果

1. Complex 場(chǎng)景

 

測(cè)試機(jī) A 的吞吐量和響應(yīng)時(shí)間曲線。

 

 

測(cè)試機(jī) B 的吞吐量和響應(yīng)時(shí)間曲線。

 

 

 

 

          注：其中的 “Wait%” 指標(biāo)是無(wú)效的，nmon （nmon_x86_debian31(11f) 版本）采集的結(jié)果都是 0。我認(rèn)為這是個(gè) Bug，再不就是 debian 31 和 ubuntu 8.10 差異造成的。已經(jīng)將該問(wèn)題提交到 IBM developerWorks 的 AIX and UNIX Performance Tools Forum，不過(guò)沒(méi)人回答 ：（。難不成 je 的哪位大蝦能給個(gè)意見(jiàn)？

 

 

2. Crash 場(chǎng)景

 

測(cè)試機(jī) A 的吞吐量和響應(yīng)時(shí)間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

測(cè)試機(jī) B 的吞吐量和響應(yīng)時(shí)間曲線。

 

Pass Transcation.

 

 

Fail Transcation.

 

 

注：其中的 “Error: reset_conn once.” 是測(cè)試腳本中通過(guò) lr_error_message 函數(shù)人為寫入的，調(diào)試用。

 

 

結(jié)果分析

          在 Complex 測(cè)試場(chǎng)景中，可以看到 vsns 服務(wù)在滿負(fù)載情況下吞吐量能夠持續(xù)、穩(wěn)定的達(dá)到 13000tps（兩臺(tái)測(cè)試機(jī)總合），響應(yīng)時(shí)間也穩(wěn)定保持在 0.015 秒上下。在服務(wù)器資源方面，很明顯 CPU 和內(nèi)存已經(jīng)飽和，也是因?yàn)槲疫@個(gè)臨時(shí)的“服務(wù)器”總共才 512M 物理內(nèi)存，還沒(méi)測(cè)試機(jī)一半強(qiáng)（2G），不過(guò)這也恰恰說(shuō)明 erlang 面對(duì)艱巨條件時(shí)還是很堅(jiān)挺的，呵呵。等回頭和同事商量給我這臺(tái)充當(dāng)服務(wù)器的辦公機(jī)器加條內(nèi)存，估計(jì)那樣一定會(huì)提高不少。當(dāng)然這和測(cè)試中對(duì) vsns 提交存儲(chǔ)的 key/value 大小有直接關(guān)系。

          可能對(duì)于 Crash 測(cè)試場(chǎng)景更有意義，現(xiàn)在就來(lái)一起看看。CPU 和內(nèi)存也與上面一樣，大負(fù)載下全都飽和。吞吐量和響應(yīng)時(shí)間也和 Complex 測(cè)試一致。在整個(gè) 3 分鐘的測(cè)試場(chǎng)景中，Crash 的 kernel_oops 方法是在 1 分 30 秒時(shí)提交的，通過(guò)響應(yīng)時(shí)間可以明顯看到其中的變化，響應(yīng)“加快”的原因在于 Socket 連接被服務(wù)器斷開(kāi)造成的（此時(shí)調(diào)用都很快失敗）。saleyn_tcp_serverk 中的 client 通信進(jìn)程由于 name_server 進(jìn)程 crash 而調(diào)用失敗后紛紛退出，造成綁定在該進(jìn)程上的 socket 全部失效而強(qiáng)制關(guān)閉。在這樣的大的吞吐量下，共造成了 99 個(gè)事務(wù)報(bào) Connection Abort（10053）異常。隨后 erlang 監(jiān)控進(jìn)程將 name_server 進(jìn)程啟動(dòng)，服務(wù)恢復(fù)正常。但從測(cè)試結(jié)果來(lái)看，兩臺(tái)測(cè)試機(jī)都有 10 秒左右的受影響時(shí)期，通過(guò)觀察發(fā)現(xiàn)其間不是全部 vsns 服務(wù)調(diào)用都失敗，而是部分正常部分失敗。通過(guò)失敗調(diào)用的吞吐量曲線可以看到，在 13000tps 壓力下 erlang 進(jìn)程 crash 后，在容錯(cuò)重新啟動(dòng)過(guò)程中，對(duì)于 client 來(lái)講每秒會(huì)有50個(gè)左右的調(diào)用請(qǐng)求失敗。同時(shí)在給出的可用物理內(nèi)存曲線中可以看到，進(jìn)程 crash 后有明顯的 5M 內(nèi)存釋放發(fā)生，當(dāng)然這包括 name_server 保存的進(jìn)程字典數(shù)據(jù)。個(gè)人認(rèn)為上面這些可以說(shuō)明，erlang 進(jìn)程的監(jiān)控樹(shù)結(jié)構(gòu)是可以有效達(dá)到容錯(cuò)目的，但在大負(fù)載情況下，服務(wù)的 crash 對(duì)吞吐量影響還是不小的，起碼性能下降不會(huì)很快緩解，當(dāng)然這會(huì)考慮負(fù)載輕重。總體還講還可以，尤其還是在這么爛的臺(tái)式機(jī)上，呵呵。

 

對(duì)服務(wù)容錯(cuò)設(shè)計(jì)的思考

          在進(jìn)行上面所說(shuō)的這個(gè) Crash 場(chǎng)景測(cè)試時(shí)，在考慮是否應(yīng)該將服務(wù)異常或不可用的信息暴露給客戶端應(yīng)用（服務(wù)消費(fèi)者）呢？尤其是服務(wù)間存在互相委托關(guān)系時(shí)，比如開(kāi)發(fā) Service Hub 服務(wù)聚合或是 Service 擴(kuò)展服務(wù)時(shí)。我想這可以有 3 種設(shè)計(jì)：

 

1. 一旦服務(wù)失敗立即返回調(diào)用者，并給出異常描述（原因）。這種設(shè)計(jì)會(huì)將服務(wù)錯(cuò)誤完全暴露，將重試（容錯(cuò)）的機(jī)制依賴到客戶端。
2. 服務(wù)失敗后一直等待服務(wù)就緒，什么時(shí)候正常了，什么時(shí)候重試。雖然容錯(cuò)對(duì)客戶端透明了，但會(huì)引入延遲，對(duì)于實(shí)時(shí)的要求不好滿足。
3. 對(duì)上邊第2點(diǎn)的補(bǔ)充，即服務(wù)重試次數(shù)和等待時(shí)間進(jìn)行限定/可配置。就像erlang otp的supervisor設(shè)計(jì)相似。

          很明顯，第 3 種方式應(yīng)該最有優(yōu)勢(shì)，兼顧了服務(wù)性能和容錯(cuò)處理，當(dāng)然實(shí)現(xiàn)起來(lái)可以也最復(fù)雜了。

 

用到的幾個(gè)優(yōu)化方法

1. 啟用 linux kernel epoll
configure --enable-kernel-poll
erl +K true parameter

2. 擴(kuò)大 linux nproc 和 nofile limits
* soft nproc 2407
* hard nproc 16384
* soft nofile 1024
* hard nofile 65536

3. 擴(kuò)大 linux 和 erlang 端口
echo 1024 65535 > ip_local_port_range
set ERL_MAX_PORTS = 102400

4. 啟用 erlang SMP
erl -smp enable +S 2

5. 擴(kuò)大進(jìn)程數(shù)量
erl +P 102400

6. 擴(kuò)大 linux tcp 協(xié)議棧中讀寫緩沖區(qū)大小，將影響 tcp window 大小
echo "640000" > /proc/sys/net/core/rmem_default
echo "640000" > /proc/sys/net/core/rmem_max
echo "640000" > /proc/sys/net/core/wmem_default
echo "640000" > /proc/sys/net/core/wmem_max

 

          本文涉及的內(nèi)容只涉及基礎(chǔ)性的驗(yàn)證、測(cè)試，未涉及具體的 erlang 軟件，且待我深入研究。Erlang rising~

 

          附件 vsns_perf.zip 為備份目的所添加，請(qǐng)勿下載使用。

 

// 2009.02.16 16:29 添加 ////

 

          關(guān)于 nmon 未能在 ubuntu 8.10 上獲得 cpu wio% 指標(biāo)的問(wèn)題，想到有可能是未以 root 權(quán)限啟動(dòng) nmon 進(jìn)程的原因，不過(guò)能過(guò)剛才驗(yàn)證，結(jié)果還不是一樣，不理想。盡管 vmstat 取得/確認(rèn)了系統(tǒng)已經(jīng)出現(xiàn) wait io，但 nmon 的 wio% 采集結(jié)果還始終是 0。nmon_x86_debian31(11f) 版本對(duì) ubuntu 8.10 的支持很失望。

 

sudo -i

nmon -c310 -s1 -r -f

 

// 2009.02.17 17:04 添加 ////

 

          呵呵，說(shuō)是遲那是快。上面說(shuō)的 nmon （nmon_x86_debian31(11f) 版本）采集的“Wait%” 結(jié)果都是 0 的問(wèn)題，nagger 已經(jīng)確認(rèn) ，并已提供新的 nmon_x86_12a 版本下載 ，包括了最新的 Ubuntu 8.10 系統(tǒng)的 nmon 映像。真的很強(qiáng)悍。

安徽新華電腦學(xué)校專業(yè)職業(yè)規(guī)劃師為你提供更多幫助【在線咨詢】