如何解決定位并修復(fù)Go 中的內(nèi)存泄露問題

這篇文章將為大家詳細(xì)講解有關(guān)如何解決定位并修復(fù)Go 中的內(nèi)存泄露問題，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

Google Cloud Go 客戶端庫(kù) [1] 通常在后臺(tái)使用 gRPC 來(lái)連接 Google Cloud API。創(chuàng)建 API 客戶端時(shí)，庫(kù)會(huì)初始化與 API 的連接，然后保持該連接處于打開狀態(tài)，直到你調(diào)用 Client.Close 。

client, err := api.NewClient()
// Check err.
defer client.Close()

客戶端可以安全地同時(shí)使用，所以你應(yīng)該保持相同 Client 直到你的任務(wù)完成。但是，如果在應(yīng)該 Close 的時(shí)候不 Close client 會(huì)發(fā)生什么呢？

會(huì)出現(xiàn)內(nèi)存泄漏。底層連接永遠(yuǎn)不會(huì)被清理。

Google 有一堆 GitHub 自動(dòng)化機(jī)器人來(lái)幫助管理數(shù)百個(gè) GitHub 存儲(chǔ)庫(kù)。我們的一些機(jī)器人通過在 Cloud Run [2] 上運(yùn)行的 Go 服務(wù)器 [3] 代理它們的請(qǐng)求。我們的內(nèi)存使用看起來(lái)像一個(gè)經(jīng)典的鋸齒形內(nèi)存泄漏：

我通過向服務(wù)器添加 pprof.Index 處理程序開始調(diào)試：

mux.HandleFunc("/debug/pprof/", pprof.Index)

`pprof` [4] 提供運(yùn)行時(shí) profiling 數(shù)據(jù)，如內(nèi)存使用情況。有關(guān)更多信息，請(qǐng)參閱 Go 官方博客上的 profiling Go 程序 [5] 。

然后，我在本地構(gòu)建并啟動(dòng)了服務(wù)器：

$ go build
$ PROJECT_ID=my-project PORT=8080 ./serverless-scheduler-proxy

然后向服務(wù)器發(fā)送一些請(qǐng)求：

for i in {1..5}; do
  curl --header "Content-Type: application/json" --request POST --data '{"name": "HelloHTTP", "type": "testing", "location": "us-central1"}' localhost:8080/v0/cron
  echo " -- $i"
done

確切的有效負(fù)載和端點(diǎn)特定于我們的服務(wù)器，與本文無(wú)關(guān)。

為了獲得正在使用的內(nèi)存的基線，我收集了一些初始 pprof 數(shù)據(jù)：

curl http://localhost:8080/debug/pprof/heap > heap.0.pprof

檢查輸出，你可以看到一些內(nèi)存使用情況，但沒有什么會(huì)立即成為一個(gè)大問題（這很好！我們剛剛啟動(dòng)了服務(wù)器?。?/p>

$ go tool pprof heap.0.pprof
File: serverless-scheduler-proxy
Type: inuse_space
Time: May 4, 2021 at 9:33am (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 2129.67kB, 100% of 2129.67kB total
Showing top 10 nodes out of 30
      flat  flat%   sum%        cum   cum%
 1089.33kB 51.15% 51.15%  1089.33kB 51.15%  google.golang.org/grpc/internal/transport.newBufWriter (inline)
  528.17kB 24.80% 75.95%   528.17kB 24.80%  bufio.NewReaderSize (inline)
  512.17kB 24.05%   100%   512.17kB 24.05%  google.golang.org/grpc/metadata.Join
         0     0%   100%   512.17kB 24.05%  cloud.google.com/go/secretmanager/apiv1.(*Client).AccessSecretVersion
         0     0%   100%   512.17kB 24.05%  cloud.google.com/go/secretmanager/apiv1.(*Client).AccessSecretVersion.func1
         0     0%   100%   512.17kB 24.05%  github.com/googleapis/gax-go/v2.Invoke
         0     0%   100%   512.17kB 24.05%  github.com/googleapis/gax-go/v2.invoke
         0     0%   100%   512.17kB 24.05%  google.golang.org/genproto/googleapis/cloud/secretmanager/v1.(*secretManagerServiceClient).AccessSecretVersion
         0     0%   100%   512.17kB 24.05%  google.golang.org/grpc.(*ClientConn).Invoke
         0     0%   100%  1617.50kB 75.95%  google.golang.org/grpc.(*addrConn).createTransport

下一步是向服務(wù)器發(fā)送一堆請(qǐng)求，看看我們是否可以 (1) 重現(xiàn)可能的內(nèi)存泄漏和 (2) 確定泄漏是什么。

發(fā)送 500 個(gè)請(qǐng)求：

for i in {1..500}; do
  curl --header "Content-Type: application/json" --request POST --data '{"name": "HelloHTTP", "type": "testing", "location": "us-central1"}' localhost:8080/v0/cron
  echo " -- $i"
done

收集和分析更多 pprof 數(shù)據(jù)：

$ curl http://localhost:8080/debug/pprof/heap > heap.6.pprof
$ go tool pprof heap.6.pprof
File: serverless-scheduler-proxy
Type: inuse_space
Time: May 4, 2021 at 9:50am (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 94.74MB, 94.49% of 100.26MB total
Dropped 26 nodes (cum <= 0.50MB)
Showing top 10 nodes out of 101
      flat  flat%   sum%        cum   cum%
   51.59MB 51.46% 51.46%    51.59MB 51.46%  google.golang.org/grpc/internal/transport.newBufWriter
   19.60MB 19.55% 71.01%    19.60MB 19.55%  bufio.NewReaderSize
    6.02MB  6.01% 77.02%     6.02MB  6.01%  bytes.makeSlice
    4.51MB  4.50% 81.52%    10.53MB 10.51%  crypto/tls.(*Conn).readHandshake
       4MB  3.99% 85.51%     4.50MB  4.49%  crypto/x509.parseCertificate
       3MB  2.99% 88.51%        3MB  2.99%  crypto/tls.Client
    2.50MB  2.49% 91.00%     2.50MB  2.49%  golang.org/x/net/http2/hpack.(*headerFieldTable).addEntry
    1.50MB  1.50% 92.50%     1.50MB  1.50%  google.golang.org/grpc/internal/grpcsync.NewEvent
       1MB     1% 93.50%        1MB     1%  runtime.malg
       1MB     1% 94.49%        1MB     1%  encoding/json.(*decodeState).literalStore

google.golang.org/grpc/internal/transport.newBufWriter 使用大量?jī)?nèi)存真的很突出！這是泄漏與什么相關(guān)的第一個(gè)跡象：gRPC。查看我們的應(yīng)用程序源代碼，我們唯一使用 gRPC 的地方是 Google Cloud Secret Manager [6] ：

client, err := secretmanager.NewClient(ctx) 
if err != nil { 
    return nil, fmt.Errorf("failed to create secretmanager client: %v", err) 
}

在每個(gè)請(qǐng)求創(chuàng)建 client 時(shí)，我們沒有調(diào)用 client.Close() ！所以，我添加了一個(gè) Close 調(diào)用，問題就消失了：

defer client.Close()

我提交了修復(fù)，然后 自動(dòng)部署 [7] ，鋸齒立即消失了！

大約在同一時(shí)間，用戶在我們的 Cloud 的 Go 示例存儲(chǔ)庫(kù)中 [8] 提交了一個(gè)問題，其中包含 cloud.google.com 上 [9] 文檔的大部分 Go 示例。用戶注意到我們忘記調(diào)用 client.Close 了。

我曾多次看到同樣的事情出現(xiàn)，所以我決定調(diào)查整個(gè) repo。

我開始粗略估計(jì)有多少受影響的文件。使用 grep ，我們可以獲得包含 NewClient 樣式調(diào)用的所有文件的列表，然后將該列表傳遞給另一個(gè)調(diào)用 grep 以僅列出不包含 Close 的文件，同時(shí)忽略測(cè)試文件：

$ grep -L Close $(grep -El 'New[^(]*Client' **/*.go) | grep -v test

竟然有 207 個(gè)文件……就上下文而言，我們 .go 在 GoogleCloudPlatform/golang-samples [10] 存儲(chǔ)庫(kù)中有大約 1300 個(gè)文件。

考慮到問題的規(guī)模，我認(rèn)為一些自動(dòng)化是 值得的 [11] 。我不想寫一個(gè)完整的 Go 程序來(lái)編輯文件，所以我使用 Bash：

$ grep -L Close $(grep -El 'New[^(]*Client' **/*.go) | grep -v test | xargs sed -i '/New[^(]*Client/,/}/s/}/}\ndefer client.Close()/'

它是完美的嗎？不。它對(duì)工作量有很大的影響嗎？是的！

第一部分（直到 test ）與上面完全相同——獲取所有可能受影響的文件的列表（那些似乎創(chuàng)建了 Client 但從沒調(diào)用 Close 的文件）。

然后，我將該文件列表傳遞給 sed 進(jìn)行實(shí)際編輯。 xargs 調(diào)用你給它的命令，每一行都以 stdin 作為參數(shù)傳遞給給定的命令。

要理解該 sed 命令，查看 golang-samples repo 示例是什么樣子有助于理解（省略導(dǎo)入和客戶端初始化后的所有內(nèi)容）：

// accessSecretVersion accesses the payload for the given secret version if one
// exists. The version can be a version number as a string (e.g. "5") or an
// alias (e.g. "latest").
func accessSecretVersion(w io.Writer, name string) error {
    // name := "projects/my-project/secrets/my-secret/versions/5"
    // name := "projects/my-project/secrets/my-secret/versions/latest"
    // Create the client.
    ctx := context.Background()
    client, err := secretmanager.NewClient(ctx)
    if err != nil {
        return fmt.Errorf("failed to create secretmanager client: %v", err)
    }
    // ...
}

在高層次上，我們初始化客戶端并檢查是否有錯(cuò)誤。每當(dāng)你檢查錯(cuò)誤時(shí)，都會(huì)有一個(gè)右花括號(hào) ( } )。我使用這些信息來(lái)自動(dòng)化編輯。

但是，該 sed 命令仍然很笨拙：

sed -i '/New[^(]*Client/,/}/s/}/}\ndefer client.Close()/'

-i 表示直接編輯文件。這不是問題，因?yàn)榇a用 git 管理了。

接下來(lái)，我使用 s 命令在檢查錯(cuò)誤 defer client.Close() 后假定的右花括號(hào) ( } )之后插入。

但是，我不想替換每個(gè) } ，我只想要在 調(diào)用 NewClient 后 的 第一個(gè) 。要做到這一點(diǎn)，你可以給一個(gè) 地址范圍 [12] 的 sed 搜索。

地址范圍可以包括在應(yīng)用接下來(lái)的任何命令之前要匹配的開始和結(jié)束模式。在這種情況下，開始是 /New[^(]*Client/ ，匹配 NewClient 類型調(diào)用，結(jié)束（由 a 分隔 , ）是 /}/ ，匹配下一個(gè)大括號(hào)。這意味著我們的搜索和替換僅適用于調(diào)用 NewClient 和結(jié)束大括號(hào)之間！

通過了解上面的錯(cuò)誤處理模式， if err != nil 條件的右大括號(hào)正是我們想要插入 Close 調(diào)用的位置。

一旦我自動(dòng)編輯了所有示例文件，我用 goimports 開始修復(fù)格式。然后，我檢查了每個(gè)編輯過的文件，以確保它做了正確的事情：

• 在服務(wù)器應(yīng)用程序中，我們應(yīng)該關(guān)閉客戶端，還是應(yīng)該保留它以備將來(lái)的請(qǐng)求使用？

• 是 Client 實(shí)際的名字 client 還是別的什么？

• 是否有一個(gè)以上的 Client 調(diào)用了 Close ？
  

完成后，只剩下 180 個(gè)已編輯的文件 [13] 。

最后一項(xiàng)工作是努力使其不再發(fā)生在用戶身上。我們想到了幾種方法：

1. 更好的示例代碼；

2. 更好的 GoDoc。我們更新了庫(kù)生成器，在生成庫(kù)時(shí)加上注釋，告知 client 需要調(diào)用 Close；

3. 更好的庫(kù)。有沒有辦法可以自動(dòng) Close 客戶端？Finalizers？知道何能做得更好嗎？歡迎在 https://github.com/googleapis/google-cloud-go/issues/4498 上交流；

關(guān)于“如何解決定位并修復(fù)Go 中的內(nèi)存泄露問題”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。