erl
概述:
Erlang模擬器
描述:
erl程序啓動一個Erlang運行時系統。準確的信息是依賴於系統的(舉例,erl是不是腳本或程序,其它程序調用)。
相反,windows用戶可能想要使用werl程序,它運行在本身帶有滾動條和支持命令行編輯的窗口。Windows上的erl程序在shell沒有提供行編輯,在Windows 95沒法滾回已經滾出屏幕的文本。然而,在管道或若是你想要重定向到標準輸入/輸出,就必須使用erl程序。
在ERTS版本5.9(OTP-R15B),運行時系統默認將不綁定調度器到邏輯處理器。瞭解更多信息,參看+sbt系統標誌的文檔。
導出:
erl <arguments>
啓動一個Erlang運行時系統。參數會被分紅模擬器標誌(emulator flag)、標誌(flags)和簡單的參數(plain arguments):
任何使用字符+啓動的參數被解釋爲emulator flag。
被名稱標明,模擬器標誌控制模擬器的行爲。
任何使用字符-啓動的參數被解釋爲一個應該被傳遞到Erlang運行時部分系統的參數,更具體的說,init系統進程,參看init。
init進程本身解釋一些標誌,init標誌。它也保存任何剩餘的標誌,user標誌。隨後,經過調用init:get_argument/1被檢索。
能夠指出,有少許「-」標誌,如今實際是模擬器標誌。參看下面的描述。
普通參數不管如何不解釋。它們也能夠被init程序保存,經過調用init:get_plain_arguments/0檢索。普通參數可能出如今第一個標誌,或在--標誌以後。另外,-extra標誌致使全部跟在後面的變成普通參數。
例子:
% erl +W w -sname arnie +R 9 -s my_init -extra +bertie
(arnie@host) 1> init:get_argument(sname).
{ok,[["1"]]}
(arnie@host) 2> init:get_plain_arguments().
["+bertie"]
這裏+W w和+R 9都是模擬器標誌。-s my_init是一個是init標誌,被init解釋。-sname arnie是一個用戶標誌,被init保存。它被內核讀取,將致使Erlang運行時系統變成分佈式。最後,跟在-extra(也就是,+bertie)的全部被認爲是普通參數。
% erl -myflag 1
1> init:get_argument(myflag).
{ok,[["1"]]}
2> init:get_plain_arguments().
[]
這裏用戶標誌-myflag 1被傳遞到init進程並保存。這是一個用戶定義標誌,大概被一些用戶定義應用使用。
Flag
在下面的列表,init標識被標記(init 標誌)。除非另有說明,全部其它標誌都是用戶標誌,值能夠經過調用init:get_argument/1檢索。請注意,用戶標誌列表不是詳盡的,可能有額外的,應用特定的標誌相應記錄在對應的應用文檔裏。
--(init flag)
全部跟在--後面到下一個標記(-flag或+flag)的被認爲是原始參數,而且能夠經過init:get_plain_arguments/0檢索;
-Application Par Val
對應用Application設置應用配置參數Par給Val,參見app(4)和application(3);
-args_file FileName
從文件FileName讀取命令行參數。在最終的命令行中,從文件讀取的參數會替換'-args_file FileName'。
文件FileName應該是一個普通的文本文件,包含註釋和命令行參數。註釋以#開始,直到下一個行結束符。反斜槓(\\)被用做轉義字符。全部被erl接收的命令行參數被容許,包括-args_file FileName。可是,當心不要形成遞歸依賴,在文件包含-args_file之間。
-extra是特殊的。它的範圍在文件末尾結束。跟在-extra的參數被移動到-extra部分,好比跟在-extra後面的命令行參數。
-async_shell_start
初始Erlang shell不會讀取用戶輸入直到系統啓動程序已經完成(Erlng5.4或更高)。該標記使啓動同步特性無效,並讓shell並行和其它系統啓動。
-boot File
指定啓動文件名稱File.boot,用來啓動系統。參看init(3)。除非File包含絕對路徑,系統在當前目錄和$ROOT/bin目錄搜索File.boot。
-boot_var Var Dir
若是啓動腳本包含路徑變量Var而不是$ROOT,該變量被擴展成Dir。當應用被安裝在另外一個目錄而不是$ROOT/lib,該變量被使用,參看systools:make_script/1,2。
-code_path_cache
啓動代碼服務器的代碼路徑緩存,參看code(3)。
-compile Mod1 Mod2 ...
編譯指定模塊而後終止(若是有些文件編譯未成功,會返回非零結束碼)。意味着-noinput。不建議使用,建議用erlc。
-config Config
指定配置文件名稱Config.config,被用來配置應用。參看app(4)和application(3)。
-connect_all false
若是有該標記,global不會管理一個全鏈接網絡的分佈式Erlang節點。全局名稱註冊不能使用。參看global(3)。
-cookie Cookie
沒有任何反作用的廢棄標記,-setcookie的通常錯誤拼寫。建議使用-setcookie。
-detached
啓動Erlang運行時系統,與系統控制檯分離。對運行守護進程和後臺程序有用。意味着-noinput。
-emu_args
調試有用。打印發送到模擬器的實際參數。
-env Variable Value
給Erlang運行時系統設置主機OS環境變量Variable到Value。舉例:
% erl -env DISPLAY gin:0
例子中,有設置爲gin:0的DISPLAY環境變量的Erlang運行時系統被啓動。
-eval Expr(init flag)
使init計算表達式Expr,參看init(3)。
-extra(init flag)
全部跟在-extra後面的命令被看作是普通參數,可使用init:get_argument/1被檢索。
-heart
啓動Erlang運行時系統的心跳監控。參看heart(3)。
-hidden
啓動Erlang運行時系統做爲隱藏節點,若是它做爲一個分佈式節點運行。隱藏節點老是和其它節點創建隱藏鏈接,除了相同全局組的節點。隱藏的鏈接不能發佈在任何已鏈接的節點,好比,已鏈接節點都不是在其它節點執行nodes()結果的部分。參看隱藏全局組,global_group(3)。
-hosts Hosts
指定正在運行的Erlang啓動服務器主機的IP地址,參看erl_boot_server(3)。若是標識有-loader inet,該標識是強制的。
IP地址必須以標準格式給出(以句號分隔的四個十進制數字,舉例"150.236.20.74")。不接受主機名稱,可是廣播地址能夠(僅限於本地網絡)。
-id Id
指定Erlang運行時系統的身份。若是做爲分佈式節點,Id必須和一塊兒提供的-sname或-name標記一致。
-init_debug
當解析啓動腳本時,使init寫一些調試信息。
-instr(emulator flag)
選擇儀表化的Erlang運行時系統運行,而不是普通的。當運行一個儀表化的運行時系統,一些資源使用能夠被得到,而且可使用模塊instrument分析。功能上,它表現得像普通的Erlang運行時系統。
—loader Loader
指定使用erl_prim_loader的方法來加載Erlang模塊到系統。參看erl_prim_loader(3)。兩個Loader方法被支持,efile和inet。efile意味着使用本地文件系統,這是默認。inet意味着使用另外一機器上的啓動服務器,而且-id、-hosts和-setcookie標記也必須指定。若是Loader是其它的,用戶提供的Loader端口程序被啓動。
-make
使Erlang運行時系統調用make:all()在當前工做目錄而後終止。參看make(3)。意味着-noinput。
-man Module
顯示Erlang模塊Module的用戶手冊。僅支持Unix。
-mode interactive | embedded
代表系統應該動態加載代碼(interactive),或者全部代碼應該在系統初始化時加載(embedded),參看code(3)。默認interactive。
-name Name
使Erlang運行時系統成爲分佈式節點。該標記調用全部必要網絡服務器使節點成爲分佈式。參看net_kernel(3)。也確保Erlang啓動前epmd運行在當前主機。參看epmd(1)。
節點名稱爲Name@Host,其中Host是當前主機的全限定主機名稱。對於短名稱,使用-sname。
-noinput
確保Erlang運行系統從不嘗試讀取任何輸入。意味着-noshell。
-noshell
啓動沒有shell的Erlang運行時系統。該標記使Elang運行時系統在一系列UNIX管道中做爲組件成爲可能。
-nostick
使Erlang代碼服務器的粘性目錄設施無效。參看code(3)。
-oldshell
調用Erlang3.3的老Erlang shell。老shell能夠被使用。
-pa Dir1 Dir2 ...
增長指定目錄到代碼目錄的開頭,與code:add_pathsa/1相同。參看code(3)。做爲-pa的可供選項,若是幾個目錄自動加到代碼目錄開頭,且目錄有一個共同的父目錄,父目錄能夠在ERL_LIBS環境變量指定。參看code(3)。
-pz Dir1 Dir2 ...
增長指定目錄到代碼目錄的末尾,和code:add_pathsz/1相同。參看code(3)。
-path Dir1 Dir2 ...
替換指定在啓動腳本的目錄。參看script(4)。
-proto_dist Proto
爲Erlang分佈式指定協議。
inet_tcp IPv4的TCP(默認)
inet_tls TLS/SSL的分佈式
inet6_tcp IPv6的TCP
舉例,啓動IPv6分佈式節點
% erl -name test@ipv6node.example.com -proto_dist inet6_tcp
-remsh Node
啓動Erlang,帶有鏈接到Node的遠程shell。
-rsh Program
指定可選項給rsh,對在遠程主機啓動從屬節點。參看slave(3)。
-run Mod [Func [Arg1, Arg2, ...]](init flag)
使init調用指定函數。Func默認是start。若是沒有提供參數,函數被認爲是零參。不然被認爲有一個參數,接收[Arg1,Arg2,...]做爲參數。全部參數做爲字符串傳遞。參見init(3)。
-s Mod [Func [Arg1,Arg2,...]](init flag)
使init調用指定函數。Func默認是start。若是沒有提供參數,函數被認爲是零參。不然被認爲有一個參數,接收[Arg1,Arg2,...]做爲參數。全部參數做爲原子傳遞。參見init(3)。
-setcookie Cookie
設置節點magic cookie爲Cookie。參見erlang:set_cookie/2。
-shutdown_time Time
指定多長時間(毫秒),init進程被容許用於關閉系統。若是Time毫秒已通過去,全部還在運行的進程被殺掉。默認爲infinity。
-sname Name
使Erlang運行時系統成爲分佈式節點,相似於-name。節點名稱Name@Host的主機名稱部分將會是短名稱,不是全限定。
若是DNS未運行,有時候這是惟一運行分佈式Erlang的方式。那些以-sname標記運行的節點和以-name標記運行的節點,它們之間沒有通訊。做爲節點名稱必須是惟一的,在分佈式Erlang系統。
-smp [enable|auto|disable]
-smp enable啓動支持SMP的Erlang運行時系統。這也許會失敗,若是沒有支持SMP的運行時系統可用。-smp auto啓動支持SMP的Erlang運行時系統,若是可用而且檢測到超過一個的邏輯處理器。-smp disable啓動不支持SMP的運行時系統。
-version(emulator flag)
使模擬器打印它的版本數字。和erl +V相似。
Emulator Flags
erl調用Erlang模擬器的代碼,支持以下的標記:
+a size
對於一步線程池的線程,建議的棧大小,以千字計。有效範圍是16-8192千字。默認推薦的棧大小是16千字。好比,在32位架構下是64千字節。異步線程的數量可能至關大,這個小的默認大小已經被選擇。默認大小對於Erlang/OTP實現的驅動是足夠的,可是對於其它動態連接的驅動,也許遠遠不夠大,可使用driver_async()功能。注意傳遞的值僅是一個建議值,在一些平臺,甚至可能被忽略。
+A size
設置異步線程池的線程數量,有效範圍是0-1024。若是線程支持可用,默認是10。
+B [c | d | i]
c選項使Ctrl-C中斷當前shell,而不是調用模擬器中斷處理程序。d選項使中斷處理程序無效(與指定+B,和沒有選項同樣)。i選項使模擬器忽略任何中斷信號。
若是在Unix oldshell使用c選項,Ctrl-C將重啓shell程序,而不是中斷它。
注意在Windows下,該標記僅僅對於werl適用,對erl不適用。也要注意在Windows上,使用Ctrl-Break,而不是Ctrl-C。
+c true | false
啓用或不啓用時間校訂:
true
啓用時間校訂。在特定平臺若是支持時間校訂,該選型默認啓用。
false
不啓用時間校訂。
爲了向後兼容性,該布爾值被忽略。該項被解釋爲+c false。
+C no_time_warp | single_time_warp | multi_time_warp
設置時間扭曲模式:
no_time_warp
無時間扭曲模式(默認)
single_time_warp
單一時間扭曲模式
multi_time_warp
多時間扭曲模式
+d
若是模擬器檢測出一個內部錯誤(或內存溢出),它會默認生成一個崩潰轉儲和一個內核轉儲。然而,內核轉儲也沒什麼用,由於進程堆的內容被崩潰轉儲產生銷燬了。
d選項通知模擬器僅僅產生一個內核轉儲,若是檢測出一個內部錯誤,則不會產生崩潰轉儲。
調用erlang:halt/1帶一個字符串參數也將產生一個崩潰轉儲。在Unix系統,給模擬器進程發送SIGUSR1信號,也將強制產生一個崩潰轉儲。
+e Number
設置ETS表的最大數量。
+ec
對全部ETS表強制使用compressed選項。僅用於測試和評估。
+fnl
虛擬機使用文件名稱,就好像他們使用ISO-latin-1編碼,不容許使用超過255碼點的Unicode字符。
瞭解更多關於文件名稱,參看STDLIB User's Guide。注意該選項也應用於命令行參數和環境變量(參看STDLIB User Guide)。
+fnu[{w|i|e}]
虛擬機處理文件名稱,就好像他們使用UTF-8(或一些其餘系統指定Unicode編碼)。在強制Unicode編碼的操做系統上,這是默認的,好比Windows和MacOS X。
+fnu能夠跟w,i,e切換來控制文件名稱編碼錯誤被報告的方式。w意味着,不管什麼時候,在目錄列表一個文件名稱編碼錯誤被跳過,一個警告被髮送到error_logger;i意味着,文件名稱編碼錯誤被靜默忽略;e意味着,不管什麼時候遇到一個文件名稱編碼錯誤,API函數將返回一個錯誤。默認是w。注意,若是連接指向無效的文件名稱,file:read_link/1老是返回錯誤。
瞭解更多關於文件名稱,參看STDLIB User's Guide。注意該選項也應用於命令行參數和環境變量(參看STDLIB User Guide)。
+fna[{w|i|e}]
選擇+fnl或+fnu基於當前操做系統的本地化設置,意味着若是你的終端已經設置了UTF-8編碼,文件系統預計對文件名稱使用相同的編碼。在全部操做系統上這是默認的,除了MacOSX和Winsdows。
跟隨w,i,e,切換+fna。若是本地化設置致使選擇了+fnu的行爲,這將生效。參看上述+fnu的描述。若是本地化設置致使選擇了+fnl的行爲,那麼w,i,e將沒有效果。
瞭解更多關於文件名稱,參看STDLIB User's Guide。注意該選項也應用於命令行參數和環境變量(參看STDLIB User Guide)。
+hms Size
設置進程的默認堆大小。
+hmbs Size
設置進程的默認二進制虛擬堆大小。
+hpds Size
設置進程的初始進程字典大小。
+K true | false
啓用或不啓用內核輪詢功能,若是模擬器支持。默認是不啓用。若是模擬器不支持內核輪詢,傳遞到模擬器的+K標記,啓動時產生一個警告。
+l
啓用自動負載追蹤,在加載代碼時顯示信息。
+L
不加載關於源文件名稱和行號的信息。這會節約內存,可是異常不會包含關於文件名稱和行號的信息。
+MFlag Value
內存分配器特殊標記,參看erts_alloc(3)瞭解進一步信息。
+n Behavior
控制信號到端口的行爲。
OTP-R16,信號到端口是真正地異步發送。注意信號老是異步地被記錄。然而,之前底層實現,同步發送這些信號。正確編碼的Erlang程序應該能處理這些問題。然而,Erlang程序存在的Bug,關於信號到端口作出錯誤的假設,很難發現。這種切換被引入爲了更容易地比較過渡期間的行爲。注意,在介紹時,這個標記被廢棄,並計劃在OTP-R17中移除。Behavior應該是下面字符之一:
d
默認值。異步信號。發送信號到端口的程序繼續執行,在信號已經到達端口以前。
s
同步信號。發送信號到端口的進程繼續執行直到信號已經發送。僅應該用於測試和調試。
a
異步信號。默認值。但發送信號的進程甚至將頻繁地繼續執行,在信號已達到端口以前。僅應該用於測試和調試。
+pc Range
設置字符範圍,系統將以啓發式字符檢測考慮打印。這將顯著影響shell、調試器和io:format函數。
當前,Range支持兩個值:
latin1
默認。只有ISO-latin-1範圍的字符認爲是可打印的。這意味着字碼大於255的字符將被認爲是不可打印的,包含這些字符的列表將顯示成整數列表而不是文本字符。
unicode
當肯定一個整數列表是否以字符串語法顯示,全部可打印unicode字符都被考慮。若是你的字體未覆蓋全部unicode字符,這將給出未預料的結果。
+P Number | legacy
設置系統同時存在進程的最大數量,若是Number有值。Number有效範圍是[1024-134217727]。
注意:
實際最大選擇的數量可能遠遠比傳遞的Number大。當前運行時系統常常,但不是老是,選擇2的冪的值。然而,這也許在將來改變。實際選擇的值可經過調用erlang:system_info(process_limit)校驗。
默認值爲262144。
若是傳的值爲legacy,將使用進程標識符分配的遺產算法。使用遺產算法,標識符將以嚴格增地方式分配直到達到最大可能的標識符。注意,該算法存在性能問題,在某些狀況下可能很是昂貴。遺產算法被廢棄,而且legacy選項計劃在OTP-R18被移除。
+Q Number | legacy
設置系統同時存在端口的最大數量,若是Number有值。Number有效範圍是[1024-134217727]。
注意:
實際最大選擇的數量可能遠遠比傳遞的Number大。當前運行時系統常常,但不是老是,選擇2的冪的值。然而,這也許在將來改變。實際選擇的值可經過調用erlang:system_info(port_limit)校驗。
正常使用的默認值是65536。然而,若是運行時系統可以決定所能打開的最大描述符數量,這個值大於65536,選擇的值將增大到大於或等於能夠打開的最大描述符數量。
在Windows,默認值設置爲8196,由於正常OS限制設置比大多數機器所能處理的要高。
之前環境變量ERL_MAX_PORTS被用於設置同時打開的最大端口數量。這個環境變量廢棄了,計劃在OTP-R17中移除,但仍是能夠是使用。
若是傳的值爲legacy,將使用端口標識符分配的遺產算法。標識符將以嚴格增地方式分配直到達到最大可能的標識符。注意,該算法存在性能問題,在某些狀況下可能很是昂貴。遺產算法被廢棄,而且legacy選項計劃在OTP-R18被移除。
+R ReleaseNumber
設置兼容模式。
分佈式機制默認不向後兼容。該標記使用早先的Erlang/OTP發佈版本將模擬器設置爲兼容模式。該發佈號必須在<current release>-2到<current release>範圍內。這限制了模擬器,使它可以和早先的版本的Erlang節點通訊(包括C和Java節點)。
注意:確保一個分佈式Erlang系統發佈的全部節點都是相同的Erlang/OTP版本,或者兩個不同的Erlang/OTP版本X和Y,其中,全部Y節點兼容X。
+r
在realloc時,強制ets內存塊移動。
+rg ReaderGroupsLimit
在Erlang運行時系統,限制爲讀操做使用讀/寫鎖優化的讀組數量。默認讀組的數量限制等於64。
當調度器的數量少於或等於讀組限制,每一個調度器有本身讀組。當調度器的數量大於讀組限制,調度器共享讀組。當大量讀組下降寫鎖性能,共享的讀組下降讀加鎖和讀解鎖性能,因此在讀操做性能和寫操做性能的限制是一種權衡。每一個讀組當前消耗64字節在每一個讀/寫鎖。也要注意,一個運行時系統使用共享讀組受益於"綁定調度器到邏輯處理器",因爲讀組在調度器之間的分佈比較好。
+S schedulers:SchedulerOnline
當啓用SMP支持,設置要建立的調度器線程和設置在線的調度器線程的數量。這兩個值的最大值是1024。若是Erlang運行時系統可以決定配置的邏輯處理器和可用邏輯處理器的數量;不然,默認值爲1。Schedulers可能被忽略,若是SchedulerOnline不對,反之亦然。經過調用erlang:system_flag(schedulers_online, SchedulersOnline,能夠在運行時改變在線調度器的數量)。
若是Schedulers和SchedulersOnline被指定爲一個負數,配置的邏輯處理器默認值或可用的邏輯處理器分別被減去這個值。
對Schedulers或SchedulersOnline指定爲零,會分別重置調度器線程或在線調度器線程的數量到默認值。
若是模擬器沒有啓用SMP支持,該選項被忽略(參看-smp標記)。
+SP SchedulersPercentage:SchedulersOnlinePercentage
當啓用SMP支持,和+S相似,使用百分比設置要建立的調度器線程,基於配置的邏輯處理器,和設置在線的調度線程,基於邏輯可用的邏輯處理器。指定值必須大於零。舉例,+SP 50:25設置調度器線程數量爲配置的邏輯處理器的50%和調度器線程的在線數量爲可用邏輯處理器的25%。SchedulersPercentage可能被忽略,若是SchedulerOnlinePercentage不對,反之亦然。經過調用erlang:system_flag(schedulers_online, SchedulersOnline),能夠在運行時改變在線調度器的數量)。
該選項和+S設置相互影響。舉例,在一個配置的8邏輯核心和可用的8邏輯核心的系統,選項+S 4:4 +SP 50:25(或另外的順序)的組合結果是2個調度器線程(4的50%)和1個在線調度器線程(4的25%)。
若是模擬器沒有啓用SMP支持,該選項被忽略(參看-smp標記)。
+SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersOnline
設置要建立的髒CPU調度器線程數量和設置在線的髒CPU調度器線程,當線程支持已經啓用。這兩個值最大是1024,而每一個值被正常的調度器的設置進一步限制:建立的髒CPU調度器線程的數量不能超過正常建立的調度器線程數量,在線的髒CPU調度器線程數量不能超過在線正常的調度器線程數量(瞭解更多細節,參看+S和+SP標記)。默認,建立的髒CPU調度器線程的數量等於正常建立的調度器線程數量,而在線髒CPU調度器線程數量等於在線正常的調度器線程數量。DirtyCPUSchedulers可能被忽略,若是DirtyCPUSchedulersOnline不對,反之亦然。經過調用 erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline),能夠在運行時改變在線髒CPU調度器的數量)。
若是模擬器未啓用線程支持,該選項被忽略。當前,該選項是試驗性的。只有模擬器被配置和編譯啓用髒調度器支持,纔可用(默認不啓用)。
+SDPcpu DirtyCPUSchedulersPercentage:DirtyCPUSchedulersOnlinePercentage
當啓用線程支持,相似+SDcpu,但使用百分數設置要建立的髒CPU調度器線程數量和設置在線髒CPU調度器線程數量。指定值必須大於零。舉例,+SDPcpu 50:25設置髒CPU調度器線程數量爲配置的邏輯處理器的50%和在線髒CPU調度器線程爲可用邏輯處理器的25%。 DirtyCPUSchedulersPercentage可能被忽略,若是DirtyCPUSchedulersOnlinePercentage 不對,反之亦然。經過調用 erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).,能夠在運行時改變在線髒CPU調度器的數量)。
該選項和+SDcpu設置相互影響。舉例,在一個配置的8邏輯核心和可用的8邏輯核心的系統,選項+SDcpu 4:4 +SDPcpu 50:25(或另外的順序)的組合結果是,2個髒CPU調度器線程(4的50%)和1個在線髒CPU調度器線程(4的25%)。
若是模擬器未啓用線程支持,該選項被忽略。目前,該選項是試驗性的。只有模擬器被配置和編譯啓用髒調度器支持,纔可用(默認不啓用)。
+SDio IOSchedulers
當啓用線程支持,設置要建立的髒I/O調度器線程數量。有效範圍是0-1024。默認,被建立的髒I/O調度器線程數量是10,和在異步線程池的默認線程數量同樣。
若是模擬器未啓用線程支持,該選項被忽略。目前,該選項是試驗性的。只有模擬器被配置和編譯啓用髒調度器支持,纔可用(默認不啓用)。
+sFlag Value
調度特定標記。
+sbt BindType
設置調度器綁定類型。
調度器也可使用+stbt標記被綁定。這兩個標記之間惟一不一樣的是下面的錯誤如何被處理:
在特定平臺,調度器的綁定不支持;
沒有可用的CPU拓撲。就是運行時系統不能自動探測CPU拓撲,而且沒有用戶自定義CPU拓撲被設置。
當使用+sbt,發生任何錯誤,運行時系統會打印一個錯誤消息,而且拒絕啓動。當使用+stbt,發生任何錯誤,運行時系統會靜默忽略錯誤,啓動使用未綁定的調度器。
當前有效的BindTypeS:
u
unbound-調度器不會綁定到邏輯處理器,好比,操做系統決定調度線程執行位置,和何時移動它們。這是默認的。
ns
no_spread-帶有關閉調度器標識符的調度器會盡量近綁定硬件。
ts
thread_spread-引用硬件線程的線程(好比,英特爾的超線程)。帶有低調度器標識符的調度器,會綁定到每一個核心的第一個硬件線程,而帶有更高等級調度器標識符的調度器會綁定到每一個核心的第二個硬件線程,等等。
ps
processor_spread-調度器會傳播像thread_spread,但也在物理處理器芯片之上。
s
spread-調度器儘量的傳播。
nnts
no_node_thread_spread-像thread_spread,但若是多個NUMA(不一致內存訪問)節點存在,調度器將每次在一個NUMA節點上傳播。好比,全部一個NUMA節點的全部邏輯處理器將逐一綁定處處理器。
nnps
no_node_processor_spread-像process_spread,但若是多個NUMA節點存在,調度器將每次在一個NUMA節點上傳播。好比,全部一個NUMA節點的全部邏輯處理器將逐一綁定處處理器。
tnnps
thread_no_node_processor_spread-thread_spread和no_node_processor_spread的組合。在NUMA節點上,調度器在硬件線程上傳播,但調度器內部上,只會逐一在一個NUMA節點在處理器上傳播。
db
default_bind-默認方式綁定調度器。當前默認是thread_no_node_processor_spread(未來可能會變)。
處理器的綁定當前僅被支持,在更新的Linux、Solaris、FreeBSD和Windows系統。
若是沒有CPU拓撲可用,當+sbt標記被處理,而BindType是其它類型而不是u,運行系統會啓動失敗。CPU拓撲使用+sct標記被定義。注意在命令行的+sbt標記前,+sct標記可能不得不被傳遞(這種狀況,沒有CPU拓撲自動被探測)。
運行時系統默認將不綁定調度器到邏輯處理器。
注意:若是Erlang運行時系統是惟一的操做系統進程,綁定線程到邏輯處理器,這提高運行時系統的性能。然而,若是其餘操做系統進程(例如另外一個Erlang運行時系統)也綁定線程到邏輯處理器,也許反而是一個性能懲罰。在一些狀況下,這種性能懲罰可能嚴重。在這種狀況下,建議你不要綁定調度器。
調度器被綁定如何起做用。舉個例子,在這種狀況,在線調度器少於運行程序,運行時系統嘗試移動進程到低調度器標識符的調度器。更多調度器在硬件上傳播,在這種狀況下,運行時系統有更多的可用資源。
注意:若是調度器綁定失敗,這將會靜默忽略。這是由於它不老是驗證有效邏輯進程標識符。若是一個錯誤被報告,它會報告給error_logger。若是你想要驗證調度器實際已經按請求被綁定,調用erlang:system_info(scheduler_bindings)。
+sbwt none|very_short|short|medium|long|very_long
設置調度器忙等待閾值。默認是medium。這個閾值決定進入休眠前調度器應該忙等待多久。
注意:這個標誌隨時可能被移除或改變,恕不另行通知。
+scl true|false
啓用或停用調度器負載壓緊。默認調度器負載壓緊啓用。當啓用,負載均衡將爭取負載分佈,會致使儘量多的調度器線程被負載。這經過移動負載到更小集合的調度器完成,當調度器頻繁不工做。當停用,那些頻繁不工做的線程將不被負載均衡邏輯考慮在內。
+scl false相似於+sub true,不一樣在於+sub true還會在調度器間平衡調度器利用。
+sct CpuTopology
<Id> = integer(); when 0 =< <Id> =< 65535
<IdRange> = <Id>-<Id>
<IdOrIdRange> = <Id> | <IdRange>
<IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>
<LogicalIds> = L<IdList>
<ThreadIds> = T<IdList> | t<IdList>
<CoreIds> = C<IdList> | c<IdList>
<ProcessorIds> = P<IdList> | p<IdList>
<NodeIds> = N<IdList> | n<IdList>
<IdDefs> = <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds> | <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>
CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>
設置用戶自定義CPU拓撲。用戶自定義CPU拓撲將覆蓋任何自動檢測的CPU拓撲。當綁定調度器到邏輯處理器時,使用CPU拓撲。
大寫字母意味着真實標識符,而小寫字母意味着假的標識符,僅用於拓撲描述。傳遞真實標識符,當嘗試訪問特定硬件可能被實時系統使用,若是它們不對,行爲是未定義的。假的邏輯CPU標識符不被接受,由於在定義CPU拓撲沒有真實邏輯CPU標識符是沒有意義的。線程、內核、處理器和節點標識符可能被忽略。若是忽略,線程id默認t0,內核id默認c0,處理器id默認p0,節點id將沒有定義。每一個邏輯處理器要麼必須是一個且只有一個NUMA節點,要麼沒有邏輯處理器必須屬於任何NUMA節點。
容許增長和減小<IdRange>s。
NUMA節點標識符在系統範圍。也就是說,系統上的每一個NUMA節點必須有一個惟一標識符。進程標識符也在系統範圍。內核標識符在處理器範圍。線程標識符在內核範圍。
標識符類型的順序隱含CPU拓撲層級。有效的順序要麼是<LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>,要麼是<LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>。也就是說,線程是內核的一部分,內核是處理器的一部分,處理器又是NUMA節點的一部分,或者線程是內核的一部分,內核是NUMA節點的一部分,NUMA節點是處理器的一部分。一個CPU拓撲能夠組成外部處理器和處理器內部NUMA節點,只要每一個邏輯處理器屬於一個且只有一個NUMA節點。若是<ProcessorIds>被省略,它默認位置將會在<NodeIds>以前。也就是說,默認是處理器外部NUMA節點。
若是在一個<IdDefs>中,使用標識符列表:
- <LogicalIds>必須是一個標識符列表;
- 至少有另一個標識符類型除了<LogicalIds>也必須有一個標識符列表;
- 全部標識符列表必須產生一樣數量的標識符。
一個簡單例子。一個四核處理器也許這種方式描述:
% erl +sct L0-3c0-3
1> erlang:system_info(cpu_topology).
[{processor,[{core,{logical,0}},
{core,{logical,1}},
{core,{logical,2}},
{core,{logical,3}}]}]
一個有一點複雜的例子。兩個四核處理器。每一個處理器在它本身的NUMA節點。邏輯處理器的順序有一點奇怪。這是爲了給標識符列表一個更好的示例:
% erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1> erlang:system_info(cpu_topology).
[{node,[{processor,[{core,{logical,0}},
{core,{logical,1}},
{core,{logical,3}},
{core,{logical,2}}]}]},
{node,[{processor,[{core,{logical,7}},
{core,{logical,4}},
{core,{logical,6}},
{core,{logical,5}}]}]}]
只要真實標識符是正確的,傳遞一個CPU拓撲,不是一個正確的CPU拓撲描述,也是能夠的。在使用時,這其實是很是有用的。這是爲了欺騙模擬器綁定它的調度器。舉例,若是你想要運行多個Erlang運行時系統在相同的機器,你想要減小使用的調度器數量和操做CPU拓撲來使它們綁定到不一樣邏輯CPUs。一個例子,在一個四核機器運行兩個Erlang運行時系統:
% erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
% erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two
在這個例子,每一個運行時系統有兩個調度器在線,全部在線調度器運行在不一樣核心。若是咱們改變一個在線調度器到一個運行時系統,和三個在線調度器到另外一個,全部在線調度器將仍是運行在不一樣核心。
注意,一個假CPU拓撲不會反應真實CPU拓撲的樣子,可能下降運行時系統的性能。
瞭解更多信息,參看erlang:system_info(cpu_topology)。
+sfwi Interval
設置調度器強制喚醒間隔。每個間隔毫秒,全部運行的隊列都將被掃描。當系統中有睡眠調度程序時,會爲找到的每一個非空運行隊列喚醒一個調度器。一個0的間隔禁用這個特性,這也是默認的。
這一特性已經被引入做爲一種臨時的解決方法,用於冗長的執行本地代碼,以及在OTP中不適當地下降reduction的本機代碼。當這些錯誤被修復時,將刪除+sfwi標誌。
+stbt BindType
嘗試設置調度器綁定類型。與+sbt標記相同,除了如何處理一些錯誤以外。要了解更多信息,請參閱+sbt標誌的文檔。
+sws very_eager|eager|medium|lazy|very_lazy
設置調度器喚醒清理閾值。默認是medium。這個標誌控制了調度程序因爲某些清理操做而請求喚醒的急切程度。當使用惰性設置時,當調度程序處於空閒狀態,能夠將更出色的清理操做保留下來。當使用一個eager設置時,調度程序將更頻繁的被喚醒,從而可能增長cpu利用率。
注意:此標誌能夠在任什麼時候候刪除或更改,而無需事先通知。
+sws default|legacy
設置調度程序喚醒策略。默認策略在erts-5.10/OTP-R16A中改變。這一策略之前被稱爲OTP-R15的提案。遺留策略在R13上被用做默認值,包括R15。
注意:此標誌能夠在任什麼時候候刪除或更改,而無需事先通知。
+swt very_low|low|medium|high|very_high
設置調度程序喚醒閾值。默認是medium。當更多的工做超出了當前清醒的調度程序的處理時,閾值決定了什麼時候喚醒睡眠調度程序。較低的閾值將致使較早的喚醒,而高閾值將致使稍後的wakeups。早期的wakeups將會更快的分配多個調度程序,可是工做將更容易在調度程序之間來回切換。
注意:此標誌能夠在任什麼時候候刪除或更改,而無需事先通知。
+spp Bool
爲端口並行設置默認的調度器。若是設置爲true,VM將調度端口任務,這時它能夠改善系統中的並行性。若是設置爲false,VM將嘗試當即執行端口任務,從而以犧牲並行性爲代價來提升延遲。若是該標誌沒有被傳遞,則默認的調度程序提示端口並行性目前是錯誤的。默認的使用能夠在運行時經過調用erlang:system_info(port_parallelism)來檢查。默認狀況下,經過將並行選項傳遞給open_port/2,能夠在端口建立上覆蓋。
+sss size
建議的堆棧大小,以千字計,用於調度器線程。有效範圍是4-8192千字。默認的堆棧大小取決於操做系統。
+t size
設置VM能夠處理的最大原子數量。默認是1048576。
+T Level
支持修改的定時,並設置修改的定時級別。目前有效範圍是0-9。運行時系統的定時將會改變。高水平一般意味着比低水平更大的變化。更改定時對於查找與時間相關的bug很是有用。
目前,修改定時影響以下:
進程分裂
調用spawn、spawn_link、spawn_monitor或spawn_opt的進程在完成調用後將會當即被換出調度器。當使用更高的修改定時級別時,調用者在被調度後也會休眠一段時間。
上下文reductions
一個進程在被調度以前容許使用的reductions是增長或減小的。
輸入reductions
在檢查I/O以前執行的reductions增長或減小。
注意:當啓用修改的定時,性能將受到影響。此標誌僅用於測試和調試。還要注意,在跟蹤衍生BIFs時,返回和返回的跟蹤消息將丟失。此標誌能夠隨時刪除或更改,無需事先通知。
+V
使模擬器打印出它的版本號。
+v
詳細的。
+W w | i
爲error_logger設置警告消息的映射。使用其中之一警告程序發送給 error logger 的消息能夠被映射到 errors (默認)、warnings(+W w)或
info reports(+W i)。當前的映射可使用error_logger:warning_map/0來檢索。請參閱error_logger(3)以得到更多消息。
+zFlag Value
混雜的標記。
+zdbbl size
設置分配緩衝區繁忙的限制,以千字節計(dist_buf_busy_limit)。有效範圍是1-2097151。默認是1024。
更大的緩衝區限制容許進程在分配上緩衝更多傳出的消息。當達到緩衝區限制時,發送過程將被暫停,直到緩衝區的大小縮小。緩衝區的限制是每一個分配通道。更高的限制會下降延遲和更高的吞吐量,而犧牲更高的內存使用。
Environment variables
ERL_CRASH_DUMP
若是模擬器須要寫一個崩潰轉儲,這個變量的值將是崩潰轉儲文件的文件名。若是該變量沒有設置,崩潰轉儲文件的名稱將會是erl_crash.dump,在當前目錄中轉儲。
ERL_CRASH_DUMP_NICE
Unix系統:若是模擬器須要寫一個崩潰轉儲,它將使用這個變量的值來設置進程的 nice 值,從而下降它的優先級。容許的範圍是1-39(更高的值將被替換爲39)。最高的值,39,將使這個過程稱爲最低的優先級。
ERL_CRASH_DUMP_SECONDS
Unix系統:這個變量給出了模擬器被容許用來編寫崩潰轉儲的秒數。當給定的秒數已通過去時,模擬器將被一個 SIGALRM 信號終止。
若是環境變量沒有設置,或設置爲0秒,ERL_CRASH_DUMP_SECONDS=0,運行時系統甚至不會嘗試編寫崩潰轉儲文件,它只會終止。
若是環境變量被設置爲負值,例如 ERL_CRASH_DUMP_SECONDS=-1,運行時系統將無限期等待崩潰轉儲文件的編寫。
若是心跳在運行,這個環境變量就會被用於心跳:
ERL_CRASH_DUMP_SECONDS = 0
徹底抑制寫入崩潰轉儲文件,從而當即從新啓動運行時系統。這與不設置環境變量是同樣的。
ERL_CRASH_DUMP_SECONDS = -1
將環境變量設置爲負值,將致使運行時系統的終止,直到崩潰轉儲文件被徹底寫入。
ERL_CRASH_DUMP_SECONDS = S
將等待S秒來完成崩潰轉儲文件,而後終止運行時系統。
ERL_AFLAGS
這個環境變量的內容將被添加到erl命令行的開頭。
-extra 標記是特殊處理的。它的範圍在環境變量內容的末尾結束。跟在 -extra 標記後的參數被移動到命令行的 -extra部分,即在 -extra標記以後的命令後結束。
ERL_ZFLAGS and ERL_FLAGS
這些環境變量的內容將被添加到erl命令行的開頭。
-extra 標記是特殊處理的。它的範圍在環境變量內容的末尾結束。跟在 -extra 標記後的參數被移動到命令行的 -extra部分,即在 -extra標記以後的命令後結束。
ERL_LIBS
這個環境變量包含一個額外的目錄庫列表,代碼服務器將搜索應用程序並添加到代碼路徑中。參見code(3)。
ERL_EPMD_ADDRESS
這個環境變量能夠被設置爲一個逗號分隔的IP地址列表,在這種狀況下,epmd守護進程只會監聽指定的地址(es)和環回地址(若是沒有指定的話,它會隱式地添加到列表中)。
ERL_EPMD_PORT
這個環境變量能夠包含在與epmd通訊時使用的端口號。默認端口在大多數狀況下均可以正常工做。能夠指定一個不一樣的端口,以容許獨立集羣的節點在同一個主機上共存。集羣中的全部節點都必須使用相同的epmd端口號。
Configuration
標準的Erlang/OTP系統能夠被從新配置,以改變啓動時的默認行爲。
The .erlang Start-up File
當Erlang/OTP啓動時,系統會在Erlang/OTP啓動的目錄中搜索名爲.erlang的文件。若是沒有找到,用戶的主目錄將被搜索.erlang文件。
若是找到了Erlang文件,那麼它被認爲包含了有效的Erlang表達式。這些表達式被評估爲它們是對shell的輸入。
典型的erlang文件包含一組搜索路徑,例如:
io:format("executing user profile in HOME/.erlang\n",[]).
code:add_path("/home/calvin/test/ebin").
code:add_path("/home/hobbes/bigappl-1.2/ebin").
io:format(".erlang rc finished\n",[]).
user_default and shell_default
在shell中不預先固定的函數被假定爲功能性對象(Funs)、內置函數(BIFs),或者屬於模塊user_default或shell_default。
要包含私人shell命令,請在模塊user_default中定義它們,並將下列參數添加爲.erlang文件中的第一行。
code:load_abs("..../user_default").
erl
若是定義了.erlang的內容,而且定義了user_default的私有版本,那麼就能夠定製Erlang/OTP環境。能夠經過在啓動腳本erl中提供命令行參數來進行更強大的更改。有關進一步信息,請參閱erl(1)和init(3)。