第五章運(yùn)行時(shí)度量
復(fù)習(xí)題
注意：要實(shí)踐第五章，需要安裝書中推薦的recon庫。其中很多的回答，都是使用recon庫。
-
關(guān)于 Erlang 的內(nèi)存,可以報(bào)告出哪些類型的信息?
- 主要考察erlang:memeroy()的返回
<pre>
erlang:memory().
[{total,64454856},
{processes,15598896},
{processes_used,15597800},
{system,48855960},
{atom,1139889},
{atom_used,1137782},
{binary,218312},
{code,28901739},
{ets,1015168}]
</pre>
- 主要考察erlang:memeroy()的返回
如果想了解進(jìn)程的總體情況,可以做的有價(jià)值的度量是什么?
-
什么是端口?如何了解其總的信息?
- 端口：一種數(shù)據(jù)類型,涵蓋了各種和外部世界通信的連接和socket:TCP socket、UDP socket、SCTP socket、文件描述符
<pre>
recon:port_types().
[{"tcp_inet",50},
{"efile",5},
{"2/2",1},
{"inet_gethost 4 ",1},
{"tty_sl -c -e",1}]
</pre> -
對于 Erlang 系統(tǒng),為什么不能用 top 或者 htop 來獲取 CPU 的使用率?可用的備選
方法是什么?原因：調(diào)度器調(diào)度和進(jìn)程實(shí)際工作都會消耗cpu資源，導(dǎo)致無法區(qū)分是調(diào)度工作忙還是進(jìn)程運(yùn)行忙。
-
備選方案：測量wall_clock,調(diào)度器鐘表時(shí)間。
<pre>
recon:scheduler_usage(1000)
</pre>
這個(gè)值是T1/T2,其中
T1:調(diào)度器花在運(yùn)行進(jìn)程、常規(guī)的 Erlang 代碼、NIF、BIF、垃圾回收等上的時(shí)間；T2:花在空轉(zhuǎn)以及調(diào)度進(jìn)程上的時(shí)間；
顯然，wall_clock越大，表示調(diào)度器越忙。
請說出兩種可獲取到的和進(jìn)程信號有關(guān)的信息?
-
如何找到進(jìn)程當(dāng)前正在運(yùn)行的代碼?
- recon:info(Pid),返回有current stacktrace項(xiàng)，對應(yīng)的結(jié)果就是。z
-
對于一個(gè)特定進(jìn)程來說,可以獲取到不同種類的內(nèi)存信息分別是什么?
- binary: refc binary
- garbage_collection:
- heap_size:最新代的堆大小
- memory
- message_queue_len
- messages
- total_heap_size:包含所有其他部分的堆,包括老堆
如何知道進(jìn)程工作量的大小?
recon:info(Pid),找出reduction值-
請列舉出在生產(chǎn)系統(tǒng)中檢查進(jìn)程時(shí),獲取起來不安全的信息。
- messages
recon:info(pid(0,1042,0),messages).
返回進(jìn)程郵箱中的所有消息。在生產(chǎn)環(huán)境中,這個(gè)調(diào)用是極度危險(xiǎn)的,比如,
如果正在調(diào)試某個(gè)進(jìn)程而導(dǎo)致它被鎖住,那么其郵箱中會堆積上百萬條消息。 一定要先調(diào)用 message_queue_len 以確保安全。recon:info(Pid)默認(rèn)不會返回messages
- messages
sys 模塊中針對 OTP 進(jìn)程提供了哪些功能?
-
在檢查 inet 端口時(shí),可以得到哪些信息?
- 元信息
- 信號
- IO
- 內(nèi)存使用
- 特定類型
-
如何得到端口的類型(文件、TCP、UDP)?
- recon:port_info("#Port<0.818.0>")
開放問題
- 在進(jìn)行全局性度量時(shí),為何需要長的時(shí)間窗口?
- 時(shí)間窗口會采樣兩次，如果選用長時(shí)間窗口，自然會忽視短生命周期的進(jìn)程。因?yàn)樽龅檬侨中远攘浚孕枰L生命周期的進(jìn)程數(shù)據(jù)
- 針對如下的每一項(xiàng),分別說說在需要定位和其相關(guān)的問題時(shí),recon:proc_count/2 和
recon:proc_window/3 哪一個(gè)更合適?
a) reduction
b) 內(nèi)存
c) 消息隊(duì)列長度- reduction,recon:proc_window更適合。因?yàn)殚L期reduction總是累加數(shù)值，對于長生命周期的進(jìn)程，自然數(shù)值很大，所以需要指定時(shí)間窗口。找出一定時(shí)間之內(nèi)，消耗reduction較大的數(shù)值。
- 內(nèi)存，recon:proc_count更適合。內(nèi)存就是本身一個(gè)累積量。
- 消息隊(duì)列長度，recon:proc_window更適合。可能是一段時(shí)間之內(nèi)，出現(xiàn)消息堆積。此時(shí)需要指定時(shí)間區(qū)間(但是recon:proc_count返回當(dāng)前的數(shù)值，感覺也適合)
- 如何找到某個(gè)給定進(jìn)程的 supervisor?
recon:info()中的meta信息中的'$ancestors' - 什么情況下使用 recon:inet_count/2? 什么情況下使用 recon:inet_window/3?
- 當(dāng)前情況下用recon:inet_count/2(快照)；持續(xù)累積的情況下用后者
- 操作系統(tǒng)報(bào)告的內(nèi)存情況和Erlang的內(nèi)存函數(shù)報(bào)告的情況有所不同的原因是什么?
- 為何Erlang會在實(shí)際不忙時(shí)卻看起來很忙?
- 調(diào)度器調(diào)度和進(jìn)程實(shí)際工作都會消耗cpu資源，導(dǎo)致無法區(qū)分是調(diào)度工作忙還是進(jìn)程運(yùn)行忙。
- 你能找到節(jié)點(diǎn)中那些已經(jīng)準(zhǔn)備就緒但是又無法立即得到調(diào)度的進(jìn)程嗎?
進(jìn)程信息中的{status,waiting}。找出所有進(jìn)程，根據(jù)supervisor模型，然后匹配{status,waiting}即可
動手題
運(yùn)行 https://github.com/ferd/recon_demoUH中的代碼,回答如下問題
- 系統(tǒng)內(nèi)存有多少?
- recon_alloc:memory(used).
- 節(jié)點(diǎn)耗費(fèi)的CPU資源多嗎?
- recon:scheduler_usage(1000)
- 可有進(jìn)程的郵箱溢出了?
- 哪個(gè)聊天進(jìn)程(council_member)占用的內(nèi)存最多?
- recon:proc_count(memory,1).
- 哪個(gè)聊天進(jìn)程最耗 CPU?
- recon:proc_count(reductions,1).
- 哪個(gè)聊天進(jìn)程最耗帶寬?
- recon:inet_count(oct,1)
- 哪個(gè)聊天進(jìn)程發(fā)送的TCP消息最多?哪個(gè)最少?
- 你能找到節(jié)點(diǎn)中哪個(gè)進(jìn)程同時(shí)持有多個(gè)連接或者文件描述符嗎?
- 你能找到節(jié)點(diǎn)中當(dāng)前哪個(gè)函數(shù)被最多的進(jìn)程同時(shí)調(diào)用嗎?
