免费很黄很色裸乳在线观看,日韩高清在线日韩大片观看网址,乌克兰黄色录像

記錄一次線上服務OOM（內(nèi)存溢出）排查

freeflydom

2025年1月10日 8:56 本文熱度 747

OOM

OOM是"Out of Memory"的縮寫，意為內(nèi)存不足或內(nèi)存溢出。在計算機科學中，當一個程序嘗試使用比系統(tǒng)可用內(nèi)存更多的內(nèi)存時，就會發(fā)生OOM錯誤。這種情況通常發(fā)生在程序試圖分配內(nèi)存空間，但操作系統(tǒng)無法滿足請求，因為它已經(jīng)沒有足夠的空閑內(nèi)存來提供給該程序。

老實說，在我印象里OOM問題只存在于網(wǎng)上案例中，練習編碼時常兩年半，還是第一次遇到。不過既然遇到了，那就要盡快排查問題并解決掉，不然真要和群里大哥說的一樣：要領盒飯了。

問題

下午兩點新版本上線，其中一個消費者服務的內(nèi)存增長速度異常迅速，在短短五分鐘內(nèi)就用完了2G內(nèi)存并自動重啟了pod，之后又在五分鐘內(nèi)OOM了，在四十分鐘內(nèi)服務的pod已經(jīng)重啟了八十幾次，要知道我們之前這個消費者服務正常運行時候只用了不到500M。

分析

首先進行初步分析，這是一個消費者服務并且新版本的需求中并沒有新增消費topic，并且業(yè)務量也沒有大的波動，不存在是業(yè)務訪問量驟增導致OOM，所以極大概率會是代碼問題。當然，每一個版本的新代碼都非常多，需求也比較龐雜，直接去看代碼肯定是不行的，這時候就要麻煩部門的運維大佬了，讓他給我們dump一下，給出一個內(nèi)存溢出時的性能記錄文件，通過這個文件可以分析內(nèi)存分配、線程創(chuàng)建、CPU使用、阻塞、程序詳細跟蹤信息等。

我這里使用的Go語言開發(fā)，一般用pprof文件進行分析，運維給出的文件有以下6個：

main-1-trace-1227152939.pprof：記錄程序執(zhí)行的詳細跟蹤信息，包括函數(shù)調(diào)用、Goroutine 的創(chuàng)建和調(diào)度等
main-1-threadcreate-1227152939.pprof：記錄線程創(chuàng)建的剖析數(shù)據(jù)，幫助分析線程創(chuàng)建的頻率和開銷。
main-1-mutex-1227152939.pprof：記錄互斥鎖（mutex）的使用情況，幫助分析鎖競爭和鎖等待的開銷。
main-1-mem-1227152939.pprof：記錄內(nèi)存分配的剖析數(shù)據(jù)，幫助分析內(nèi)存使用的熱點和分配情況。
main-1-cpu-1227152939.pprof：記錄 CPU 使用的剖析數(shù)據(jù)，幫助分析 CPU 時間的消耗情況。
main-1-block-1227152939.pprof：記錄阻塞操作的剖析數(shù)據(jù)，幫助分析阻塞操作的頻率和開銷。

內(nèi)存OOM，那最重要的當然是mem文件，也就是內(nèi)存分配剖析數(shù)據(jù)，不過很不幸，服務重啟速度太快了，運維大佬dump的時候正好處于服務剛重啟的時候，所以mem文件中顯示的內(nèi)存才占用不到20M，并且占比上也沒看出有什么問題。想讓運維再幫忙dump一下內(nèi)存快要OOM的時候，但是為了線上服務的穩(wěn)定性版本已經(jīng)回退了，無法重新dump，只能從其他幾個文件中查找問題了。

除了內(nèi)存占用分析，在性能問題分析中CPU占用分析也是極為重要的一環(huán)，這一查看就有意思了，CPU總的使用率雖然不高，但是這個占比就比較奇怪了。第一占比的runtime.step是Go的運行時系統(tǒng)負責管理內(nèi)存分配、垃圾回收、調(diào)度goroutine等底層操作，這個暫且不管，占比第二的居然是runtime.selectgo，這個就非常詭異了，select一般用于channel的非阻塞調(diào)用，但是問題是新增代碼中沒有地方顯示地調(diào)用了select，那可以初步判斷是底層源碼中某處一直在調(diào)用select函數(shù)，不過目前還不知道是誰觸發(fā)的這個調(diào)用，還需要繼續(xù)查看其他文件。

之后繼續(xù)查看互斥鎖的情況，其實這個文件在目前這種情況下排查的價值已經(jīng)不大了，因為出現(xiàn)問題的是內(nèi)存溢出而不是CPU占用率，并且CPU占用率確實不是很高，而且Go中是有檢索死鎖的機制，大部分死鎖是能夠被Go發(fā)現(xiàn)并報一個deadlock錯誤，打開文件之后發(fā)現(xiàn)果然沒有死鎖發(fā)生。

接下來查看阻塞操作的分析情況，從解析結(jié)果中可以看出，select的阻塞時間遙遙領先，select出現(xiàn)這種情況只會是存在case但是沒有default的時候，當所有case不符合的時候，負責這個select的goroutine會阻塞住直到存在符合的case出現(xiàn)才會喚醒繼續(xù)走下去，當時我看到這我滿腦子問號，誰家好人select不加default??？

再查看線程創(chuàng)建情況，由于pod剛啟動不久，所以這個文件也看不出什么東西，很正常的線程創(chuàng)建。

看到這里還是沒能定位到問題所在，但是別急，我們還有最重要的文件還沒看，那就是trace文件，它可以記錄程序執(zhí)行的詳細跟蹤信息，包括函數(shù)調(diào)用、Goroutine 的創(chuàng)建和調(diào)度，使用go自帶的pprof分析工具打開trace文件

go tool trace main-1-trace-1227102939.pprof

會出現(xiàn)以下本地頁面：

在Goroutine分析中，可以鎖定真正的問題所在了，在go-zero的core包下的collection文件在不到一秒內(nèi)創(chuàng)建了兩萬多的Goroutine，雖然兩萬多數(shù)量不多，但是這個速度十分異常，最重要的是這個定時輪就很奇怪，這個項目中根本沒有定時任務，接下來就很容易查詢了，只要查找這次提交的代碼中哪里使用到了collection包。

經(jīng)過一番全局搜索后，最終確定了問題代碼：

func NewXXXLogic(svcCtx *svc.ServiceContext, ctx context.Context) *XXXLogic {
    cache, _ := collection.NewCache(30 * time.Second)
    return &XXXLogic{
       Logger:     logx.WithContext(ctx),
       svcCtx:     svcCtx,
       ctx:        ctx,
       localCache: cache,
    }
}

在新上線的版本中只有這一處用到了collection包，原本這里的意思是將建立一個緩存放到上下文中去傳遞，但是乍一看我沒有看出有什么問題，過期時間也設置了，按照我原有理解過期時間到了就會自動釋放掉，為什么還是會內(nèi)存溢出了？但是我忽然意識到應該不是緩存引發(fā)的內(nèi)存溢出，可能是協(xié)程過多引發(fā)的內(nèi)存溢出，因為一個初始協(xié)程是2KB左右，如果數(shù)量過多也會造成內(nèi)存不夠。

為了探究根本原因，我點進了collection包的源碼進行查看，在其中NewCache()方法中找到了造成協(xié)程數(shù)異常增加的定時輪創(chuàng)建方法NewTimingWheel()。

之后點進去這個方法進一步查看，可以看到這個定時輪的結(jié)構(gòu)體，里面包含了四個channel以及一些其他數(shù)據(jù)結(jié)構(gòu)，粗略估計這一個TimingWheel結(jié)構(gòu)體所占內(nèi)存要達到一百字節(jié)以上，這是一個比較龐大的對象，如果無限制的創(chuàng)建下去很容易造成內(nèi)存OOM發(fā)生。

但是這個定時輪為什么會創(chuàng)建那么多呢？為什么不會關閉，按理說go-zero的源碼不應該會有這么大的漏洞，繼續(xù)查看這個定時輪的run()方法，終于發(fā)現(xiàn)了問題所在，這個定時輪中開啟了select方法，并且沒有default方法，所以之前阻塞文件那里才會顯示select阻塞時間占比達到了99%，并且唯一關閉這個定時輪的方法是接收到tw.ticker.Stop()才會停止，那么這個stop方法會在什么時候調(diào)用呢？

答案是會在程序停止運行的時候進行調(diào)用。所以如果程序仍在運行，就會有無限制的協(xié)程創(chuàng)建定時輪，這時候定時輪因為無法關閉所以協(xié)程也不會進行銷毀，有點類似于守護線程，所以在協(xié)程無限制的創(chuàng)建下最終導致了線上內(nèi)存OOM了。