優(yōu)化您的 Go 應(yīng)用程序

1. 如果您的應(yīng)用程序在 Kubernetes 中運(yùn)行，請(qǐng)自動(dòng)設(shè)置 GOMAXPROCS 以匹配 Linux 容器的 CPU 配額

Go 調(diào)度器 可以具有與運(yùn)行設(shè)備的核心數(shù)量一樣多的線程。由于我們的應(yīng)用程序在 Kubernetes 環(huán)境中的節(jié)點(diǎn)上運(yùn)行，當(dāng)我們的 Go 應(yīng)用程序開(kāi)始運(yùn)行時(shí)，它可以擁有與節(jié)點(diǎn)中的核心數(shù)量一樣多的線程。由于許多不同的應(yīng)用程序在這些節(jié)點(diǎn)上運(yùn)行，因此這些節(jié)點(diǎn)可能包含相當(dāng)多的核心。

通過(guò)使用 https://github.com/uber-go/automaxprocs，Go 調(diào)度器使用的線程數(shù)量將與您在 k8s yaml 中定義的 CPU 限制一樣多。

示例：

應(yīng)用程序 CPU 限制(在 k8s.yaml 中定義)：1 核心 節(jié)點(diǎn)核心數(shù)量：64

通常情況下，Go 調(diào)度器會(huì)嘗試使用 64 個(gè)線程，但如果我們使用 automaxprocs，它將僅使用一個(gè)線程。

我觀察到在我實(shí)施這個(gè)方法的應(yīng)用程序中有相當(dāng)大的性能提升。約 60% 的 CPU 使用率，約 30% 的內(nèi)存使用率和約 30% 的響應(yīng)時(shí)間。

2. 對(duì)結(jié)構(gòu)體字段進(jìn)行排序

結(jié)構(gòu)體中字段的順序直接影響您的內(nèi)存使用情況。

例如：

type testStruct struct {
 testBool1  bool    // 1 byte
 testFloat1 float64 // 8 bytes
 testBool2  bool    // 1 byte
 testFloat2 float64 // 8 bytes
}

您可能會(huì)認(rèn)為這個(gè)結(jié)構(gòu)體將占用 18 字節(jié)，但實(shí)際上不會(huì)。

func main() {
 a := testStruct{}
 fmt.Println(unsafe.Sizeof(a)) // 32 bytes
}

這是因?yàn)樵?64 位架構(gòu)中內(nèi)部?jī)?nèi)存對(duì)齊的工作方式。

many boxes showing 8 bytes of testbool1, testFIoat1, testbool2, testFIoat2

我們?nèi)绾谓档蛢?nèi)存使用?我們可以根據(jù)內(nèi)存填充來(lái)對(duì)字段進(jìn)行排序。

type testStruct struct {
 testFloat1 float64 // 8 bytes
 testFloat2 float64 // 8 bytes
 testBool1  bool    // 1 byte
 testBool2  bool    // 1 byte
}

func main() {
 a := testStruct{}
 fmt.Println(unsafe.Sizeof(a)) // 24 bytes
}

我們并不總是需要手動(dòng)排序這些字段。您可以使用諸如 fieldalignment 等工具來(lái)自動(dòng)對(duì)結(jié)構(gòu)體進(jìn)行排序。

fieldalignment -fix ./... 

3. 垃圾回收調(diào)優(yōu)

在 Go 1.19 之前，我們只能使用 GOGC(runtime/debug.SetGCPercent) 來(lái)配置垃圾回收周期;然而，在某些情況下，我們可能會(huì)超出內(nèi)存限制。隨著 Go 1.19 的到來(lái)，我們現(xiàn)在擁有了 GOMEMLIMIT。GOMEMLIMIT 是一個(gè)新的環(huán)境變量，允許用戶限制 Go 進(jìn)程可以使用的內(nèi)存量。這個(gè)功能提供了更好的控制 Go 應(yīng)用程序內(nèi)存使用的方式，防止它們使用過(guò)多的內(nèi)存導(dǎo)致性能問(wèn)題或崩潰。通過(guò)設(shè)置 GOMEMLIMIT 變量，用戶可以確保其 Go 程序在系統(tǒng)上平穩(wěn)高效地運(yùn)行，而不會(huì)對(duì)系統(tǒng)造成不必要的壓力。

它并不替代 GOGC，而是與之配合使用。您還可以禁用 GOGC 百分比配置，只使用 GOMEMLIMIT 來(lái)觸發(fā)垃圾回收。

GOGC 設(shè)為 100 和內(nèi)存限制為 100MB

GOGC 設(shè)為關(guān)閉(off)并且內(nèi)存限制為 100

在減少垃圾回收的運(yùn)行量方面有明顯的效果，但在應(yīng)用此設(shè)置時(shí)需要小心。如果您不了解應(yīng)用程序的極限，請(qǐng)不要將 GOGC=off。

4. 使用 unsafe 包進(jìn)行字符串 <-> 字節(jié)轉(zhuǎn)換而不進(jìn)行復(fù)制

在字符串與字節(jié)之間進(jìn)行轉(zhuǎn)換時(shí)，我們通常會(huì)進(jìn)行變量的復(fù)制。但在 Go 內(nèi)部，這兩種類型通常使用 StringHeader 和 SliceHeader 值。我們可以在這兩種類型之間進(jìn)行轉(zhuǎn)換，而不進(jìn)行額外的分配。

// For Go 1.20 and higher
func StringToBytes(s string) []byte {
 return unsafe.Slice(unsafe.StringData(s), len(s))
}

func BytesToString(b []byte) string {
 return unsafe.String(unsafe.SliceData(b), len(b))
}

// For lower versions
// Check the example here
// https://github.com/bcmills/unsafeslice/blob/master/unsafeslice.go#L116

諸如 fasthttp 和 fiber 等庫(kù)也在其內(nèi)部使用這種結(jié)構(gòu)。

注意： 如果您的字節(jié)或字符串值可能會(huì)在后續(xù)發(fā)生更改，請(qǐng)不要使用此特性。

5. 使用 jsoniter 替代 encoding/json

我們通常在代碼中使用 Marshal 和 Unmarshal 方法來(lái)進(jìn)行序列化或反序列化。

Jsoniter 是 encoding/json 的 100% 兼容的替代品。

以下是一些性能基準(zhǔn)：

將其替換為 encoding/json 非常簡(jiǎn)單：

import "encoding/json"

json.Marshal(&data)
json.Unmarshal(input, &data)
import jsoniter "github.com/json-iterator/go"

var json = jsoniter.ConfigCompatibleWithStandardLibrary
json.Marshal(&data)
json.Unmarshal(input, &data)

6. 使用 sync.Pool 來(lái)減少堆分配

對(duì)象池背后的主要概念是避免重復(fù)創(chuàng)建和銷毀對(duì)象的開(kāi)銷，這可能會(huì)對(duì)性能產(chǎn)生負(fù)面影響。

緩存先前分配但未使用的項(xiàng)目有助于減輕垃圾回收器的負(fù)擔(dān)，并允許稍后重新使用它們。

以下是一個(gè)示例：

type Person struct {
 Name string
}

var pool = sync.Pool{
 New: func() any {
  fmt.Println("Creating a new instance")
  return &Person{}
 },
}

func main() {
 person := pool.Get().(*Person)
 fmt.Println("Get object from sync.Pool for the first time:", person)
 person.Name = "Mehmet"

 fmt.Println("Put the object back in the pool")
 pool.Put(person)

 fmt.Println("Get object from pool again:", pool.Get().(*Person))

 fmt.Println("Get object from pool again (new one will be created):", pool.Get().(*Person))
}

//Creating a new instance
//Get object from sync.Pool for the first time: &{}
//Put the object back in the pool
//Get object from pool again: &{Mehmet}
//Creating a new instance
//Get object from pool again (new one will be created): &{}

通過(guò)使用 sync.Pool，我解決了 New Relic Go Agent 中的內(nèi)存泄漏問(wèn)題。以前，它為每個(gè)請(qǐng)求創(chuàng)建一個(gè)新的 gzip writer。我創(chuàng)建了一個(gè)池，以便代理程序可以使用該池中的 writer，而不是為每個(gè)請(qǐng)求創(chuàng)建新的 gzip writer 實(shí)例，從而大大減少了堆使用，并因此減少了系統(tǒng)的垃圾回收次數(shù)。這個(gè)改進(jìn)大約將我們應(yīng)用程序的 CPU 使用率降低了約 40%，內(nèi)存使用率降低了約 22%。