Go 调度器 可以具有与运行设备的核心数量一样多的线程。由于我们的应用程序在 Kubernetes 环境中的节点上运行，当我们的 Go 应用程序开始运行时，它可以拥有与节点中的核心数量一样多的线程。由于许多不同的应用程序在这些节点上运行，因此这些节点可能包含相当多的核心。
通过使用 https://github.com/uber-go/automaxprocs，Go 调度器使用的线程数量将与您在 k8s yaml 中定义的 CPU 限制一样多。
示例：
应用程序 CPU 限制(在 k8s.yaml 中定义)：1 核心 节点核心数量：64
通常情况下，Go 调度器会尝试使用 64 个线程，但如果我们使用 automaxprocs，它将仅使用一个线程。
我观察到在我实施这个方法的应用程序中有相当大的性能提升。约 60% 的 CPU 使用率，约 30% 的内存使用率和约 30% 的响应时间。
结构体中字段的顺序直接影响您的内存使用情况。
例如：
type testStruct struct { testBool1 bool // 1 byte testFloat1 float64 // 8 bytes testBool2 bool // 1 byte testFloat2 float64 // 8 bytes}您可能会认为这个结构体将占用 18 字节，但实际上不会。
func main() { a := testStruct{} fmt.Println(unsafe.Sizeof(a)) // 32 bytes}这是因为在 64 位架构中内部内存对齐的工作方式。
many boxes showing 8 bytes of testbool1, testFIoat1, testbool2, testFIoat2
我们如何降低内存使用?我们可以根据内存填充来对字段进行排序。
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}
我们并不总是需要手动排序这些字段。您可以使用诸如 fieldalignment 等工具来自动对结构体进行排序。
fieldalignment -fix ./... 在 Go 1.19 之前，我们只能使用 GOGC(runtime/debug.SetGCPercent) 来配置垃圾回收周期;然而，在某些情况下，我们可能会超出内存限制。随着 Go 1.19 的到来，我们现在拥有了 GOMEMLIMIT。GOMEMLIMIT 是一个新的环境变量，允许用户限制 Go 进程可以使用的内存量。这个功能提供了更好的控制 Go 应用程序内存使用的方式，防止它们使用过多的内存导致性能问题或崩溃。通过设置 GOMEMLIMIT 变量，用户可以确保其 Go 程序在系统上平稳高效地运行，而不会对系统造成不必要的压力。
它并不替代 GOGC，而是与之配合使用。您还可以禁用 GOGC 百分比配置，只使用 GOMEMLIMIT 来触发垃圾回收。
GOGC 设为 100 和内存限制为 100MB
GOGC 设为关闭(off)并且内存限制为 100
在减少垃圾回收的运行量方面有明显的效果，但在应用此设置时需要小心。如果您不了解应用程序的极限，请不要将 GOGC=off。
在字符串与字节之间进行转换时，我们通常会进行变量的复制。但在 Go 内部，这两种类型通常使用 StringHeader 和 SliceHeader 值。我们可以在这两种类型之间进行转换，而不进行额外的分配。
// For Go 1.20 and higherfunc 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 等库也在其内部使用这种结构。
注意： 如果您的字节或字符串值可能会在后续发生更改，请不要使用此特性。
我们通常在代码中使用 Marshal 和 Unmarshal 方法来进行序列化或反序列化。
Jsoniter 是 encoding/json 的 100% 兼容的替代品。
以下是一些性能基准：
将其替换为 encoding/json 非常简单：
import "encoding/json"json.Marshal(&data)json.Unmarshal(input, &data)import jsoniter "github.com/json-iterator/go"var json = jsoniter.ConfigCompatibleWithStandardLibraryjson.Marshal(&data)json.Unmarshal(input, &data)对象池背后的主要概念是避免重复创建和销毁对象的开销，这可能会对性能产生负面影响。
缓存先前分配但未使用的项目有助于减轻垃圾回收器的负担，并允许稍后重新使用它们。
以下是一个示例：
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): &{}通过使用 sync.Pool，我解决了 New Relic Go Agent 中的内存泄漏问题。以前，它为每个请求创建一个新的 gzip writer。我创建了一个池，以便代理程序可以使用该池中的 writer，而不是为每个请求创建新的 gzip writer 实例，从而大大减少了堆使用，并因此减少了系统的垃圾回收次数。这个改进大约将我们应用程序的 CPU 使用率降低了约 40%，内存使用率降低了约 22%。
本文链接：http://www.28at.com/showinfo-26-17553-0.html提升您的 Go 应用性能的六种方法
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： Angular 发布新文档、新 Logo
下一篇： Python：求求按规范写我
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号