方法一：
内存分配器跟踪:GODEBUG=allocfreetrace=1
调度器追踪
调度器追踪能够提供对 goroutine 调度的动态行为的内视，而且同意调试负载平衡和可扩展性问题。要启用调度器追踪。
能够带有环境变量 GODEBUG=schedtrace=1000 来执行程序（这个值的意思是输入的周期，单位 ms，这样的情况下是每秒一次）：
set GODEBUG=schedtrace=1000
SCHED 1004ms: gomaxprocs=4 idleprocs=0 threads=11 idlethreads=4 runqueue=8 [0 1 0 3] SCHED 2005ms: gomaxprocs=4 idleprocs=0 threads=11 idlethreads=5 runqueue=6 [1 5 4 0] SCHED 3008ms: gomaxprocs=4 idleprocs=0 threads=11 idlethreads=4 runqueue=10 [2 2 2 1]
第一个数字（"1004ms"）是从程序開始后的时间。 Gomaxprocs 是当前的 GOMAXPROCS 值。 Idleprocs 是空载的处理器数（剩下的在执行 Go 代码）。Threads 是调度器产生的工作线程总数（线程有三种状态：执行 Go 代码（gomaxprocs-idleprocs），执行 syscalls/cgocalls。闲置）。 Idlethreads是闲置的工作线程数。 Runqueue 是执行的 goroutine 的全局队列长度。方括号里的数字（"[0 1 0 3]"）是可执行的 goroutine 的预处理器队列的长度。 全局和局部队列的长度总和表示执行中可用的 goroutine 的总数。 注意：你能够任意组合追踪器。如：GODEBUG = gctrace = 1，allocfreetrace = 1，schedtrace = 1000。 注意：相同有具体的调度器追踪，你能够这样启用它：GODEBUG = schedtrace = 1000，scheddetail = 1。它将会输出每个 goroutine、工作线程和处理器的具体信息。我们将不会在这里讨论它的格式，由于它主要是给调度器开发人员使用；你能够在这里src/pkg/runtime/proc.c找到它的具体信息。 当一个程序不与 GOMAXPROCS 成线性比例和/或没有消耗 100% 的 CPU 时间，调度器追踪就显得很实用。理想的情况是：全部的处理器都在忙碌地执行 Go 代码，线程数合理。全部队列都有充足的任务且任务是合理均匀的分布的： gomaxprocs=8 idleprocs=0 threads=40 idlethreads=5 runqueue=10 [20 20 20 20 20 20 20 20] 不好的情况是上面所列的东西并没有全然达到。比如以下这个演示，没有足够的任务来保持全部的处理器繁忙： gomaxprocs=8 idleprocs=6 threads=40 idlethreads=30 runqueue=0 [0 2 0 0 0 1 0 0] 注意：这里使用操作系统提供的实际CPU利用率作为终于的标准。在 Unix 系操作系统中是 top 命令。在 Windows 系统中是任务管理器。 你能够使用 goroutine 分析器来了解哪些 goroutine 块处于任务短缺状态。 注意，仅仅要全部的处理器处于忙绿状态，负载失衡就不是最坏的，它仅仅会导致适度的负载平衡开销。
内存统计 Go 执行时能够通过 runtime.ReadMemStats 函数提供粗糙的内存统计。 这个统计相同能够通过 http://myserver:6060/debug/pprof/heap? debug=1 底部的net/http/pprof提供。统计资料，点击此处。 一些值得关注的地方是: 1. HeapAlloc - 当前堆大小。 2. HeapSys - 总的堆大小。 3. HeapObjects - 堆中对象的总数。 4. HeapReleased - 释放到操作系统中的内存。假设内存超过五分钟没有使用，执行时将会把它释放到操作系统中，你能够通过 runtime/debug.FreeOSMemory 来强制改变这个过程。 5. Sys - 操作系统分配的总内存。 6. Sys-HeapReleased - 程序的有效内存消耗。 7. StackSys - goroutine 栈的内存消耗（注意：一些栈是从堆中分配的。因此没有计入这里。不幸的是，没有办法得到栈的总大小（https://code.google.com/p/go/issues/detail?id=7468））。 8. MSpanSys/MCacheSys/BuckHashSys/GCSys/OtherSys - 执行时为各种辅助用途分配的内存；它们没什么好关注的，除非过高的话。 9. PauseNs - 最后一次垃圾回收的持续时间。
使用：set GODEBUG=gctrace=1 / GODEBUG=gctrace=2
直接执行可执行文件：server.exe
格式：gc # @#s #%: #+...+# ms clock, #+...+# ms cpu, #->#-># MB, # MB goal, # P
GC #
表示第几次GC
@#s
表示程序開始多长时间运行的GC
#%
表示程序開始GC时间占用的百分比（percentage of time spent in GC since program start）
#+...+#
表示GC运行时CPU堵塞时间和
#->#-># MB
表示GC開始堆大小,结束堆大小,在活跃堆大小
# MB goal
表示目标对大小
# P
表示程序执行时CPU核数
演示样例 ：
gc 13 @1277.835s 0%: 0+1.0+0+1.0+1.0 ms clock, 0+1.0+0+0/1.0/0+3.0 ms cpu, 0->0->0 MB, 4 MB goal, 4 P
方法二：
import _ "net/http/pprof"
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
在程序中加入以上代码.
-----------------------------------------------------------
使用以下的命令能够查看各项性能：
go tool pprof http://localhost:6060/debug/pprof/heap
查看30秒内的cpu使用：
go tool pprof http://localhost:6060/debug/pprof/profile
查看goroutime性能：
go tool pprof http://localhost:6060/debug/pprof/block
查看5秒的执行trace.
wget http://localhost:6060/debug/pprof/trace?seconds=5
在浏览器打开查看：
http://localhost:6060/debug/pprof/
https://blog.golang.org/2011/06/profiling-go-programs.html
命令：go tool pprof /mnt/Go/src/main http://localhost:6060/debug/pprof/heap
输入list能够看到具体情况.
输入web 能够在web页面查看
此外我们也能够执行go tool pprof your-executable-name --dot profile-filename > heap.gv，这样将得到一个heap.gv文件，我们在graphviz里面打开这个文件将得到一个更具体的包含调用关系在内的内存消耗图。当然。我们假设仅仅须要一张图，也能够执行dot -Tpng heap.gv > heap.png将这个gv文件另存为png图，这样就能够像我一样，在以下展示剖析结果了。
三、使用pprof文件分析：
import (
"runtime/pprof" // 引用pprof package
"os"
)
func main() {
f, _ := os.Create("profile_file")
pprof.StartCPUProfile(f) // 開始cpu profile，结果写到文件f中
defer pprof.StopCPUProfile() // 结束profile
...
}
执行 执行程序，生成profile文件 分析 在命令行上执行： go tool pprof [binary] [profile] 进入pprof环境后。能够用help命令查看帮助信息 最经常使用的命令如top10，能够看最耗时的function 这里详解一下top命令的输出格式。比如： 14 2.1% 17.2% 58 8.7% std::_Rb_tree::find 各字段的含义依次是： 1. 採样点落在该函数中的次数 2. 採样点落在该函数中的百分比 3. 上一项的累积百分比 4. 採样点落在该函数，以及被它调用的函数中的总次数 5. 採样点落在该函数，以及被它调用的函数中的总次数百分比 6. 函数名
时间： 2024-11-14 16:32:52