http://shiningray.cn/some-facts-about-erlang-and-smp.html

原文：http://groups.google.com/group/erlang-questions/browse_thread/thread/7827f5e32681ca8e

by.Kenneth Erlang/OTP team, Ericsson
譯：ShiningRay

以下是一些Erlang SMP實現的細節和與性能與伸縮性相關一些簡單介紹。

幾周之內還有有一個關于多核如何運作以及未來如何發展的更詳細的介紹。我打算將一些內容放在我的報告中，將于9月27日的ICFP2008，Erlang Workshop在Victoria BC展示給大家。

沒有SMP支持的Erlang VM只有1個運行在主處理線程中的調度器。該調度器從運行隊列（run-queue）中取出可以運行的Erlang進程以及IO任務，而且因為只有一個線程訪問他們所以無須鎖定任何數據。

而帶有SMP支持的Erlang VM可以有一個或多個調度器，每個運行在一個線程中。調度器從同一個公共運行隊列中取出可運行的Erlang進程和IO任務。在SMP VM中所有的共享數據結構都會由鎖進行保護，運行隊列就是這樣一個由鎖保護的數據結構。

從OTP R12B開始，如果操作系統報告有多于1個的CPU（或者核心）VM的SMP版本會自動啟動，并且根據CPU或者核心的數量啟動同樣數量的調度器。

你可以從“erl”命令打印出來的第一行看到它選擇了哪些參數。例如：

Erlang (BEAM) emulator version 5.6.4 [source] [smp:4] [asynch-threads:0] …..
其中“[smp:4]”表示SMP VM運行了4個調度器。

默認值可以用“-smp [enable|disable|auto]”來替換，auto是默認的。如果smp被啟用了（-smp enable），要設置調度器的數量可以使用“+S Number”其中Number是調度器的數量（1到1024）

注意1：運行多于CPU或核心總數的調度器不會有任何提升。

注意2：在某些操作系統中一個進程可使用的CPU或者核心的數量可以被限制。例如，在Linux中，命令“taskset”就可以實現這個功能。 Erlang VM目前還只能探測CPU或者核心的總數，不會考慮“taskset”所設置的掩碼。正因如此，例如可能會出現（已經出現過了）即使Erlang VM運行了4個調度器，也只使用了2個核心。OS會進行限制因為它要考慮“taskset”所設置的掩碼。

每個Erlang VM的調度器都運行于一個OS線程上，是OS來決定線程是否執行在不同的核心上。一般來說OS會很好地處理這個問題并且會保證線程在執行期間運行于同一個核心上。

Erlang進程會被不同的調度器運行，因為他們是從一個公共運行隊列中被取出，由首先可用的調度器運行。

性能和伸縮性

只有一個調度器的SMP VM要比非SMP的VM稍微慢那么一點點。SMP VM內部需要用到各種鎖，不過只要不存在鎖的爭用，那么由鎖引起的開銷不會非常大（就是鎖爭用上面需要花時間）。這也解釋了為何在某些情況下，運行多個只有一個調度器的SMP VM要比包含多個調度器的單一SMP VM更加高效。當然運行多個VM要求應用可以按照多個并行任務的方式運行并且之間沒有或者幾乎不通訊。

一個程序是否能在多核上的SMP VM中良好地進行提升很大程度上取決于程序的性質，某些程序可以保持線性提升至8核甚至16核，同時其他某些程序基本不能提升，連2核都不行。實際應用中很多程序都能在主流市場的核心數上得到提升，見下文。

若并行的持續“通話”由每個核心一個或多個Erlang進程來表示，實際的支持大量通話的電信產品已經先現出在雙核和四核處理器上不俗的伸縮性。注意，這些產品是在SMP VM和多核處理器出現很久以前按照普通的Erlang風格來寫的，他們也能無須任何修改甚至不需重新編譯代碼就能從Erlang SMP VM中獲益。

SMP性能得到持續改進

SMP實現正被不斷改進以便能得到更好的性能和伸縮性。在每個服務發布版R12B-1,2,3,4,5…,R13B等等中，你都能發現新的優化。

一些已知的瓶頸

單一的常見運行隊列隨著CPU或核心的數量的增加會成為一個顯著的瓶頸。

這從4核開始往上就會顯現出來，不過4核仍然可以為多數應用程序提供不錯的性能。我們正在從事一個每個調度器一個運行隊列的解決方法作為目前最重要的改進。

Ets表格會引入鎖。在R12B-4之前在每次對一個ets-table的訪問中會用到兩個鎖，但是在R12B-4中meta-table的鎖被優化過，可以顯著減少爭用（前面已經提到爭用是有很大代價的）。如果很多Erlang進程訪問同一個表格，就會有很多鎖爭用造成性能降低尤其當這些進程主要工作是訪問ets-table。鎖存在于表級而非記錄級。注意！這也會影響到Mnesia因為Mnesia用到了很多ets-table。

我們關于SMP的策略

當我們開始實現SMP VM的最初，我們就確定了策略：“首先讓它可以運行，然后測量，然后優化”。自從2006年五月我們發布了第一個穩定的SMP VM（R11B）以來，我們一直遵循著這個策略。

還有更多已知的東西可以改進，我們會按照性能的收益大小先后各個擊破。

我們將主要的精力放在多核（大于4）上更好的連續伸縮性上。

卓越典范

即使SMP系統有還有一些已知的瓶頸不過已經有不錯的整體性能和伸縮性，同時我相信在讓程序員利用多核機器事半功倍方面，我們是一個卓越的典范。