近日,快手宣布開源KOOM,成為行業(yè)首個(gè)開源線上內(nèi)存溢出(Out of Memory,以下簡(jiǎn)稱OOM)問題解決方案的互聯(lián)網(wǎng)企業(yè)。據(jù)介紹,KOOM是在客戶端完成內(nèi)存監(jiān)控后,將解析報(bào)告上傳到云端,傳輸文件大小僅為KB級(jí),運(yùn)行時(shí)用戶無(wú)感知,對(duì)流量基本無(wú)影響,適合大規(guī)模普及應(yīng)用,目前該方案已在快手全量業(yè)務(wù)中應(yīng)用,OOM率降低了80%以上,效果顯著。

OOM是當(dāng)前Android開發(fā)中的常見疑難問題,尤其是線上發(fā)生的OOM問題極難定位。業(yè)界當(dāng)前最知名的方案LeakCanary,通過(guò)監(jiān)控Activity/Fragment泄漏優(yōu)化Java OOM問題,多年來(lái)一直為廣大app保駕護(hù)航,解決了OOM治理從0到1的問題。但面對(duì)行業(yè)不斷復(fù)雜的業(yè)務(wù)環(huán)境和龐大用戶流量,LeakCanary仍有優(yōu)化空間:受限于性能,無(wú)法在線上大規(guī)模部署,僅支持線下使用;只能定位Activity&Fragment泄漏,無(wú)法定位大對(duì)象、頻繁分配等問題;需要人工一一分析,無(wú)法對(duì)問題聚類量化……為了徹底解決OOM問題,行業(yè)嘗試了多種解決方案,通常是基于LeakCanary做優(yōu)化,但至今沒有能完全解決監(jiān)控過(guò)程中的性能問題,普遍解決方法是通過(guò)采樣的辦法犧牲一小部分用戶的體驗(yàn)來(lái)定位問題。

快手OOM  Killer沿用行業(yè)的研究思路,針對(duì)LeakCanary無(wú)法解決的難題進(jìn)行自研改造,充分發(fā)揮LeakCanary原有優(yōu)勢(shì)的同時(shí)補(bǔ)足短板,打造了一套可以線上部署、兼顧線下、配置靈活、適用范圍廣泛、高度自動(dòng)化,埋點(diǎn)、監(jiān)控、解析、上報(bào)、分發(fā)、跟進(jìn)、報(bào)警一站式服務(wù)的閉環(huán)監(jiān)控系統(tǒng),將絕大多數(shù)OOM問題攔截在灰度階段,徹底解決了OOM問題。

KOOM框架

快手KOOM核心流程包括:配置下發(fā)決策、監(jiān)控內(nèi)存狀態(tài)、采集內(nèi)存鏡像、解析鏡像文件(以下簡(jiǎn)稱hprof)生成報(bào)告并上傳、問題聚合報(bào)警與分配跟進(jìn)。

無(wú)主動(dòng)觸發(fā)GC不卡頓

之前行業(yè)的普遍做法是通過(guò)在Activity.onDestroy()后連續(xù)觸發(fā)兩次GC,并檢查引用隊(duì)列,判定Activity是否發(fā)生了泄漏,但頻繁GC會(huì)造成用戶可感知的卡頓,快手為實(shí)現(xiàn)無(wú)感觸發(fā)設(shè)計(jì)了全新的監(jiān)控模塊,通過(guò)無(wú)性能損耗的內(nèi)存閾值監(jiān)控來(lái)觸發(fā)鏡像采集。將對(duì)象是否泄漏的判斷延遲到了解析時(shí),閾值監(jiān)控只要在子線程定期獲取關(guān)注的幾個(gè)內(nèi)存指標(biāo)即可,性能損耗忽略不計(jì)。

內(nèi)存監(jiān)控流程圖

高性能鏡像DUMP

采集內(nèi)存鏡像傳統(tǒng)方案會(huì)造成應(yīng)用完全凍結(jié)長(zhǎng)達(dá)幾秒,期間用戶完全不能操作,嚴(yán)重?fù)p害用戶體驗(yàn)?？焓掷孟到y(tǒng)內(nèi)核COW(Copy-on-write,寫時(shí)復(fù)制)機(jī)制,每次dump內(nèi)存鏡像前先暫停虛擬機(jī),然后fork子進(jìn)程來(lái)執(zhí)行dump操作,父進(jìn)程在fork成功后立刻恢復(fù)虛擬機(jī)運(yùn)行,整個(gè)過(guò)程對(duì)于父進(jìn)程來(lái)講總耗時(shí)只有幾毫秒,對(duì)用戶完全沒有影響。

暫停虛擬機(jī)需要調(diào)用虛擬機(jī)的art::Dbg::SuspendVM函數(shù),谷歌從Android 7.0開始對(duì)調(diào)用系統(tǒng)庫(kù)做了限制,快手自研了kwai-linker組件,通過(guò)caller address替換和dl_iterate_phdr解析繞過(guò)了這一限制。

Fork dump hprof流程圖

“不偷”用戶流量的解決方案

傳統(tǒng)方案得到的hprof文件通常比較大,占用用戶大量磁盤空間,上傳大文件浪費(fèi)用戶流量,且不利于問題聚類分析?？焓植捎昧诵碌乃悸?采用邊緣計(jì)算的思路,將內(nèi)存鏡像于閑時(shí)進(jìn)行獨(dú)立進(jìn)程單線程本地分析,不過(guò)多占用系統(tǒng)運(yùn)行時(shí)資源;分析完即刪除,不占用磁盤空間;分析報(bào)告大小只有KB級(jí)別,不浪費(fèi)用戶流量。

分析報(bào)告生成流程總體分為三個(gè)環(huán)節(jié),第一個(gè)環(huán)節(jié)掃描鏡像構(gòu)建索引,建立泄露查找分析的基礎(chǔ);第二個(gè)環(huán)節(jié)查找出泄露的對(duì)象,根據(jù)既有的framework知識(shí)以及人為設(shè)定的策略,執(zhí)行對(duì)象泄露判定;第三個(gè)環(huán)節(jié)生成最終報(bào)告文件,將對(duì)象泄露路徑、泄露數(shù)量、類統(tǒng)計(jì)、運(yùn)行時(shí)信息添加至報(bào)告文件,輔助后續(xù)根據(jù)報(bào)告分析解決OOM問題。

解析鏡像生成報(bào)告流程圖

針對(duì)鏡像回?fù)菩枨?對(duì)hprof進(jìn)行運(yùn)行時(shí)hook裁剪,只保留分析OOM必須的數(shù)據(jù)。裁剪還有數(shù)據(jù)脫敏的好處,只保留對(duì)分析問題有用的內(nèi)存中類與對(duì)象的組織結(jié)構(gòu),并不上傳真實(shí)的業(yè)務(wù)數(shù)據(jù),充分保護(hù)用戶隱私。

總結(jié)展望

快手KOOM計(jì)劃做完整的客戶端內(nèi)存解決方案,開發(fā)者可以通過(guò)接入KOOM,解決自己項(xiàng)目中的OOM問題。此次一期開源暫時(shí)只包括Android Java OOM解決方案,后續(xù)還將開源Android線程/文件描述符監(jiān)控、Android Native OOM監(jiān)控、iOS OOM監(jiān)控等,最終實(shí)現(xiàn)幫助開發(fā)者解決各種場(chǎng)景下OOM的愿景。

快手KOOM GitHub地址:https://github.com/KwaiAppTeam/KOOM