Erlang項(xiàng)目?jī)?nèi)存泄漏分析方法
隨著項(xiàng)目越來(lái)越依賴Erlang，碰到的問題也隨之增加。前段時(shí)間線上系統(tǒng)碰到內(nèi)存高消耗問題，記錄一下troubleshooting的分析過(guò)程。線上系統(tǒng)用的是Erlang R16B02版本。
問題描述
有幾臺(tái)線上系統(tǒng)，運(yùn)行一段時(shí)間，內(nèi)存飆升。系統(tǒng)模型很簡(jiǎn)單，有網(wǎng)絡(luò)連接，pool中找新的process進(jìn)行處理。top命令觀察，發(fā)現(xiàn)內(nèi)存都被Erlang進(jìn)程給吃完了，netstat命令查看網(wǎng)絡(luò)連接數(shù)，才區(qū)區(qū)幾K。問題應(yīng)該是Erlang內(nèi)存泄漏了。
分析方法
Erlang系統(tǒng)有個(gè)好處，可以直接進(jìn)入線上系統(tǒng)，在生產(chǎn)現(xiàn)場(chǎng)分析問題。我們系統(tǒng)是通過(guò)Rebar管理的，可以用不同方法進(jìn)入線上系統(tǒng)。
本機(jī)登錄
可以直接登錄到線上機(jī)器，然后通過(guò)以下命令attach到Erlang系統(tǒng)里面
$ cd /path/to/project
$ rel/xxx/bin/xxx attach
(node@host)>
通過(guò)remote shell
獲取Erlang系統(tǒng)的cookie
$ ps -ef |grep beam %%找到參數(shù) --setcookie
新開一個(gè)shell，使用同樣的cookie，不同的nodename
$ erl --setcookie cookiename -name test@127.0.0.1
用start remote shell進(jìn)入系統(tǒng)
Erlang R16B02 (erts-5.10.3) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false]
Eshell V5.10.3 (abort with ^G)
(test1@127.0.0.1)1> net_adm:ping('node@127.0.0.1').
pong
(test1@127.0.0.1)2> nodes().
['node@127.0.0.1']
(test1@127.0.0.1)3>
User switch command
--> h
c [nn] - connect to job
i [nn] - interrupt job
k [nn] - kill job
j - list all jobs
s [shell] - start local shell
r [node [shell]] - start remote shell
q - quit erlang
? | h - this message
--> r 'node@127.0.0.1'
--> j
1 {shell,start,[init]}
2* {'node@127.0.0.1',shell,start,[]}
--> c 2
分析流程
Erlang有很多工具，可以分析系統(tǒng)信息，比如appmon，webtool。但是系統(tǒng)內(nèi)存嚴(yán)重不足，已經(jīng)沒有辦法啟動(dòng)這些工具了，幸好還有Erlang shell。
Erlang shell自帶了很多有用的命令，可以用help()方法查看
> help().
Erlang系統(tǒng)內(nèi)存消耗情況
top結(jié)果顯示，是內(nèi)存問題，所以第一步可以先看看Erlang的系統(tǒng)內(nèi)存消耗情況
> erlang:memory().
memory()可以看到Erlang emulator分配的內(nèi)存，有總的內(nèi)存，atom消耗的內(nèi)存，process消耗的內(nèi)存等等。
Erlang process創(chuàng)建數(shù)量
線上系統(tǒng)發(fā)現(xiàn)主要內(nèi)存消耗都在process上面，接下來(lái)要分析，是process內(nèi)存泄漏了，還是process創(chuàng)建數(shù)量太多導(dǎo)致。
> erlang:system_info(process_limit). %%查看系統(tǒng)最多能創(chuàng)建多少process
> erlang:system_info(process_count). %%當(dāng)前系統(tǒng)創(chuàng)建了多少process
system_info()返回當(dāng)前系統(tǒng)的一些信息，比如系統(tǒng)process，port的數(shù)量。執(zhí)行上面命令，大吃一驚，只有2，3k的網(wǎng)絡(luò)連接，結(jié)果Erlang process已經(jīng)有10多w了。系統(tǒng)process創(chuàng)建了，但是因?yàn)榇a或者其它原因，堆積沒有釋放。
查看單個(gè)process的信息
既然是因?yàn)閜rocess因?yàn)槟撤N原因堆積了，只能從process里找原因了
先要獲取堆積process的pid
> i(). %%返回system信息
> i(0,61,886). %% (0,61,886)是pid
看到有很多process hang在那里，查看具體pid信息，發(fā)現(xiàn)message_queue有幾條消息沒有被處理。下面就用到強(qiáng)大的erlang:process_info()方法，它可以獲取進(jìn)程相當(dāng)豐富的信息。
> erlang:process_info(pid(0,61,886), current_stacktrace).
> rp(erlang:process_info(pid(0,61,886), backtrace)).
查看進(jìn)程的backtrace時(shí)，發(fā)現(xiàn)下面的信息
0x00007fbd6f18dbf8 Return addr 0x00007fbff201aa00 (gen_event:rpc/2 + 96)
y(0) #Ref<0.0.2014.142287>
y(1) infinity
y(2) {sync_notify,{log,{lager_msg,[], ..........}}
y(3) <0.61.886>
y(4) <0.89.0>
y(5) []
process在處理Erlang第三方的日志庫(kù)lager時(shí)，hang住了。
問題原因
查看lager的文檔，發(fā)現(xiàn)以下信息
Prior to lager 2.0, the gen_event at the core of lager operated purely in synchronous mode. Asynchronous mode is faster, but has no protection against message queue overload. In lager 2.0, the gen_event takes a hybrid approach. it polls its own mailbox size and toggles the messaging between synchronous and asynchronous depending on mailbox size.
{async_threshold, 20}, {async_threshold_window, 5}
This will use async messaging until the mailbox exceeds 20 messages, at which point synchronous messaging will be used, and switch back to asynchronous, when size reduces to 20 - 5 = 15.
If you wish to disable this behaviour, simply set it to 'undefined'. It defaults to a low number to prevent the mailbox growing rapidly beyond the limit and causing problems. In general, lager should process messages as fast as they come in, so getting 20 behind should be relatively exceptional anyway.
原來(lái)lager有個(gè)配置項(xiàng)，配置message未處理的數(shù)量，如果message堆積數(shù)超出，則會(huì)用 同步 方式處理！
當(dāng)前系統(tǒng)打開了debug log，洪水般的log把系統(tǒng)給沖垮了。
老外也碰到類似問題，這個(gè)thread給我們的分析帶來(lái)很多幫助，感謝一下。
總結(jié)
Erlang提供了豐富的工具，可以在線進(jìn)入系統(tǒng)，現(xiàn)場(chǎng)分析問題，這個(gè)非常有助于高效、快速的定位問題。同時(shí)，強(qiáng)大的Erlang OTP讓系統(tǒng)有更穩(wěn)定的保證。我們還會(huì)繼續(xù)挖掘Erlang，期待有更多的實(shí)踐分享。
相關(guān)文章
這篇文章主要介紹了Erlang中的映射組Map詳細(xì)介紹,本文講解了創(chuàng)建映射組、更新映射組、兩種操作符的區(qū)別、映射的增加、刪除、獲取等內(nèi)容,需要的朋友可以參考下2015-02-02
當(dāng)單臺(tái) RabbitMQ 服務(wù)器的處理消息的能力達(dá)到瓶頸時(shí)，此時(shí)可以通過(guò) RabbitMQ 集群來(lái)進(jìn)行擴(kuò)展，從而達(dá)到提升吞吐量的目的2021-08-08
RabbitMQ是實(shí)現(xiàn)了高級(jí)消息隊(duì)列協(xié)議（AMQP）的開源消息代理軟件（亦稱面向消息的中間件）。RabbitMQ服務(wù)器是用Erlang語(yǔ)言編寫的，所有主要的編程語(yǔ)言均有與代理接口通訊的客戶端庫(kù)2021-06-06
這篇文章主要介紹了Erlang中遍歷取出某個(gè)位置的最大值代碼,本文直接給出實(shí)現(xiàn)代碼,需要的朋友可以參考下2015-03-03
這篇文章主要介紹了Erlang中的匹配模式總結(jié),本文講解了賦值時(shí)匹配、流程控制中的匹配、消息傳遞匹配等內(nèi)容,需要的朋友可以參考下2015-01-01
這篇文章主要介紹了Erlang中的基本元素操作小結(jié),本文講解了元組(tuple)、記錄(record)、列表(list)、映射組(map)等內(nèi)容,需要的朋友可以參考下2015-03-03
Erlang中執(zhí)行l(wèi)inux命令的兩種方法
這篇文章主要介紹了Erlang中執(zhí)行l(wèi)inux命令的兩種方法,本文著重講解了erlang:open_port的使用,需要的朋友可以參考下2015-01-01
這篇文章主要介紹了Erlang中的函數(shù)與流程控制介紹,本文先是講解了函數(shù)的一些知識(shí),然后講解了case語(yǔ)句和if語(yǔ)句及算術(shù)表達(dá)式等內(nèi)容,需要的朋友可以參考下2015-01-01
這篇文章主要介紹了Erlang IO編程之文件目錄操作常用方法小結(jié),本文講解了常用的文件操作如打開文件、讀取文件、寫入文件、刪除文件等,需要的朋友可以參考下2015-01-01
Erlang項(xiàng)目?jī)?nèi)存泄漏分析方法
這篇文章主要介紹了Erlang項(xiàng)目?jī)?nèi)存泄漏分析方法,本文講解了分析方法、分析流程并找到問題原因和解決方法,需要的朋友可以參考下2015-02-02