Go SDK自带了Profiling库，可以用来识别程序的缺陷、性能瓶颈。内置以下剖析能力：

1. CPU剖析（profile）：报告CPU的使用情况，定位到热点（消耗CPU周期最多的）代码。默认情况下Go以100HZ的频率进行CPU采样
2. 内存剖析（heap）：报告堆内存当前分配（存活对象）情况。默认情况下每分配512KB进行内存采样。你可以使用URL参数gc，提示报告前进行GC
3. 内存剖析（allocs）：报告所有内存分配历史
4. 线程创建（threadcreate）：报告导致新OS线程创建的代码片段，分析阻塞式系统调用
5. 协程剖析（goroutine）：报告所有Goroutine的调用栈
6. 阻塞剖析（block）：报告Goroutine在哪些同步原语（包括定时器通道）上阻塞，显示调用栈。必须显式调用

   runtime.SetBlockProfileRate

   来启用此特性。默认每发生一次阻塞均采样
7. 互斥量剖析（mutex）：报告锁竞争情况，显示持有互斥量的代码的调用栈。当你认为CPU英文锁竞争而没有被完全使用时，显式调用

   runtime.SetMutexProfileFraction

    来启用此特性
8. 执行追踪（trace）：追踪当前应用程序的执行栈

此外，Go还允许定制自己的剖析，在代码中手工报告性能分析数据。

要采集一个Go应用的剖析数据，有两种方式：

1. 利用runtime/pprof包，进行剖析数据采集，并且在应用退出时将剖析数据写入到文件
2. 利用net/http/pprof包，进行剖析数据采集，支持连接到HTTP服务实时分析

不管使用那种方式，都需要增加一些代码。

进行CPU剖析，添加如下代码：

f, err := os.Create(*cpuprofile)
if err != nil {
    log.Fatal("could not create CPU profile: ", err)
}
defer f.Close()
if err := pprof.StartCPUProfile(f); err != nil {
    log.Fatal("could not start CPU profile: ", err)
}
// 停止采样，并将剖析概要信息记录到文件
// 此方法实际上会将采样率设置为0
defer pprof.StopCPUProfile()

进行内存剖析，添加如下代码：

// 设置采样率，默认每分配512*1024字节采样一次。如果设置为0则禁止采样，只能设置一次
runtime.MemProfileRate = *memProfileRate


f, err := os.Create(*memprofile)
if err != nil {
    log.Fatal("could not create memory profile: ", err)
}
defer f.Close()
runtime.GC() // 执行GC，避免垃圾对象干扰
// 将剖析概要信息记录到文件
if err := pprof.WriteHeapProfile(f); err != nil {
    log.Fatal("could not write memory profile: ", err)
}

调用下面的方法启用此功能：

runtime.SetBlockProfileRate(5)

参数5表示，每发生5次Goroutine阻塞事件则采样一次。默认值1。 

下面的代码演示了如何将阻塞剖析概要信息记录到文件：

func stopBlockProfile() {
    if *blockProfile != "" && *blockProfileRate >= 0 {
        f, err := os.Create(*blockProfile)
        if err = pprof.Lookup("block").WriteTo(f, 0); err != nil {
            fmt.Fprintf(os.Stderr, "Can not write %s: %s", *blockProfile, err)
        }
        f.Close()
    }
} 

从Go 1.8开始，支持采集处于竞态条件的互斥锁，调用下面的方法启用此功能：

runtime.SetMutexProfileFraction(5)

此调用允许你捕获处于竞态条件的Goroutine的调用栈的一部分。

在进行测试时，不需要上述显式的调用，使用命令行参数即可：

go test -mutexprofile=mutex.out 

包net/http/pprof能够将实时剖析数据通过HTTP暴露为pprof可视化工具能识别的格式。

要使用此包，需要导入：

import _ "net/http/pprof"

你需要为pprof提供一个HTTP服务器：

go func() {
	log.Println(http.ListenAndServe("localhost:6060", nil))
}()

如果你不使用

http.DefaultServeMux

r.HandleFunc("/debug/pprof/", pprof.Index)
r.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
r.HandleFunc("/debug/pprof/profile", pprof.Profile)
r.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
r.HandleFunc("/debug/pprof/trace", pprof.Trace) 

要连接到HTTP服务进行实时分析，使用如下命令：

# 设置剖析摘要信息存放目录
export PPROF_TMPDIR=/tmp/pprof

# 获取堆快照
go tool pprof http://localhost:6060/debug/pprof/heap
# 获取从启动依赖的内存分配历史
go tool pprof http://localhost:6060/debug/pprof/allocs

# 30秒CPU分析，需要等待30秒才能看到命令提示符
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Goroutine阻塞分析
go tool pprof http://localhost:6060/debug/pprof/block

# 收集5秒的执行调用栈
wget http://localhost:6060/debug/pprof/trace?seconds=5

# 互斥锁分析
go tool pprof http://localhost:6060/debug/pprof/mutex

要查看所有可用的剖析， 访问 http://localhost:6060/debug/pprof/ 。

#             可执行文件路径
#                      保存的剖析摘要文件
go tool pprof bin/Temp mutex.mprof

通过工具go tool pprof打开URL或文件后，会显示一个

(pprof)

focus

sudo apt-get install graphviz
sudo apt-get install gv

routine_regexp

--cum

routine_regexp

filename

调用pprof时，可以选择启动一个Web UI，指定-http选项即可：

go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap

 你可以访问Web UI来查看烈焰图等高级图表。

这里使用一段CPU密集型代码来学习CPU剖析：

package main

import (
	"net/http"
	_ "net/http/pprof"
	"sync"
	"time"
)

var wg sync.WaitGroup

func main() {
	go func() {
		http.ListenAndServe("localhost:6060", nil)
	}()

	wg.Add(1)
	go calculte(wg)
	wg.Wait()
}

func calculte(wg sync.WaitGroup) {
	for i := 0; i < 100000000; i++ {
		time.Sleep(time.Millisecond)
		cpuBound(i)
	}
	wg.Done()
}

func cpuBound(i int) {
	factorial(i)
	sieveOfEratosthenes(i)
}
func sieveOfEratosthenes(N int) (primes []int) {
	b := make([]bool, N)
	for i := 2; i < N; i++ {
		if b[i] == true {
			continue
		}
		primes = append(primes, i)
		for k := i * i; k < N; k += i {
			b[k] = true
		}
	}
	return
}

func factorial(x int) int {
	if x == 0 {
		return 1
	}

	return x * factorial(x-1)
}

(pprof) top10
Showing nodes accounting for 24630ms, 83.75% of 29410ms total
Dropped 107 nodes (cum <= 147.05ms)
Showing top 10 nodes out of 31
      flat  flat%   sum%        cum   cum%
    4720ms 16.05% 16.05%     4990ms 16.97%  main.sieveOfEratosthenes
    4510ms 15.33% 31.38%    19440ms 66.10%  runtime.gentraceback
    3550ms 12.07% 43.45%    23490ms 79.87%  main.factorial
    2810ms  9.55% 53.01%     8460ms 28.77%  runtime.getStackMap
    2130ms  7.24% 60.25%     3220ms 10.95%  runtime.funcdata
    2070ms  7.04% 67.29%     2630ms  8.94%  runtime.findfunc
    1540ms  5.24% 72.53%     1740ms  5.92%  runtime.pcvalue
    1400ms  4.76% 77.29%     1400ms  4.76%  runtime.add
    1000ms  3.40% 80.69%     9610ms 32.68%  runtime.adjustframe
     900ms  3.06% 83.75%     1070ms  3.64%  runtime.pcdatastart
...
         0     0% 97.18%      5.01s 17.04%  main.calculte
         0     0% 97.18%      4.99s 16.97%  main.cpuBound

使用top命令可以直接看到消耗CPU最多的方法，各列含义如下：

1. flat：在采样期间，此函数正在执行的次数 * 10ms。 可以用来粗略估计函数的运行耗时，不包含当前函数调用其它函数并等待返回的时间
2. flat%：flat / 总采样时间。估算函数运行耗CPU占比
3. sum%：当前行加上前面所有行的flat%总和
4. cum：在采样期间，此函数出现在调用栈的次数*10ms。和flat相比，该指标包含子函数耗时
5. cum%：cum/总采样时间

要以cum降序输出，执行

top10 -cum

上面的例子中，factorial是自递归调用，其cum值不知道为何比父例程cpuBound还要大得多，不符合只觉。

通过top定位到耗时函数后，可以进一步使用该命令，分析函数每一行代码消耗多少时间。

函数cpuBound调用两个子例程factorial、sieveOfEratosthenes，它们都是非常耗时的：

(pprof) list cpuBound
Total: 29.41s
ROUTINE ======================== main.cpuBound in /home/alex/Go/workspaces/default/src/git.gmem.cc/alex/go-study/golang/profile.go
         0      4.99s (flat, cum) 16.97% of Total
         .          .     27:	wg.Done()
         .          .     28:}
         .          .     29:
         .          .     30:func cpuBound(i int) {
         .          .     31:	factorial(i)
         .      4.99s     32:	sieveOfEratosthenes(i)
         .          .     33:}
         .          .     34:func sieveOfEratosthenes(N int) (primes []int) {
         .          .     35:	b := make([]bool, N)
         .          .     36:	for i := 2; i < N; i++ {
         .          .     37:		if b[i] == true {

从上面的输出可以看到， cpuBound的全部时间均消耗在对sieveOfEratosthenes的调用上，而factorial这个自递归调用的耗时无法体现。

使用此命令可以生成一个SVG图片，清晰的显示调用关系图。图中越红的节点消耗CPU越多： 

从图中可以看到factorial函数引发的调用链最耗时，calculte其次。由于factorial是自递归调用，calculte到factorial的调用关系没有识别出来。

这里使用一段内存消耗型代码来学习CPU剖析：

package main

import (
	"net/http"
	_ "net/http/pprof"
	"time"
)

type pkg struct {
	blob
}
type blob struct {
	data [1024]int
}

func main() {
	go func() {
		http.ListenAndServe("localhost:6060", nil)
	}()
	consume()
}

func consume() {
	for i := 0; i < 100000000; i++ {
		time.Sleep(time.Millisecond * 1)
		b100 := createBlob(100)
		println(b100)
		p100 := createPkg(100)
		println(p100)
	}
}

func createPkg(i int) interface{} {
	ps := make([]pkg, 0)
	for x := 0; x < i; x++ {
		ps = append(ps, pkg{})
	}
	return ps
}

func createBlob(i int) []blob {
	bs := make([]blob, 0)
	for x := 0; x < i; x++ {
		bs = append(bs, blob{})
	}
	return bs
}

执行下面的命令，可以获取一个堆快照，快照中包含所有存活对象：

go tool pprof http://localhost:6060/debug/pprof/heap

使用top命令可以看到哪些方法分配了最多的内存：

(pprof) top
Showing nodes accounting for 1.95MB, 100% of 1.95MB total
      flat  flat%   sum%        cum   cum%
    1.95MB   100%   100%     1.95MB   100%  main.createPkg
         0     0%   100%     1.95MB   100%  main.consume
         0     0%   100%     1.95MB   100%  main.main
         0     0%   100%     1.95MB   100%  runtime.main

可以看到，在本次快照中，createPkg分配的内存最多。

使用list命令，可以进一步定位到createPkg的哪一行代码分配了这些内存：

(pprof) list createPkg
Total: 1.95MB
ROUTINE ======================== main.createPkg in /home/alex/Go/workspaces/default/src/git.gmem.cc/alex/go-study/golang/heap.go
    1.95MB     1.95MB (flat, cum)   100% of Total
         .          .     31:}
         .          .     32:
         .          .     33:func createPkg(i int) interface{} {
         .          .     34:   ps := make([]pkg, 0)
         .          .     35:   for x := 0; x < i; x++ {
    1.95MB     1.95MB     36:           ps = append(ps, pkg{})
         .          .     37:   }
         .          .     38:   return ps
         .          .     39:}
         .          .     40:
         .          .     41:func createBlob(i int) []blob {

可以看到，全部内存均由于代码

ps = append(ps, pkg{})

类似的，使用web命令可以展示出内存分配的调用栈。

执行下面的命令，可以获取程序运行依赖，所有内存分配的历史：

go tool pprof http://localhost:6060/debug/pprof/allocs

用top命令看，分配内存的量明显比heap剖析大的多：

(pprof) top
Showing nodes accounting for 5.69TB, 100% of 5.69TB total
Dropped 33 nodes (cum <= 0.03TB)
      flat  flat%   sum%        cum   cum%
    2.85TB 50.00% 50.00%     2.85TB 50.00%  main.createPkg
    2.85TB 50.00%   100%     2.85TB 50.00%  main.createBlob
         0     0%   100%     5.69TB   100%  main.consume
         0     0%   100%     5.69TB   100%  main.main
         0     0%   100%     5.69TB   100%  runtime.main

使用web命令，可以展示出内存分配的调用栈：

所谓内存泄漏，意味着占用的内存一直无法释放。在pprof中，泄漏的内存一直存在于heap剖析的输出中，并且随着运行时间的增加，迟早会出现在top命令的输出中。

这里使用一段内存消耗型代码来学习阻塞剖析：

package main

import (
	"net/http"
	_ "net/http/pprof"
	"runtime"
	"sync"
	"time"
)

var mutex sync.Mutex

func main() {
	// rate = 1：统计所有的 block event,
	// rate <=0：关闭block profiling
	// rate > 1：阻塞时间t>rate那秒的event 一定会被统计，小于rate则有t/rate 的几率被统计
	runtime.SetBlockProfileRate(1 * 1000 * 1000)
	go func() {
		http.ListenAndServe("localhost:6060", nil)
	}()
	var wg sync.WaitGroup
	for ; ; {
		wg.Add(1)
		mutex.Lock()
		go worker(&wg)
		time.Sleep(2 * time.Millisecond)
		mutex.Unlock()
		wg.Wait()
	}
}
func worker(wg *sync.WaitGroup) {
	defer wg.Done()
	mutex.Lock()
	time.Sleep(1 * time.Millisecond)
	mutex.Unlock()
}

执行下面的命令，可以获取所有录制的阻塞事件：

go tool pprof http://localhost:6060/debug/pprof/block

top显示的是阻塞时间最长的方法：

(pprof) top
Showing nodes accounting for 2.99mins, 100% of 2.99mins total
Dropped 9 nodes (cum <= 0.01mins)
      flat  flat%   sum%        cum   cum%
  1.95mins 65.37% 65.37%   1.95mins 65.37%  sync.(*Mutex).Lock
  1.03mins 34.63%   100%   1.03mins 34.63%  sync.(*WaitGroup).Wait
         0     0%   100%   1.03mins 34.63%  main.main
         0     0%   100%   1.95mins 65.37%  main.worker
         0     0%   100%   1.03mins 34.63%  runtime.main
(pprof)

这里可以看到阻塞时间都消耗在互斥量的Lock和等待组的Wait方法上。 

使用top无法感知什么代码导致了阻塞，你可以使用web，展示导致阻塞的调用栈。 

package main

import (
	"math/rand"
	"net/http"
	_ "net/http/pprof"
	"runtime"
	"sync"
	"time"
)

var mutex sync.Mutex

func main() {
	// rate = 0：关闭 mutex prof
	// rate = 1：记录所有的 mutex event
	// rate > 1：随机记录 1/rate 的 mutex event
	runtime.SetMutexProfileFraction(1)
	go func() {
		http.ListenAndServe("localhost:6060", nil)
	}()

	go worker()
	go worker()
	var wg sync.WaitGroup
	wg.Add(1)
	wg.Wait()
}
func worker() {
	for ; ; {
		mutex.Lock()
		time.Sleep(time.Duration(rand.New(rand.NewSource(time.Now().Unix())).Intn(10)) * time.Second)
		mutex.Unlock()
	}
}

执行下面的命令，可以获取所有录制的互斥锁事件：

go tool pprof http://localhost:6060/debug/pprof/mutex

使用top命令，可以看到锁竞争的位置。

可以执行：

curl -s  http://localhost:6060/debug/pprof/goroutine?debug=2

来获取所有Goroutine的状态、调用栈。

如果Goroutine因为读写通道而阻塞，可以看到类似下面的输出：

goroutine 1 [chan receive, 7 minutes]:
main.main()
	/home/alex/Go/workspaces/default/src/git.gmem.cc/alex/go-study/golang/goroutine.go:21 +0x71

在这个例子中，主协程已经等待达7分钟。这种在通道上的等待是无法通过阻塞分析看到的。

如果Goroutine正在等待（包括网络）IO完成，可以看到类似下面的输出：

goroutine 436 [IO wait]:
internal/poll.runtime_pollWait(0x7ff9056e2dd8, 0x72, 0xb)

Go允许开发人员扩展自己的Profile，来跟踪任何资源的创建/释放。

假设你负责编写某个Blob服务器的客户端库，用户的需求是随时了解某个客户端实例打开了多少Blob。 你可以使用定制剖析满足此需求：

package blobstore

import "runtime/pprof"

// 定制剖析
var openBlobProfile = pprof.NewProfile("blobstore.Open")

// 打开一个Blob，所有Blob不再使用之后需要关闭
func Open(name string) (*Blob, error) {
	blob := &Blob{name: name}

	// ... 在这里加载并初始化Blob


	// 此方法将当前调用栈加入到剖析中，并且将此栈关联到对象blob
	// 信息存放在内部的一个map中，以blob为key，这意味着：
	//   1.blob必须适合用作key，而且它
	//   2.在显示调用Remove之前不会被GC
	// 如果剖析已经包含blob的调用栈，则panic

	// 2 表示跳过的栈帧数量，对于调用栈
	//   Add
	//   called from rpc.NewClient
	//   called from mypkg.Run
	//   called from main.main
	//  skip=0 从rpc.NewClient中的Add调用处开始记录
	//  skip=1 从mypkg.Run的NewClient调用处开始记录 
	openBlobProfile.Add(blob, 2)
	return blob, nil
}

// 关闭Blob并释放底层资源
func (b *Blob) Close() error {
	// 从Profile中移除对象b关联的调用栈
	openBlobProfile.Remove(b)
	return nil
}

如果此客户端库的使用者，想知道自己的程序当前打开了多少Blob，在什么地方（代码位置）打开的，可以这样编写：

package main

import (
	"fmt"
	"math/rand"
	"net/http"
	_ "net/http/pprof"
	"time"

	"myproject.org/blobstore"
)

func main() {
	for i := 0; i < 1000; i++ {
		name := fmt.Sprintf("task-blob-%d", i)
		go func() {
			// 打开Blob，会导致剖析记录数据
			b, err := blobstore.Open(name)
			if err != nil {
			}
			defer b.Close()
		}()
	}
	http.ListenAndServe("localhost:6060", nil)
}

程序运行期间，使用如下命令即可看到打开了哪些Blob：

go tool pprof http://localhost:6060/debug/pprof/blobstore.Open

(pprof) top
Showing nodes accounting for 800, 100% of 800 total
      flat  flat%   sum%        cum   cum%
       800   100%   100%        800   100%  main.main.func1 /Users/jbd/src/hello/main.go

The post Go应用性能剖析 appeared first on 绿色记忆.

Sysdig是一个开源的系统性能分析工具，可以实现strace、tcpdump、lsof、top、iftop等工具所具有的功能。

如果需要源代码级别的、通用剖析工具，可以参考：利用perf剖析Linux应用程序。

# CentOS 7
rpm --import https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public
curl -s -o /etc/yum.repos.d/draios.repo http://download.draios.com/stable/rpm/draios.repo
# yum update
yum -y install epel-release

yum install kernel-devel-$(uname -r)
yum install sysdig
/usr/lib/dkms/dkms_autoinstaller start
sysdig-probe-loader

-c 运行指定的chisel，如果chisel需要参数，则必须用--chisel=chiselname chiselargs形式
-cl 列出可用的chisel，从./chisels, ~/.chisels,/usr/share/sysdig/chisels搜索
-M 在指定秒数之后停止收集
-n 在获取指定数量的事件之后停止收集
-S 在捕获结束，例如列出top事件之后，打印汇总摘要
-s 捕获IO缓冲的前N字节，默认80

不加任何参数调用，每行显示一个捕获的事件，不断刷新。输出格式：

# 事件号 发生事件          CPU号   进程名(PID） 事件方向
#                                             事件类型 事件参数
1462218 16:40:38.068514659 3 <NA> (2941270) > switch next=2941697(sysdig) pgft_maj=0 pgft_min=0 vm_size=0 vm_rss=0 vm_swap=0                                                             
1462220 16:40:38.068515560 6 java (2556857) > futex addr=7F3B3888C598 op=129(FUTEX_PRIVATE_FLAG|FUTEX_WAKE) val=1                                                                        
1462222 16:40:38.068515997 5 java (2557004) > futex addr=7F3AEC01C894 op=137(FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET) val=1                                                                 
1462224 16:40:38.068516460 6 java (2556857) < futex res=0

可以将结果输出到文件而非控制台：

sysdig -w result.dump

sysdig -r result.dump

可以使用过滤器对sysdig输出进行过滤，过滤器支持 =、!=、contains等操作符

下面的命令列出可用的过滤器：

sysdig -l

----------------------
Field Class: fd

fd.num          # 文件描述符号
fd.type         # 文件描述符类型，支持的值：'file', 'directory', 'ipv4', 'ipv6', 'unix',
                # 'pipe', 'event', 'signalfd', 'eventpoll', 'inotify', 'signal fd'
fd.typechar     # 文件描述符类型简写，支持的值：f                 4       6       u
                #  p      e         s           l            i
                # o表示未知
fd.name         # 文件描述符全名，对于文件，即完整路径；对于套接字，即连接元组
fd.directory    # 文件描述符是文件，且它必须位于此目录下
fd.filename     # 文件描述符是文件，且它的basename是此值
fd.ip           # 匹配客户端或服务器IP地址
fd.cip          # 匹配客户端IP地址
fd.sip          # 匹配服务器IP地址
fd.lip          # 匹配本地地址
fd.rip          # 匹配远程地址
fd.port         # 匹配客户端或服务器端口
fd.cport        # 对于TCP/UDP，客户端端口
fd.sport        # 对于TCP/UDP，客户端端口
fd.lport        # 对于TCP/UDP，本地端口
fd.rport        # 对于TCP/UDP，远程端口
fd.l4proto      # 套接字协议，可选 'tcp', 'udp', 'icmp' or 'raw'
fd.sockfamily   # 套接字家族，可选 'ip' or 'unix'
fd.is_server    # 指定为true则用于套接字的进程必须是服务器端
fd.uid          # FD的唯一标识
fd.containername
                # container ID + FD name
fd.containerdirectory
                # container ID + directory name
fd.proto        # FD的协议
fd.cproto       # 对于TCP/UDP，客户端协议
fd.sproto       # 对于TCP/UDP，服务器协议
fd.lproto       # 对于TCP/UDP，本地协议
fd.rproto       # 对于TCP/UDP，远程协议
fd.net          # IP网络
fd.cnet         
fd.snet         
fd.lnet         
fd.rnet         
fd.connected    # 对于TCP/UDP，设置为true则仅仅匹配已连接的套接字

----------------------
Field Class: process

proc.pid        # 生成事件的进程的ID
proc.exe        # 第一个命令行参数，通常是可执行文件名
proc.name       # 生成事件的可执行文件的名称
proc.args       # 生成事件的进程的命令行参数
proc.env        # 环境变量 
proc.cmdline    # 完整命令行，也就是 proc.name + proc.args
proc.exeline    # 完整命令行，也就是 proc.exe + proc.args
proc.cwd        # 当前工作目录
proc.nthreads   # 进程包括的线程数量
proc.nchilds    # 进程包括的子线程数量（除去主线程）
proc.ppid       # 父进程ID
proc.pname      # 父进程名称
proc.pcmdline   # 父进程的cmdline
proc.apid       # 某个祖先进程的ID
proc.aname      # 某个祖先进程的名称
proc.loginshellid
                # 登陆Shell ID
proc.duration   # 进程已经启动的纳秒
proc.fdopencount
                # 进程打开的文件描述符数量
proc.fdlimit    # 进程能够打开的文件描述符数量
proc.fdusage    # 打开/最大文件描述符比率
proc.vmsize     # 进程虚拟内存大小，单位KB
proc.vmrss      # 驻留内存大小
proc.vmswap     # 交换到磁盘的内存大小
thread.pfmajor  # 进程启动以来主页面错误次数
thread.pfminor  # 进程启动以来次页面错误次数
thread.tid      # 线程ID
thread.ismain   # 如果指定为true，生成事件的线程必须是主线程
thread.exectime # 最后被调度的线程消耗的CPU纳秒数
thread.totexectime
                # 从捕获开始，当前线程使用的CPU纳秒总数
thread.cgroups  # 线程所属的Cgroup，聚合为单个字符串
thread.cgroup   # 线程所属的某个Cgroup子系统
thread.vtid     # 从产生事件的线程自己的PID命名空间看到的，自己的PID
proc.vpid       # 从产生事件的进程自己的PID命名空间看到的，自己的PID
thread.cpu      # 最近一秒消耗的CPU时间
thread.cpu.user # 最近一秒消耗的CPU时间（用户态）
thread.cpu.system
                # 最近一秒消耗的CPU时间（内核态）
thread.vmsize   # 对于主线程，即虚拟内存大小，对于非主线程，为0
proc.sid        # 会话ID
proc.sname      # 会话名称
proc.tty        # 进程的控制终端，0为无控制终端的进程
proc.exepath    # 可执行文件的完整路径
proc.vpgid      # 从产生事件的进程自己的PID命名空间看到的，自己的进程组ID

----------------------
Field Class: evt

evt.num         # 事件编号
evt.time        # 事件时间戳，包含纳秒部分
evt.time.s      # 事件时间戳，不包含纳秒
evt.datetime    # 事件时间戳，包含日期部分
evt.rawtime     # 原始时间戳，19700101到现在的纳秒数
evt.rawtime.s   # 原始时间戳，19700101到现在的秒数
evt.rawtime.ns  # 原始时间戳，小数部分（纳秒部分）
evt.reltime     # 从捕获到发生事件时流逝的时间
evt.reltime.s  
evt.reltime.ns  
evt.latency     # 配对的enter/exit事件的延迟，纳秒
evt.latency.s   
evt.latency.ns  
evt.latency.human
                # 可读格式，例如10.3ms
evt.deltatime   # 当前事件和上一个事件之间的延迟
evt.deltatime.s 
evt.deltatime.ns
evt.dir         # 事件方向，>为enter事件，<为exit事件
evt.type        # 事件（类型的）名称，例如open
evt.type.is     # evt.type.is.open匹配所有open事件
syscall.type    # 对于系统调用事件，指定系统调用名称，例如open
evt.category    # 事件分类，例如file表示文件操作包括open/close，net表示网络操作
                # memory表示mmap/brk等操作
evt.cpu         # 事件所在的CPU序号
evt.args        # 聚合为字符串的事件参数
evt.arg         # 单个事件参数，使用参数名或序号，例如evt.arg.fd或'evt.arg[0]
evt.res         # 事件结果字符串，如果成功SUCCESS，否则是错误码字符串，例如ENOENT 
evt.failed      # 如果true匹配失败事件
evt.is_io       # 匹配读写FD的事件，例如 read(), send, recvfrom()
evt.is_io_read  
evt.is_io_write 
evt.io_dir      # IO方向，r或w
evt.is_wait     # 如果true则匹配那些导致线程等待的事件，例如sleep(), select(), poll()
evt.wait_latency
                # 等待事件返回（exit）消耗的时间阈值
evt.is_syslog   # 事件是否是写入syslog
evt.is_open_read
                # 如果为true，匹配打开以进行读的open/openat事件
evt.is_open_write
                # 如果为true，匹配打开以进行写的open/openat事件

----------------------
Field Class: user

user.uid        # 用户ID
user.name       # 用户名称
user.homedir    # 家目录
user.shell      # 用户的Shell
user.loginuid   # 审计用户ID
user.loginname  # 审计用户名

----------------------
Field Class: group

group.gid       # 组ID
group.name      # 组名称

----------------------
Field Class: container

container.id    # 容器ID
container.name  # 容器名称
container.image # 容器镜像名称
container.image.id
                # 容器镜像ID
container.type  # 容器类型，例如docker, rkt
container.privileged
                # true则匹配运行在特权模式的容器
container.image.repository
container.image.tag
container.image.digest

----------------------
Field Class: k8s

k8s.pod.name    # Pod名称
k8s.pod.id      # Pod标识符
k8s.pod.label   # Pod的标签，例如k8s.pod.label.foo
k8s.pod.labels  # 逗号分隔的多个Pod标签
k8s.rc.name     # 复制控制器
k8s.rc.id       
k8s.rc.label    
k8s.rc.labels   
k8s.svc.name    # 服务
k8s.svc.id      
k8s.svc.label   
k8s.svc.labels  
k8s.ns.name     # 命名空间
k8s.ns.id       
k8s.ns.label    
k8s.ns.labels
k8s.rs.name     # 复制集
k8s.rs.id      
k8s.rs.label   
k8s.rs.labels   
                
k8s.deployment.name
                # Deployment
k8s.deployment.id
k8s.deployment.label
k8s.deployment.labels

过滤特定进程产生的事件： 

# 仅仅捕获sshd产生的事件
sysdig proc.name=sshd

# 读取Dump，仅仅显示mysqld产生的事件
sysdig -r result.dump proc.name=mysqld

Sysdig中的chisels是一小段Lua脚本，用于分析sysdig事件流。Chisels支持：

1. 实时分析：每秒刷新一次
2. 离线分析：会打印总体的汇总信息

执行下面的命令列出可用的Chisels：
 

sysdig -cl

Category: Application
---------------------
httplog         # HTTP请求日志
httptop         # HTTP请求TOP
memcachelog     # memcache请求日志

Category: CPU Usage
-------------------
spectrogram     # OS延迟的可视化直方图
subsecoffset    # 
topcontainers_cpu
                # CPU占用最高的容器
topprocs_cpu    # CPU占用最高的进程

Category: Errors
----------------
topcontainers_error
                # 错误最多的容器
topfiles_errors # 错误最多的文件
topprocs_errors # 错误最多的进程

Category: I/O
-------------
echo_fds        # 打印进程读写的文件
fdbytes_by      # IO字节数，根据一个任意的过滤器字段进行聚合
fdcount_by      # FD计数，根据一个任意的过滤器字段进行聚合
fdtime_by       # FD时间
iobytes         # 任何类型的FD的IO字节数总和
iobytes_file    # 文件IO字节数总和
spy_file        # 回响任何进程对所有文件进行的任何读写，可选的，你可以提供一个文件名，这样只会拦截
                # 单个文件上发生的读写
stderr          # 打印进程的标准错误
stdin           # 打印进程的标准输入
stdout          # 打印进程的标准输出
topcontainers_file
                # 读写磁盘字节数最多的容器
topfiles_bytes  # 被读写字节数最多的文件
topfiles_time   # 被访问时间最长的文件
topprocs_file   # 读写磁盘字节数最多的进程

Category: Logs
--------------
spy_logs        # 回响任何进程对任何日志文件执行的写入
spy_syslog      # 打印任何写入到syslog的消息

Category: Misc
--------------
around          # 在指定过滤器匹配时，输出指定事件范围附近的事件

Category: Net
-------------
iobytes_net     # 显示总和网络IO字节数
spy_ip          # 显示和指定IP地址的数据交换情况
spy_port        # 显示和指定端口的数据交换情况
topconns        # IO字节数最多的网络链接
topcontainers_net
                # 导致网络IO最多的容器
topports_server # 读写字节数最多的TCP/UDP端口
topprocs_net    # 导致网络IO最多的进程

Category: Performance
---------------------
bottlenecks     # 最缓慢的系统调用
fileslower      # 跟踪缓慢的文件IO
netlower        # 跟踪缓慢的网络IO
proc_exec_time  # 显示进程执行时间
scallslower     # 跟踪缓慢的系统调用
topscalls       # 调用次数最多的系统调用
topscalls_time  # 消耗时间最多的系统调用

Category: Security
------------------
list_login_shells
                # 列出登陆Shell的ID
shellshock_detect
                # 打印 shellshock攻击
spy_users       # 显示交互式的用户活动

Category: System State
----------------------
lscontainers    # 列出运行中的荣iq
lsof            # 列出（可过滤）打开的文件描述符
netstat         # 列出（可过滤）打开的网络链接
ps              # 列出（可过滤）运行中的进程

显示使用网络带宽最多的进程： 

sysdig -c topprocs_net

查看网络IO最高的进程： 

sysdig -c topprocs_net                                                                                                                                         
# Bytes               Process             PID                                                                                                                                              
# --------------------------------------------------------------------------------                                                                                                         
# 38.48KB             msgr-worker-1       198488                                                                                                                                           
# 24.36KB             msgr-worker-0       198488                                                                                                                                           
# 8.12KB              msgr-worker-2       198488                                                                                                                                           
# 76B                 bird                3951084                                                                                                                                          
# 52B                 zabbix_agentd       5930                                                                                                                                             
 #31B                 zabbix_agentd       5931

打印和目标主机之间的数据交换： 

# 以二进制形式打印
sysdig -s2000 -X -c echo_fds fd.cip=10.5.39.41
# 以ASCII形式打印
sysdig -s2000 -A -c echo_fds fd.cip=192.168.0.1

最繁忙服务器端口，按当前已建立连接数：

# 按服务器端口分组
sysdig -c fdcount_by fd.sport "evt.type=accept"

最繁忙客户端地址，按收发字节数：

sysdig -c fdbytes_by fd.cip

列出不是发往Apache的入站请求： 

sysdig -p "%proc.name %fd.name" "evt.type=accept and proc.name!=httpd"

捕获打开特定文件的进程： 

# 针对/var/log文件的事件
sysdig fd.name=/var/log
# 事件参数fd中包含/var/log的事件
sysdig fd.name contains /var/log
# 7227884 16:52:37.116806685 4 svlogd (5880) > write fd=6(<f>/var/log/calico/libnetwork/current) size=50 
# 7227885 16:52:37.116816800 4 svlogd (5880) < write res=50 data=./run: exec: line 3: libnetwork-plugin: not found.

下面的例子，显示被读写字节数最多的文件（瞬时）：

sysdig -c topfiles_bytes

# Bytes               Filename                                                                                                                                                             
# --------------------------------------------------------------------------------                                                                                                         
# 2.53KB              /etc/hosts                                                                                                                                                           
# 585B                /sys/fs/cgroup/memory/kubepods/besteffort/pod56e20dda-38bf-11e9-99bd-44a8421fdcc8/memory.stat                                                                        
# 563B                /sys/fs/cgroup/memory/kubepods/besteffort/memory.stat                                                                                                                
# 116B                /sys/fs/cgroup/cpu,cpuacct/kubepods/besteffort/cpuacct.usage_percpu

联用过滤器，仅仅显示/root下读写字节数最多的文件（瞬时）：

sysdig -c topfiles_bytes "fd.name contains /root"

联用过滤器，仅仅显示admin用户读写字节数最多的文件（瞬时）： 

sysdig -c topfiles_bytes "user.name=admin" 

显示延迟超过1ms的IO调用： 

sysdig -c fileslower 1
# evt.datetime            proc.name    evt.type LATENCY(ms)  fd.name
# ----------------------- ------------ -------- ------------ -----------------------------------------
# 2019-03-25 11:15:54.119 node_exporte read               75 /host/sys/fs/xfs/sda2/stats/stats

根据FD类型汇总IO数据量：

sysdig -r t.scap -c fdbytes_by fd.type

# Bytes     fd.type
# ------------------------------
# 485.00M   file
# 4.63M     unix
# 509.92KB  pipe
# 99.83KB   ipv4
# 53.79KB   event
# 3.08KB    inotify

根据目录汇总IO数据量，仅仅考虑文件IO： 

sysdig -r t.scap -c fdbytes_by fd.directory "fd.type=file"

# Bytes     fd.directory
# ------------------------------
# 101.89M   /tmp/
# 90.26M    /root/.ccache/tmp/
# 85.75M    /usr/include/c++/4.7.2/bits/
# 24.74M    /usr/include/c++/4.7.2/

在特定目录下，汇总每个文件的IO数据量：  

sysdig -r t.scap -c fdbytes_by fd.filename "fd.directory=/tmp/"

# Bytes     fd.filename
# ------------------------------
# 13.64M    ccJvb4Mi.s
# 9.33M     cc4pbJkV.s
# 6.72M     ccx9zir6.s

发现导致特定目录下文件IO的进程： 

# 根据进程名聚合
                                         # 逻辑与：IO的目标是/tmp/*.s文件
sysdig -r t.scap -c fdbytes_by proc.name "fd.directory=/tmp/ and fd.filename contains .s"

# Bytes     proc.name
# ------------------------------
# 50.57M    as
# 49.03M    cc1plus
# 1.54M     cc1
# 1B        httpd

发现针对特定文件IO的调用栈： 

sysdig -A -r t.scap -c echo_fds "fd.filename=ccJvb4Mi.s"

# ------ Write 4.00KB to /tmp/ccJvb4Mi.s
# .file"chisel.cpp"
# .text
# .Ltext0:
# .section.text._ZNSt9exceptionC2Ev,"axG",@p 

# CPU用量最大的进程
sysdig -pc -c topprocs_cpu
# 网络带宽用量最大的进程
sysdig -pc -c topprocs_net 
# 文件IO字节数最大
sysdig -pc -c topfiles_bytes
# 网络连接数最高
sysdig -pc -c topconns 

sysdig的图形化用户接口，类似于top或htop，但是功能要强大的多：

1. 支持实时分析，也支持分析sysdig跟踪文件。跟踪文件可以来自其它机器
2. 支持CPU、内存、磁盘IO、网络IO等多方面指标的详细分析
3. 支持跟踪进程、文件、网络连接的IO活动
4. 可以钻取到进程、文件、网络连接
5. 支持sysdig的过滤语法
6. 支持容器和K8S

csysdig基于view，每个view是一小段Lua脚本，负责收集指标并展示在屏幕上

apt-get install sysdig

 -d 刷新间隔，默认2000
-pc  容器支持，显示额外的容器相关的字段
-k 启用K8S支持，指定API Server的URL，可用环境变量SYSDIG_K8S_API代替
-K 使用指定的凭证来访问K8S，可用环境变量SYSDIG_K8S_API_CERT代替
-N 不把端口号转换为名称
-r 读取跟踪文件

1. 不使用参数调用该命令，执行实时分析；使用-r来分析跟踪文件
2. 按F2切换view
3. Enter可以钻取，Backspace可以退回
4. 按F5可以显示选中条目的IO活动
5. 按F6可以看到选中条目的sysdig事件

你可以钻取、上卷，快捷键分别为Enter、Backspace。例如你可以从进程钻取到线程，在不同的钻取级别，你都可以切换、查看其它view，非常强大

1. 进程视图：k杀死进程
2. 容器视图：b打开Shell

以系统调用为例，颜色越靠近红色，说明那个耗时区间的系统调用越多： 

F2选择视图时，右侧会给出每个字段的含义

The post 使用Sysdig进行系统性能分析 appeared first on 绿色记忆.

剖析（Profiling）是一种有效的、细粒度的软件性能检查手段，大部分编程语言的生态圈都有各种性能剖析工具。本文的讨论内容与具体编程语言无关，而关注在Linux系统上对应用程序的性能进行剖析。

Linux内核实现了非常有价值的性能分析基础设施（perf infrastructure），可以用于剖析各种CPU或软件事件。这一功能由perf_events接口暴露，并提供

perf

1. 为什么内核使用太多的CPU，哪些代码使用了这些CPU时间
2. 什么代码导致CPU二级缓存不命中
3. CPU是否因内存IO而卡顿
4. 什么代码在分配内存，分配了多少
5. 什么触发了TCP重传
6. 某个内核函数是否被频繁调用
7. 线程离开CPU的原因 

perf_events是内核2.6+的一部分，用户空间工具perf在包linux-tools-common中，需要安装才能使用。要想从剖析中获得更多内核相关信息，你需要符号（Symbol）和栈追踪，这可能需要安装额外的包，甚至使用特定选项重新编译你的内核。剖析用户空间代码时，也要求目标应用程序的调试信息（符号表）被保留。

perf_events有三种工作模式：

1. counting，在内核上下文对各种指标进行计数
2. sampling，对事件进行采样，并将性能数据存放到内核缓冲，然后异步的写入到perf.data
3. bpf，4.4版本内核引入的新特性，允许在内核中执行一段用户自定义的代码，以执行高效的过滤、汇总

perf_events的采样是基于事件进行的。采样的周期以事件的数量来表示，而非基于时间。当目标事件计数溢出指定的数值，则产生一个采样。

样本中包含的信息取决于用户和工具指定的度量类型，但是最重要的信息是指令指针（instruction pointer），也就是程序被中断时所处的位置。

这种基于中断的采样，在现代处理器上存在刹车效应。也就是说，样本中记录的指针，和程序被中断以处理PMU事件时的指令指针，可能相隔数十个指令。

record子命令默认使用cycle事件，类似于定期采样。

perf_events可以捕获的事件类型包括：

1. 硬件事件，来自CPU自己或CPU的PMU（Performance Monitoring Unit，性能监控单元），包含一系列微架构事件例如时钟周期、L1缓存丢失等。具体支持的事件类型取决于CPU型号
2. 软件事件，基于内核计数器的低级事件，例如CPU迁移、上下文切换、Minor Faults、Major Faults（页面错误）
3. 追踪点事件，由内核中的ftrace实现，包括：
   1. 内核追踪点事件，静态的、内核级的追踪点，硬编码到内核
   2. 用户静态定义追踪（USDT），用户态应用程序硬编码的追踪点
   3. 动态追踪，软件可以被动态instrumented，在任何位置创建事件。对于内核软件，使用kprobes框架，对于用户软件，使用uprobes
   4. 定时追踪，以任意频率抓取快照，主要用于CPU剖析，工作机制是定期引发中断

要启用内核动态追踪，需要使用内核编译参数CONFIG_KPROBES=y、CONFIG_KPROBE_EVENTS=y。要追踪基于帧指针的内核栈，需要内核编译参数CONFIG_FRAME_POINTER=y。

要启用用户动态追踪，需要使用内核编译参数CONFIG_UPROBES=y、CONFIG_UPROBE_EVENTS=y

事件有多种表示方式，最简单的是它的字符串表示。引用事件时，可以指定限定符：

# 剖析用户级、内核级的cycle事件
-e cycles
-e cycles:uk
# 仅用户级
-e cycles:u

限定符包括：

perf可以在不同的范围收集性能数据：

1. 单线程（per-thread）：仅仅监控选择的线程。如果线程被调度失去CPU，对它的性能计数暂停，如果线程被调度到其它CPU，计数会存储并恢复，继续在新CPU上进行计数
2. 单进程（ per-process）：进程的所有线程都被监控，计数被汇总
3. 单CPU（ per-cpu）：仅仅监控单颗、或者选定的几颗CPU上的事件
4. 全局（system-wide）：监控所有CPU上的事件

和其它调试工具一样，perf需要符号信息，符号用于将内存地址转换为可读的函数、变量名称。没有符号信息，你会看到0x7ff3c1cddf29这样的HEX代码，无法阅读。

如果需要被剖析的软件通过包管理器安装，你需要找到并安装对应的调试包（可能以-dbgsym为后缀）。如果找不到调试包，可以考虑手工编译。

Java、Node.js等基于虚拟机的语言，在自己的虚拟CPU上执行代码，因而具有自己管理栈和执行函数的方法。

为了通过perf来剖析这类语言的程序，你需要：

1. 对于Java，使用perf-map-agent
2. 对于Node.js，使用命令行选项

   --perf_basic_prof

你可能看不到完整的Java栈，这是因为X86上的Hotspot忽略了帧指针（Frame pointer）。在8u60+版本以后，可以使用-XX:+PreserveFramePointer修复这一问题。

为了方便剖析，编译时尽量保留帧指针，编译器的优化行为可能导致难以调试，但是很多情况下优化掉帧指针是默认行为。

缺少帧指针会导致无法看到完整的调用栈，解决此问题的方法有几种：

1. 使用DWARF（ELF文件通常使用的调试信息格式）信息来Unwind栈
2. 使用LBR（Last Branch Record），这是处理器特性，因此可能不可用
3. 保留帧指针

下面是默认情况下编译（-O2，忽略帧指针）得到的OpenSSH的剖析结果：

57.14%     sshd  libc-2.15.so        [.] connect           
               |
               --- connect
                  |          
                  |--25.00%-- 0x7ff3c1cddf29
                  |          
                  |--25.00%-- 0x7ff3bfe82761
                  |          0x7ff3bfe82b7c
                  |          
                  |--25.00%-- 0x7ff3bfe82dfc
                   --25.00%-- [...]

以

-fno-omit-frame-pointer

100.00%     sshd  libc-2.15.so   [.] __GI___connect_internal
               |
               --- __GI___connect_internal
                  |          
                  |--30.00%-- add_one_listen_addr.isra.0
                  |          add_listen_addr
                  |          fill_default_server_options
                  |          main
                  |          __libc_start_main
                  |          
                  |--20.00%-- __nscd_get_mapping
                  |          __nscd_get_map_ref
                  |          
                  |--20.00%-- __nscd_open_socket
                   --30.00%-- [...]

可以看到符号都显示出来了，另外add_one_listen_addr的祖先帧也显示出来了。 

你需要使用

CONFIG_FRAME_POINTER=y

从内核3.9版本开始，缺失栈指针的问题有个变通的解决方案（对于用户空间的栈）——使用libunwind。libunwind基于dwarf，调用perf时传入--call-graph dwarf即可。

在Ubuntu上可以这样安装：

apt install linux-tools-common

系统可能会提示你安装其它的包，安装即可。

perf支持一系列的子命令：

运行一个命令，并收集性能计数器。

对于任何支持计数的事件，perf都能够在进程执行期间对发生的事件进行计数，计数结果会直接打印在控制台上。

stat子命令可以在线程、进程、CPU、全局级别进行计数。默认情况下进程的所有线程、子进程的计数都被统计在内，可以通过-i选项修改此行为。

参考record子命令。

# 如果不指定-e，则默认收集所有事件的计数器
perf stat [-e <EVENT> | --event=EVENT] [-a] <command>
perf stat [-e <EVENT> | --event=EVENT] [-a] -- <command> [<options>]

# CPU性能计数器
perf stat command

# 详细的CPU性能计数器
perf stat -d command

# 收集指定进程的性能计数，直到Ctrl-C
perf stat -p PID

# 收集整个系统的性能计数，持续5秒
perf stat -a sleep 5
# Performance counter stats for 'system wide':
#      20010.623960      cpu-clock (msec)          #    4.000 CPUs utilized          
#            61,947      context-switches          #    0.003 M/sec                  
#             4,153      cpu-migrations            #    0.208 K/sec                  
#                99      page-faults               #    0.005 K/sec                  
#     5,003,068,069      cycles                    #    0.250 GHz                      (49.96%)
#     2,000,087,622      instructions              #    0.40  insn per cycle           (75.00%)
#       393,183,513      branches                  #   19.649 M/sec                    (75.05%)
#        24,391,051      branch-misses             #    6.20% of all branches          (74.99%)

#       5.003219775 seconds time elapsed


# 指定需要收集的几种计数器，持续10秒
perf stat -e cycles,instructions,cache-references,cache-misses,bus-cycles -a sleep 10

# CPU一级缓存计数器
perf stat -e L1-dcache-loads,L1-dcache-load-misses,L1-dcache-stores command

# TLB计数器
perf stat -e dTLB-loads,dTLB-load-misses,dTLB-prefetch-misses command

# CPU最后一级缓存计数器
perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-prefetches command

# 统计指定进程的系统调用
perf stat -e 'syscalls:sys_enter_*' -p PID

# 统计全局系统调用
perf stat -e 'syscalls:sys_enter_*' -a sleep 5

# 统计调度器相关事件
perf stat -e 'sched:*' -p PID
perf stat -e 'sched:*' -p PID sleep 10

# 统计Ext4相关事件
perf stat -e 'ext4:*' -a sleep 10

# 统计块IO事件
perf stat -e 'block:*' -a sleep 10

# 收集多种事件
perf stat -e cycles,instructions,cache-misses

动态显示执行成本最高的项。

默认情况下以cycles事件采样，样本最高的输出在最顶部。

# 动态显示成本最高的地址和符号，不保存到文件
perf top -F 49
# 动态显示成本最高的命令
perf top -F 49 -ns comm,dso

此命令可以启动一个命令，并对其进行剖析，然后把剖析数据记录到文件（默认perf.data）。按Ctrl - C可以随时结束剖析。

此命令可以在线程、进程、CPU、全局级别进行剖析。

record, report, annotate是一组相关的命名，通常的使用流程是：

1. 在被剖析机器上调用record录制数据
2. 拷贝录制的perf.data，在任意机器上调用report、annotate进行分析

该命令不是记录所有事件，还是进行采样。默认情况下采样基于cycle事件，也就是进行定期采样。

perf_events接口允许通过两种方式描述采样周期：

1. period：事件发生的次数
2. frequency：每秒样本的平均个数

perf默认使用第二种，具体来说对应到-F选项。-F 1000表示1000Hz，也就是每秒平均采样1000个。内核会动态的调整采样周期，以尽量满足需求。

perf record [-e <EVENT> | --event=EVENT] [-l] [-a]    <command>
perf record [-e <EVENT> | --event=EVENT] [-l] [-a] -- <command> [<options>]

perf report -T

-C 0,2-3

# 以99HZ的频率剖析指定的命令，默认情况下工作在Per-thread模式
perf record -F 99 command

# 以99HZ的频率剖析指定的PID
perf record -F 99 -p PID
# 以99HZ的频率剖析指定的PID，持续10秒
perf record -F 99 -p PID sleep 10
# 以99HZ的频率剖析整个系统
perf record -F 99 -ag -- sleep 10

# 基于事件发生次数，而非采样频率来指定采样周期
perf record -e retired_instructions:u -c 2000

# 进行栈追踪（通过Frame Pointer）
perf record -F 99 -p PID -g -- sleep 10
# 进行栈追踪（通过DWARF）
perf record -F 99 -p PID --call-graph dwarf sleep 10
# 全局性栈追踪
perf record -F 99 -ag -- sleep 10  # 4.11之前
perf record -F 99 -g -- sleep 10   # 4.11之后
# 追踪某个容器的栈
perf record -F 99 -e cpu-clock --cgroup=docker/1d567f4393190204...etc... -a -- sleep 10

# 每发生10000次L1缓存丢失，进行一次采样
perf record -e L1-dcache-load-misses -c 10000 -ag -- sleep 5
# 每发生以100次最后级别的CPU缓存丢失，进行一次采用
perf record -e LLC-load-misses -c 100 -ag -- sleep 5 

# 采样内核指令
perf record -e cycles:k -a -- sleep 5 
# 采用用户指令
perf record -e cycles:u -a -- sleep 5 
# 精确采样用户指令，基于PEBS
perf record -e cycles:up -a -- sleep 5

# 追踪新进程的创建
perf record -e sched:sched_process_exec -a

# 追踪上下文切换
perf record -e context-switches -a
perf record -e context-switches -c 1 -a
perf record -e context-switches -ag
# 追踪通过sched跟踪点的上下文切换
perf record -e sched:sched_switch -a

# 追踪CPU迁移
perf record -e migrations -a -- sleep 10

# 追踪所有connect调用（出站连接）
perf record -e syscalls:sys_enter_connect -ag
# 追踪所有accepts调用（入站连接）
perf record -e syscalls:sys_enter_accept* -ag

# 追踪所有块设备请求
perf record -e block:block_rq_insert -ag
# 追踪所有块设备发起和完成
perf record -e block:block_rq_issue -e block:block_rq_complete -a
# 追踪100KB（200扇区）以上的块操作完成
perf record -e block:block_rq_complete --filter 'nr_sector > 200'
# 追踪所有同步写操作的完成
perf record -e block:block_rq_complete --filter 'rwbs == "WS"'
# 追踪所有写操作的完成
perf record -e block:block_rq_complete --filter 'rwbs ~ "*W*"'

# 采样Minor faults（RSS尺寸增加）
perf record -e minor-faults -ag
perf record -e minor-faults -c 1 -ag
# 采样页面错误
perf record -e page-faults -ag

# 追踪所有Ext4调用，并把结果写入到非Ext4分区
perf record -e 'ext4:*' -o /tmp/perf.data -a 

# 追踪kswapd唤醒事件
perf record -e vmscan:mm_vmscan_wakeup_kswapd -ag

# 添加Node.js USDT 探针，要求Linux 4.10+
perf buildid-cache --add `which node`
# 跟踪Node.js http__server__request USDT事件
perf record -e sdt_node:http__server__request -a 

此命令用于分析perf record生成的perf.data文件。

perf report [-i <file> | --input=file]

默认情况下，样本根据函数（符号）分类，数量最多的样本位于最前面：

#  Overhead        Command  Shared Object                      Symbol
+  21.70%          swapper  [kernel.kallsyms]              [k] 0xffffffff8104f45a
+   8.89%  qemu-system-x86  [kernel.kallsyms]              [k] 0xffffffff810496f6
+   3.32%             Xorg  [kernel.kallsyms]              [k] 0xffffffff8172da33
+   2.96%       vmware-vmx  [kernel.kallsyms]              [k] 0xffffffff81121880
+   2.23%           chrome  chrome                         [.] 0x0000000004fdb6e6
+   2.17%             java  [kernel.kallsyms]              [k] 0xffffffff8109f02b
+   1.71%           chrome  [kernel.kallsyms]              [k] 0xffffffff8172d982
+   1.56%             Xorg  [nvidia]                       [k] _nv008054rm
+   1.55%             Xorg  [nvidia]                       [k] _nv014095rm

各列含义如下：

1. Overhead，在对应函数中采样到的样本计数
2.  Command，样本从什么应用程序中采集到
3. Shared Object，样本来自的ELF镜像。如果：
   1. 应用程序是动态链接的，这里可能显示共享库的名称
   2. 如果样本来自内核空间，则一律显示伪ELF镜像名“kernel.kallsyms”
4. 第4列是特权级别，点号表示用户级别，k、g、u、H分别表示内核级别、客户机内核级别、客户机用户级别、hypervisor
5. 最后一列是符号名称，如果缺乏调试信息，则显示为0x开头的函数内存地址

你可以指定多种分组规则，对样本数进行统计。

下面的例子根据共享对象分组：

perf report --sort=dso

+  48.05%  [kernel.kallsyms]                                                                                                                                                             
+   8.06%  libglib-2.0.so.0.4600.1                                                                                                                                                       
+   5.81%  libc-2.19.so                                                                                                                                                                  
+   4.93%  [nvidia]                                                                                                                                                                      
+   2.83%  libgobject-2.0.so.0.4600.1                                                                                                                                                    
+   2.39%  [kvm_intel]

下面的例子根据CPU序号分组：

perf report --sort=cpu

+  17.10%  0                                                                                                                                                                             
+  15.21%  2                                                                                                                                                                             
+  14.76%  4                                                                                                                                                                             
+  12.81%  6                                                                                                                                                                             
+  11.98%  3                                                                                                                                                                             
+  10.00%  5                                                                                                                                                                             
+   9.85%  1                                                                                                                                                                             
+   8.28%  7

perf不知道如何从压缩内核（vmlinuz）中抽取符号，如果你的内核保留了调试符号，则可以用-k来指出未压缩内核的位置：

perf report -k /tmp/vmlinux

如果在record时收集了调用链，则Overhead可以在Children、Self两个列中显示。Children显示子代函数的样本计数、Self显示函数自己的样本计数

# 报告perf.data
perf report

# 显示样本数量
perf report -n

# 树状结构显示，展开，可以追踪到高成本的执行路径
perf report --stdio
# 每行显示一个帧，扁平化显示，按成本降序排列
perf report --stdio -n -g folded

此命令用于源码级别的分析。

所有被采样到的函数都会被反汇编，每个指令占据采样的比例会被输出。

如果应用程序以-ggdb编译，annotate还能够生成源码级别信息：

------------------------------------------------
 Percent |   Source code & Disassembly of noploop
------------------------------------------------
         :
         :
         :
         :   Disassembly of section .text:
         :
         :   08048484 <main>:
         :   #include <string.h>
         :   #include <unistd.h>
         :   #include <sys/time.h>
         :
         :   int main(int argc, char **argv)
         :   {
    0.00 :    8048484:       55                      push   %ebp
    0.00 :    8048485:       89 e5                   mov    %esp,%ebp
[...]
    0.00 :    8048530:       eb 0b                   jmp    804853d <main+0xb9>
         :                           count++;
   14.22 :    8048532:       8b 44 24 2c             mov    0x2c(%esp),%eax
    0.00 :    8048536:       83 c0 01                add    $0x1,%eax
   14.78 :    8048539:       89 44 24 2c             mov    %eax,0x2c(%esp)
         :           memcpy(&tv_end, &tv_now, sizeof(tv_now));
         :           tv_end.tv_sec += strtol(argv[1], NULL, 10);
         :           while (tv_now.tv_sec < tv_end.tv_sec ||
         :                  tv_now.tv_usec < tv_end.tv_usec) {
         :                   count = 0;
         :                   while (count < 100000000UL)
   14.78 :    804853d:       8b 44 24 2c             mov    0x2c(%esp),%eax
   56.23 :    8048541:       3d ff e0 f5 05          cmp    $0x5f5e0ff,%eax
    0.00 :    8048546:       76 ea                   jbe    8048532 <main+0xae>
[...]

再次强调一下刹车现象，百分比信息可能不准确。

对于压缩内核，你可以指定非压缩版本内核的位置，以解析符号：

perf annotate -k /tmp/vmlinux -d symbol 

显示支持的事件列表。

# 显示所有事件
perf list

# 显示跟踪点sched下的事件
perf list 'sched:*'

用于定义新的追踪点，实现动态追踪。

perf probe [options] --add=PROBE [...]
perf probe [options] PROBE
perf probe [options] --del=[GROUP:]EVENT [...]
perf probe --list[=[GROUP:]EVENT]
perf probe [options] --line=LINE
perf probe [options] --vars=PROBEPOINT
perf probe [options] --funcs

# 为tcp_sendmsg函数添加进入追踪点，--add可以省略
perf probe --add tcp_sendmsg

# 移除tcp_sendmsg进入追踪点
perf probe -d tcp_sendmsg

# 为tcp_sendmsg函数添加退出追踪点
perf probe 'tcp_sendmsg%return'

# 显示tcp_sendmsg的可用变量，需要debuginfo
perf probe -V tcp_sendmsg
# 显示tcp_sendmsg的可用变量和外部变量
perf probe -V tcp_sendmsg --externs

# 显示tcp_sendmsg可用的行探针
perf probe -L tcp_sendmsg

# 显示tcp_sendmsg的81行可用的探针
perf probe -V tcp_sendmsg:81

# 为tcp_sendmsg添加进入进入追踪点，使用3个参数寄存器（依赖于平台）
perf probe 'tcp_sendmsg %ax %dx %cx'

# 为tcp_sendmsg添加进入进入追踪点，且将cx寄存器设置别名bytes（依赖于平台）
perf probe 'tcp_sendmsg bytes=%cx'

# 追踪tcp_sendmsg，要求%cx变量大于100
perf record -e probe:tcp_sendmsg --filter 'bytes > 100'

# 捕获返回值
perf probe 'tcp_sendmsg%return $retval'

# 为tcp_sendmsg和它的入口参数size添加追踪点，需要debuginfo，但是不依赖平台
perf probe 'tcp_sendmsg size'

# 为tcp_sendmsg和size、Socket状态添加追踪点
perf probe 'tcp_sendmsg size sk->__sk_common.skc_state'

# size大于0并且套接字状态不为TCP_ESTABLISHED时追踪tcp_sendmsg
perf record -e probe:tcp_sendmsg --filter 'size > 0 && skc_state != 1' -a

# 在tcp_sendmsg的81行添加追踪点，使用局部变量seglen
perf probe 'tcp_sendmsg:81 seglen'

# 为libc的用户态malloc函数添加探针
perf probe -x /lib64/libc.so.6 malloc

# 列出可用的动态探针
perf probe -l?

该命令使用额外的信息来增强事件流。

进行10秒钟的剖析：

perf record -a -g sleep 10

根据应用程序的名称进行分组，整体上根据样本的执行成本进行排序：

perf report --sort comm,dso

可以展开执行成本高的项，追踪到CPU时间都消耗在哪里了：

对于上面这个例子，可以看到，kubelet消耗的资源主要用于Prometheus相关的指标收集，以及grpc的客户端。

perf stat -- tar xzf ideaIU-2018.3.3.tar.gz 

 Performance counter stats for 'tar xzf ideaIU-2018.3.3.tar.gz':
    # 反映CPU利用率
       9725.627068 task-clock (msec)         #    0.941 CPUs utilized          
    # 上下文切换数量
            45,568 context-switches          #    0.005 M/sec                  
             1,370 cpu-migrations            #    0.141 K/sec        
    # 页面错误数量          
               623 page-faults               #    0.064 K/sec                  
    # 经过的时钟周期的数量
    36,249,427,884 cycles                    #    3.727 GHz                    
    # IPC，每时钟周期指令数（instructions per cycle），通常越高越好，表示工作处理过程是优化的
    # 但是，最好还是检查实际执行的指令，Spin loop就是高指令频率但是实际上什么事都不做的反例
    46,378,956,536 instructions              #    1.28  insns per cycle
     # 分支和分支预测失败
     8,274,686,762 branches                  #  850.813 M/sec                  
       214,332,307 branch-misses             #    2.59% of all branches        

      10.334029429 seconds time elapsed

perf_events支持使用固定频率来采样指令指针或栈追踪，进而分析CPU使用。采样频率通过-F选项指定。

频率可以选用99，而非100HZ，以避免采样和某些周期性活动的步调完全一致而导致结果失真。如果需要更高分辨率的采样，可以使用997这样的频率，但是注意频率越高剖析本身的成本也越高。

示例：

# 以99HZ频率，全局的采样30秒
perf record -F 99 -a -g -- sleep 30

除了定时触发（固定频率采样），采样也可以由特定的CPU硬件计数器触发。使用这些计数器可以分析缓存丢失、memory stall cycles（由于访问内存而导致的时钟周期浪费，内存访问速度相对CPU时钟周期要慢的多）等更低级别的处理器事件。

可用的事件列表：

perf list | grep Hardware
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]
  cache-references                                   [Hardware event]
  cache-misses                                       [Hardware event]
  branch-instructions OR branches                    [Hardware event]
  branch-misses                                      [Hardware event]
  bus-cycles                                         [Hardware event]
  ref-cycles                                         [Hardware event]
  L1-dcache-loads                                    [Hardware cache event]
  L1-dcache-load-misses                              [Hardware cache event]
  L1-dcache-stores                                   [Hardware cache event]
  L1-dcache-store-misses                             [Hardware cache event]
  L1-dcache-prefetch-misses                          [Hardware cache event]
  L1-icache-load-misses                              [Hardware cache event]
  LLC-loads                                          [Hardware cache event]
  LLC-stores                                         [Hardware cache event]
  LLC-prefetches                                     [Hardware cache event]
  dTLB-loads                                         [Hardware cache event]
  dTLB-load-misses                                   [Hardware cache event]
  dTLB-stores                                        [Hardware cache event]
  dTLB-store-misses                                  [Hardware cache event]
  iTLB-loads                                         [Hardware cache event]
  iTLB-load-misses                                   [Hardware cache event]
  branch-loads                                       [Hardware cache event]
  branch-load-misses                                 [Hardware cache event]
  mem:<addr>[:access]                                [Hardware breakpoint]

如果每当发生这些事件，就记录栈追踪，对系统性能有严重的影响。因此，通常使用-c选项，当计数器增加一定数量后，记录一次栈追踪：

perf record -e L1-dcache-load-misses -c 10000 -ag -- sleep 5

上面这个例子，每当L1缓存丢失10000次，记录一次栈追踪。

下面的命令统计所有调用次数大于0的系统调用的数量：

perf stat -e 'syscalls:sys_enter_*' tar xzf ideaIU-2018.3.3.tar.gz 2>&1 | awk '$1 != 0'
 Performance counter stats for 'tar xzf ideaIU-2018.3.3.tar.gz':

                 2      syscalls:sys_enter_statfs                                   
            12,417      syscalls:sys_enter_utimensat                                   
  ...                                 
            12,417      syscalls:sys_enter_unlinkat                                   
  ...                                
            12,432      syscalls:sys_enter_newfstat                                   
                 1      syscalls:sys_enter_lseek                                    
           184,818      syscalls:sys_enter_read                                     
           192,154      syscalls:sys_enter_write                                    
                12      syscalls:sys_enter_access                                   
            12,417      syscalls:sys_enter_fchmod                                   
            12,417      syscalls:sys_enter_fchown                                   
                26      syscalls:sys_enter_open                                     
            24,834      syscalls:sys_enter_openat                                   
            12,442      syscalls:sys_enter_close                                                                 
  ...
      38.365080478 seconds time elapsed

可以看到，主要的系统调用都是read/write。

使用strace命令可以获得类似的结果，但是strace的成本要高的多。测试结果显示，perf可能让程序变慢2.5倍，而strace则会让程序变慢高达60倍。

perf record -e sched:sched_process_exec -a
# Ctrl-C
perf report -n --sort comm --stdio

# Overhead       Samples  Command
# ........  ............  .......
#
    32.14%             9  ionice 
    32.14%             9  nice   
    21.43%             6  du     
    10.71%             3  find   
     3.57%             1  ipset

追踪点sched:sched_process_exec在某个进程调用exec()产生另外一个进程时生效，这通常是新进程的产生方式。但是这个例子的结果不一定准确，原因是：

1. 进程可能fork()出子进程，追踪点sched:sched_process_fork可以用于这种情况
2. 应用程序可以reexec —— 针对自己再次调用exec() —— 这种用法可以清空地址空间，但是不会产生新进程

某些时候你希望了解服务器发起了哪些网络连接，是哪些进程发起的，为何发起。这些网络连接可能是延迟的根源。

追踪connect系统调用，即可了解出站连接：

perf record -e syscalls:sys_enter_connect -ag
perf report --stdio

# Children      Self  Trace output
# ........  ........  ............................................................
#
     5.88%     5.88%  fd: 0x00000005, uservaddr: 0xc4206fa390, addrlen: 0x0000001b
            |
            ---0x894812ebc0312874
               0xc42008e000
               runtime.main
               main.main
               github.com/projectcalico/node/pkg/readiness.Run
               github.com/projectcalico/node/pkg/readiness.checkBIRDReady
               github.com/projectcalico/node/pkg/readiness/bird.GRInProgress
               net.Dial
               net.(*Dialer).Dial
               net.(*Dialer).DialContext
               net.dialSerial
               net.dialSingle
               net.dialUnix
               net.unixSocket
               net.socket
               net.(*netFD).dial
               net.(*netFD).connect
               syscall.Connect
               syscall.Syscall

可以看到，占比最高的出站连接是由Calico Node容器发起的。

通过剖析套接字缓冲的使用情况，也是定位到什么代码使用了最多的网络I/O的一种方法：

perf record -e 'skb:consume_skb' -ag

使用perf可以了解应用程序为何休眠、在何处休眠、休眠多久。主要通过收集sched_stat、sched_switch事件实现。

剖析的目标代码如下：

for (i = 0; i <  10; i++) {
        ts1.tv_sec = 0;
        ts1.tv_nsec = 10000000;
        // 休眠
        nanosleep(&ts1, NULL);

        tv1.tv_sec = 0;
        tv1.tv_usec = 40000;
        // 休眠
        select(0, NULL, NULL, NULL,&tv1);
}

执行下面的命令开始剖析：

./perf record -e sched:sched_stat_sleep -e sched:sched_switch  -e sched:sched_process_exit -g -o perf.data.raw  sleep_test

合并sched_start、sched_switch事件：

perf inject -v -s -i perf.data.raw -o perf.data

报告：

perf report --stdio --show-total-period -i perf.data

  100.00%     502408738      foo  [kernel.kallsyms]  [k] __schedule
               |
               --- __schedule
                   schedule
                  |          
                  |--79.85%-- schedule_hrtimeout_range_clock
                  |          schedule_hrtimeout_range
                  |          poll_schedule_timeout
                  |          do_select
                  |          core_sys_select
                  |          sys_select
                  |          system_call_fastpath
                  |          __select
                  |          __libc_start_main
                  |          
                   --20.15%-- do_nanosleep
                             hrtimer_nanosleep
                             sys_nanosleep
                             system_call_fastpath
                             __GI___libc_nanosleep
                             __libc_start_main

The post 利用perf剖析Linux应用程序 appeared first on 绿色记忆.

Eclipse Memory Analyzer（MAT）是一个图形化的Java堆分析工具，速度快且特性丰富，可以用于取代JDK自带的堆Dump浏览器（jhat）。使用MAT，你可以快速分析包含上亿对象的生产环境Dump文件，快速计算某种对象导致的内存占用量，进而评估内存泄漏风险。

你可以将MAT安装为独立运行的RCP应用，也可以作为插件安装到现有的Eclipse中。

jhat不是本文的主题，这里做一个简单的介绍。

这是JVM自带的堆Dump分析工具，执行如下命令即可使用：

jhat a.map  # a.map为Dump文件路径

jhat默认在7000端口暴露HTTP服务，你可以通过浏览器进行以下查询：

下面是一段急剧消耗内存的示例代码：

package com.dangdang.digital.test;

import org.apache.commons.lang.math.RandomUtils;

import java.util.concurrent.TimeUnit;

public class BusyApplication {

    public static void main( String[] args ) {
        new MemoryPredator( Integer.parseInt( args[0] ), Integer.parseInt( args[1] ) ).start();
    }

}

class MemoryPredator extends Thread {

    private final int consumeInterval;

    private int retainTime;

    public MemoryPredator( int consumeInterval, int retainTime ) {
        this.consumeInterval = consumeInterval;
        this.retainTime = retainTime;
    }

    @Override
    public void run() {
        for ( ; ; ) {
            consumeMemory( retainTime );
            try {
                TimeUnit.MILLISECONDS.sleep( consumeInterval );
            } catch ( InterruptedException e ) {
            }
        }
    }

    private void consumeMemory( final int retainTime ) {
        new MemoryPreyThread( retainTime ).start();
    }

}

class MemoryPreyThread extends Thread {

    private final int retainTime;

    public MemoryPreyThread( int retainTime ) {
        this.retainTime = retainTime;
    }

    @Override
    public void run() {
        int n = ( RandomUtils.nextInt( 100 ) + 1 );
        Object bigObj = createBigObject( n );
        System.out.println( String.format( "%d MB consumed", n ) );
        try {
            TimeUnit.MILLISECONDS.sleep( retainTime );
        } catch ( InterruptedException e ) {
        }
    }

    private Object createBigObject( int n ) {
        Object big = new byte[n * 1024 * 1024];
        return big;
    }
}

让上述程序执行一段时间（应用程序参数使用500 7000），然后使用下面的命令获取堆Dump：

# 只Dump可达对象，使用二进制格式，输出为bzapp.hprof
jmap -dump:live,format=b,file=bzapp.hprof  `jps | grep BusyApplication | cut -d' ' -f1`

通过jhat开启服务后，打开浏览器，首先看到的是堆中包含的类的列表（不包含平台类）：

All Classes (excluding platform)

Package com.dangdang.digital.test
class com.dangdang.digital.test.BusyApplication [0xc0005048]
class com.dangdang.digital.test.MemoryPredator [0xc0004ff0]
class com.dangdang.digital.test.MemoryPreyThread [0xc0004f98]

Package com.jarego.jayatana
class com.jarego.jayatana.Agent [0xc0005200]

Package org.apache.commons.lang.math
class org.apache.commons.lang.math.JVMRandom [0xc0004e60]
class org.apache.commons.lang.math.RandomUtils [0xc0004f00]

点击界面下方的Show heap histogram连接，可以看到Shallow size最大的类型：

Class                                    Instance Count        Total Size

class [B                                 1063                  788662183
class [I                                 512                   6789172
class [C                                 2552                  349224
class java.lang.Class                    566                   54336
class [Ljava.lang.Object;                467                   48496
class [S                                 770                   44518
class java.lang.String                   2494                  39904
class java.net.URL                       346                   30448
class [Ljava.util.WeakHashMap$Entry;     156                   22464
class java.util.HashMap$Entry            771                   21588

可以看到byte[]类型，即[B，占用绝大部分内存，接近800MB。

点击class [B上的链接，进入byte[]类型的主页面“Class 0xc009a858”，后面的是类对象的内存地址，和Dump分析关系不大。留意“References to this object”这一段内容：

[B@0xbb0b6e18 (240 bytes) : ??
[B@0xc00bad20 (30 bytes) : ??
[B@0xbae503c0 (29 bytes) : ??
[B@0xbb091708 (115 bytes) : ??
[B@0xbb057350 (29 bytes) : ??

... 

[B@0xc87c6368 (15728656 bytes) : ??       # 大对象

任何类型的示例，都会持有该类型的Class对象的引用，byte[]也不例外。所有存活的byte[]对象因此列于“References to this object”中。我们需要关心的通常（取决于应用场景）是大对象，简单的滚动页面，留意那些更长的行，就可以定位到大的byte[]了。

可以看到对象[B@0xc87c6368占据了15M的内存空间，点击其上的链接，进入[B@0xc87c6368对象的主页面。在页面的下方，可以看到Other Queries - Reference Chains from Rootset - Exclude weak refs，点击后，可以查看从GC Root到此对象的引用链页面：

References to [B@0xc87c6368 (15728656 bytes)

Java Local References

Java Local Reference (from com.dangdang.digital.test.MemoryPreyThread@0xc4ec6208) : # 这是GCRoot

--> [B@0xc87c6368 (15728656 bytes)

至此，我们可以大概判定，引发内存问题的代码，位于类MemoryPreyThread中。

点击菜单项 File ⇨  Open Heap Dump ...，看到如下界面：

上半部分显示当前正在分析的对象的基本信息，以上面的截图为例：

下半部分包括4个选项卡：

1. Statics：此对象的类变量列表
2. Attributes：此对象的实例变量列表
3. Class Hierarchy：类层次图
4. Value：对象的值

此面板使用饼图显示Retained Size最大的对象，并列出其导致的内存驻留的尺寸。这些对象往往就是问题所在。

饼图上方的按钮区、和饼图下方的Actions/Reports/Step By Step，功能是对应的。

其中Actions包括：

1. Histogram：类似jhat的Histogram类似，但是支持统计Retained Size，支持排序
2. Dominator Tree：显示那些导致内存驻留最严重的对象，按对象导致驻留的比例，降序排列。可以展开这些对象的引用链
3. Top Consumers：以饼图、列表方式显示导致内存驻留最严重的对象、类、类加载器、包
4. Duplicate Classes：显示不同类加载器重复加载的类

其中Reports包括：

1. Leak Suspects：可以的内存泄漏报告，更加细粒度的、辅助人工分析的报告

使用jhat，我们就可以获取堆Dump中的全部信息了。 但是其UI非常简陋，缺乏排序、统计类功能，这些功能正是MAT能提供的。下面我们使用MAT来分析上一章的示例应用。

打开Dump后，在Overview面板的饼图上，可以立即看到所有大内存驻留都是由com.dangdang.digital.test.MemoryPreyThread类型的对象所引发。

单击任何一个饼图切片，点击菜单List Objects ⇨ With Outgoing References，可以看到对象引用的哪些对象的Shallow Size较大。这些对象就是内存驻留的根源：

很明显， MemoryPreyThread所引用的、byte[]类型的局部变量，其Shallow Size占据了全部内存份额。注意：如果上级对象的Outgoing引用特别多，则问题所在的子级对象可能看不到，这种情况下可以点击Retained Heap列排序或者手工展开。

对于像示例应用这样简单的代码，分析到这里就直接能定位到问题代码所在行号了。生产环境中的情况要复杂的多，单纯基于堆内存Dump进行静态分析不一定能奏效，需要结合线程栈Dump，甚至是剖析工具（JMC、JProfiler等）录制的内存分配历史。

概要情况如下图：

某个线程引用了接近6G的数据。从线程名字上来看，它是一个普通的工作线程，持有的6G内存应该是某种临时性对象。

分析此线程的Outgoing引用，排序Retained Heap列，将大内存条目显示出来：

可以看到，内存由一个局部变量（<Java Local>）导致。需要注意，局部变量的GC Root都是当前执行线程。出现问题的变量引用一个ArrayList对象，进一步展开可以猜测到此对象是数据库查询的结果集：

可以看到，此ArrayList的元素多达1000万。很可能是错误的SQL语句把大量行甚至整个表都读取过来，一下子把JVM内存撑爆了。

展开一个ByteArrayRow，查看行中的元素，进一步定位到所操作的表。配合JMC查看Hot Methods，定位到了存在问题的方法。

线上环境某服务，因为内存溢出、连续FGC被监控进程杀死，我们获得的堆Dump，内存占用总计1.7GB，Netty 3.x中的类NioClientSocketPipelineSink导致了绝大部分的内存驻留。

点击饼图中最大的切片NioClientSocketPipelineSink进行分析，打开菜单项List Objects ⇨ With Incoming References，展开：

可以看到NioClientSocketPipelineSink是Netty处理管线（Pipeline）的一部分。在很多框架中，管线常常和SRC、SINK等术语一起出现，SRC常常表示管线的输入、SINK则表示输出。

一个全局性的ChannelFactory、大量DefaultChannelPipeline通过sink属性引用了NioClientSocketPipelineSink。这些DefaultChannelPipeline应该是某种一次性对象，不熟悉代码的话只能猜测到这个程度，可以考虑通过JMC来录制对象分配的调用栈，来证实这种猜测。

那么，谁创建了这些DefaultChannelPipeline呢？从上面的截图中可以看到Dubbo的NettyClient间接引用了NioClientSocketPipelineSink，再随机抽取几个DefaultChannelPipeline展开：

可以看到来自Dubbo的NettyClient通过channel ⇨ pipeline ⇨ sink 引用了DefaultChannelPipeline。com.alibaba.dubbo上面引用链上唯一的非Netty包，我们有理由猜测Dubbo和内存溢出有关。

我们可以看一下相关对象的计数。对于希望统计数量的对象，在调用链上点选它，左下面板切换到Class Hierarchy，在类名上右击，选择List Object  ⇨ With Incoming References：

由于类的每个对象都会引用类对象，因此展开右侧窗口的根节点，即可知晓对象的大概数量。在本例中，DefaultChannelPipeline、NioClientSocketChannel的数量大概是130万，NettyClient的数量是33。

MAT的支配树功能，可以帮助你追踪实际（Shallow）消耗内存的对象：

可以看到，Netty内部的某种链表结构（LinkedTransferQueue）的每个元素的RegisterTask对象占用了1KB的内存，但是链表长度非常大，因此这个链表消耗了大量的内存。

从名字LinkedTransferQueue可以猜测，这是Netty用来存储待处理的网络数据的。

从MAT分析的结果来看，NioClientSocketPipelineSink的内部类Boss的实例变量registerTaskQueue，占据了高达1.64GB的内存。我们来看一下这个类是做什么的：

// 代码中不相关的部分做了删减
class NioClientSocketPipelineSink extends AbstractChannelSink {

    final Executor bossExecutor;

    private final Boss[] bosses;
    private final NioWorker[] workers;

    private final AtomicInteger bossIndex = new AtomicInteger();
    private final AtomicInteger workerIndex = new AtomicInteger();

    // 这是外部能影响队列registerTaskQueue的唯一入口
    public void eventSunk( ChannelPipeline pipeline, ChannelEvent e) throws Exception {
        if (e instanceof ChannelStateEvent) {

            ChannelState state = event.getState();
            Object value = event.getValue();

            switch (state) {
            case CONNECTED:
                if (value != null) {
                    // 连接到客户端通道
                    connect(channel, future, (SocketAddress) value);
                } else {
                    channel.worker.close(channel, future);
                }
                break;
        } else if (e instanceof MessageEvent) {}
    }


    private void connect(  final NioClientSocketChannel channel, final ChannelFuture cf, SocketAddress remoteAddress) {
        try {
            if (channel.socket.connect(remoteAddress)) {
                channel.worker.register(channel, cf);
            } else {
                // 通道是非阻塞模式，因此会走到这个分支
                nextBoss().register(channel);
            }

        } catch (Throwable t) {}
    }
    Boss nextBoss() {
        return bosses[Math.abs( bossIndex.getAndIncrement() % bosses.length)];
    }


    private final class Boss implements Runnable {

        private final AtomicBoolean wakenUp = new AtomicBoolean();
        private final Object startStopLock = new Object();
        private final Queue<Runnable> registerTaskQueue = new LinkedTransferQueue<Runnable>();

        // 这个方法直接导致registerTaskQueue增大
        void register(NioClientSocketChannel channel) {
            Runnable registerTask = new RegisterTask(this, channel);

            synchronized (startStopLock) {
                // 如果尚未启动，则使用Executor启动Client Boss线程
                // 每当有新的连接请求到达，都会尝试启动Client Boss线程
                if (!started) {
                    DeadLockProofWorker.start(
                                bossExecutor,
                                new ThreadRenamingRunnable(
                                        this, "New I/O client boss #" + id + '-' + subId));
                }
                // 添加一个RegisterTask
                boolean offered = registerTaskQueue.offer(registerTask);
            }

            if (wakenUp.compareAndSet(false, true)) {
                // 唤醒选择器
                selector.wakeup();
            }
        }

        public void run() {
            Selector selector = this.selector;
            long lastConnectTimeoutCheckTimeNanos = System.nanoTime();
            for (;;) {
                wakenUp.set(false);

                try {
                    // 最多阻塞500ms
                    int selectedKeyCount = selector.select(500);
                    if (wakenUp.get()) {
                        selector.wakeup();
                    }
                    // 消费registerTaskQueue队列
                    processRegisterTaskQueue();

                    
                    if (selector.keys().isEmpty()) {
                        if (shutdown ||
                            bossExecutor instanceof ExecutorService && ((ExecutorService) bossExecutor).isShutdown()) {

                            synchronized (startStopLock) {
                                if (registerTaskQueue.isEmpty() && selector.keys().isEmpty()) {
                                    // 标记Client Boss线程为停止状态，下次再有连接请求到达，会再次启动
                                    started = false;
                                    try {
                                        selector.close();
                                    } catch (IOException e) {
                                        logger.warn(
                                                "Failed to close a selector.", e);
                                    } finally {
                                        this.selector = null;
                                    }
                                    // 退出条件
                                    break;
                                } else {
                                    shutdown = false;
                                }
                            }
                        } else {
                            shutdown = true;
                        }
                    } else {
                        shutdown = false;
                    }

                } catch (Throwable t) {}
            }
        }

        private void processRegisterTaskQueue() {
            for (;;) {
                final Runnable task = registerTaskQueue.poll();
                if (task == null) {
                    break;
                }

                task.run();
            }
        }

    private static final class RegisterTask implements Runnable {

        RegisterTask(Boss boss, NioClientSocketChannel channel) {
            this.boss = boss;
            this.channel = channel;
        }

        public void run() {
            try {
                // 在指定的选择器上注册通道的事件
                channel.socket.register( boss.selector, SelectionKey.OP_CONNECT, channel);
            } catch (ClosedChannelException e) {
                channel.worker.close(channel, succeededFuture(channel));
            }

            int connectTimeout = channel.getConfig().getConnectTimeoutMillis();
            if (connectTimeout > 0) {
                channel.connectDeadlineNanos = System.nanoTime() + connectTimeout * 1000000L;
            }
        }
    }
}

可以看到：

1. 每当有新的连接请求时，都会调用Boss.register，从而唤醒Boss.run线程
2. 一旦Boss.run线程线程启动，它就会消费掉所有堆积的registerTaskQueue元素

也就是说，正常情况下，registerTaskQueue队列不应该出现堆积的。由于发现问题时没有开启Dubbo或Netty的日志，准备等待下次问题重现后继续深入分析。

The post 使用Eclipse Memory Analyzer分析JVM堆Dump appeared first on 绿色记忆.

从用户角度来看，Web应用内存问题可以表现为以下几种形式：

这三种表现形式并不是孤立的。缓慢的内存泄漏最终会导致内存的大量使用，内存泄漏/暴涨会导致GC消耗更多的时间以及更频繁的运作。

本文主要探讨内存泄漏问题。

所谓内存泄漏，是指应用程序不再需要的内存，由于某种原因没有归还给操作系统。

JavaScript是一种基于垃圾回收机制（GCed）的语言，垃圾回收器可以辅助内存的回收：它检查某一片内存是否从应用其它部分可达，以确定该内存是否可以被安全回收。GCed语言中的内存泄漏主要由多余引用（unwanted references）导致。所谓多余引用，是从活动GC Root直接/间接指向一片不再需要的内存的引用。

尽管现代JS引擎能够在一些情况下自动执行垃圾回收，由于代码逻辑错误导致的内存泄漏仍然存在，特别是在单页面应用/Ajax成为主流的今天，长时间运行的Web页面往往因此渐渐变慢甚至崩溃。

“多余引用”在Web应用的场景下可以进一步的细分。下表列出常见的情形：

var

window

null

setInterval()

var resource = getData();
setInterval(function() {
    var node = document.getElementById('node');
    // 某个时间点之后node可能不再存在，因此该定时器什么也不做
    if(node) node.innerHTML = JSON.stringify(someResource));
}, 1000);
// 但是，定时器函数没有被销毁，而它引用resource这个数据（可能是一大片内存），这就造成了潜在的内存泄漏

// 因此，应当记住，定时器不需要的时候，手工销毁它
var handle = setInterval(NoOp);
clearInterval(handle); //执行清理

var e = document.getElementById( 'button' );
function clickHandler( event ) {
    e.innerHtml = 'text';
}
e.addEventListener( 'click', clickHandler );

// 先移除观察者
e.removeEventListener( 'click', clickHandler );
// 然后再移除DOM节点
e.parentNode.removeChild( e );

按快捷键Shift + ESC，可以打开Chrome任务管理器（Task Manager）。通过持续的观察任务管理器，你可以查看每个页面的内存用量的变化，进而获得可能的内存泄漏提示。常用输出列如下：

Chrome任务管理器只能给出一些粗略的提示。实际工作中我们通常使用Chrome Developer Tools来发现并定位内存泄漏。Dev Tools由9个面板组成，其中Timeline、Profiles有助于内存分析。

通过该面板可以直观的看到不正常的内存使用，你可以使用它获得对问题的初步认识。

切换到Timeline面板，然后勾选Memory，点击可以启动时间线记录，点击弹窗的Finish按钮则停止记录。注意，在启动、停止前，你应该点击执行强制垃圾回收。时间线记录示例如下：

在这个示例中，随着时间的推进，周期性的内存用量跳涨而之后不能收缩到原有水平、Nodes、Listeners计数的持续增加，这些都是明显的内存泄漏信号。

该面板是定位内存泄漏的关键，使用它你可以：

1. 获取内存的快照，分析JS对象、DOM节点如何占用内存。支持比对两个快照，发现内存使用情况的变化
2. 录制内存分配随时间的变化，可用于隔离出内存泄漏。

切换到Profiles面板，点选Take Heap Snapsot，然后点击Task Snapshot按钮，即可获得一张实时的堆快照。注意：获取快照前，会自动执行垃圾回收。快照示例如下：

点击左上角的下拉菜单，可以在几个视图之间切换：

定位内存泄漏需要一些技巧，但是一般都是从快照的Summary视图开始分析。一个常用的工作流程是所谓三快照（three snapshot）技术：

1. 执行必要的预热操作，确保那些需要长期驻留的对象初始化完毕
2. 获取一个快照
3. 执行可能导致内存泄漏的操作
4. 获取一个快照
5. 再次执行你觉得可能导致内存泄漏的操作
6. 再次获取一个快照
7. 选择最后一个快照，在列表顶部选择：
8. 这样，你就可以看到那些在快照1-快照2这个时间段内分配的，到目前为止仍然驻留在内存中的那些对象。这些对象可能是导致内存泄漏的对象
9. 展开对象类型节点，选中一个对象，这时下面的Retainers面板会显示该对象的驻留树——即该对象是如何被其它对象引用的

三快照技术有效的依据是：在应用经过预热（warm-up）阶段之后，分配的新对象一般都是由（定时器/用户）操作触发的、朝生暮死的对象。这些本该朝生暮死的对象如果一直驻留，意味着存在内存泄漏。

切换到Profiles面板，点选Record Heap Allocations，然后点击Start按钮，即可录制内存分配沿着时间线的变化情况——堆分配时间线（Heap Timelines）。点击按钮可以停止录制，并生成一个快照。

注意：时间线对象列表子面板，仅仅包含在时间线结尾时刻仍然存活的对象。

堆分配时间线的优势在于，你可以任意选择大小的时间区间，查看区间内发生的内存分配，有利于隔离出内存泄漏。时间线示例如下：

截图中，最上面的是时间轴，每一个蓝色/灰色的柱子表示一系列相关的内存分配。柱子的高度表示分配内存的大小，蓝色部分表示到结束录制的那个时间点为止，仍然驻留的内存大小，灰色部分表示已经被回收的内存大小。

中间的对象列表面板，显示选中的时间区间内的内存分配，按类型分组。展开一个类型节点，可以看到仍然存活的实例。

下面是Retainers面板，可以显示某个存活实例的引用链。例如上图中当前选中的字符串实例被window.arr[18]引用。

在对象列表子面板的Constructor列、Retainers子面板的Object列，都有以构造器表示的对象类型，这些类型的说明如下：

这里我们举一个利用堆快照剖析DOM树泄漏的例子。考虑下面的代码：

<button id="btn">Create</button>
<script type="text/javascript">
    var detachedTree;
    document.getElementById('btn').addEventListener('click', function () {
        var div = document.createElement('div');
        for (var i = 0; i < 10; i++) {
            var span = document.createElement('span');
            div.appendChild(span);
        }
        detachedTree = div;
    });
</script>

点击Create按钮后，监听器会创建一个div元素，其内部包含10个span元素。由于div元素尚未添加到页面DOM树中且被全局变量detachedTree引用，因此它属于Detached节点。

我们在点击Create按钮后获取一个快照，在Summary视图的Class filter中搜索Detached，可以看到如下结果：

在对象列表面板中，黄色背景表示Detached DOM子树的根节点，这类节点被JavaScript代码直接引用；红色背景（非直接引用）则表示Detached DOM子树的分支/叶子节点，没有被JavaScript代码直接引用。

在上图中点选一个对象，下面的Retainers面板会显示该对象的引用链：

可以看到，引用链从直接引用对象的变量开始，逆向追溯。引用链上的每个元素使用如下语法描述：

# name 可以是对象属性名称、native（表示该引用是本地代码）、[数组索引]
# ObjectType 指明对象的类型
# @id 指明对象的唯一标识
name1 in ObjectType1 @id1
  name2 in ObjectType2 @id2
  # ObjectType2类型的对象id2的name2属性指向ObjectType1类型的对象id1

 对于上图左右两个引用链，应当这样解读：

1. 对于HTMLDivElement，window的detachedTree属性（就是我们声明的全局变量）直接引用之
2. 对于HTMLSpanElement，window的detachedTree属性引用了HTMLDivElement ⇨ HTMLDivElement的native属性引用了DOM子树数组  ⇨ DOM子树数组的第1个元素引用了HTMLSpanElement

在追踪DOM树泄漏时，可以不关注红色背景节点，而仅追踪黄色背景节点被哪些JavaScript变量使用，然后清除多余引用。

“机房实景”是某系统中的一个模块，它以图形化的方式展示数据中心的各种设备：包括服务器、网络设备、监控设备。设备及其状态基于位图、矢量图、文本等形式展示。如果数据中心规模较大，可以为其设计多张实景图，并在这些实景图之间轮巡（即定期切换显示），以了解数据中心的网络和环境状态。

从技术角度来说，该模块以Draw 2D Touch 5.3.4为基础，而后者的底层框架则是Raphael以及jQuery。

在测试阶段，我们发现长时间运行机房实景模块后，浏览器占用的内存不断上涨。特别是启用实景图轮询的情况下，数小时后内存占用超过1G，最终浏览器会崩溃。

通过Chrome任务管理器查看：

1. 刚进入机房实景模块时：Native内存占用80MB，JS内存占用20MB
2. 10分钟后，强制GC后：Native内存占用110MB，JS内存占用45MB
3. 20分钟后，强制GC后：Native内存占用130MB，JS内存占用64MB

这组数据说明机房实景模块很可能存在内存泄漏问题。

重新进入机房实景模块，等待模块预热完毕（机房实景模块在启动时需要加载所有实景图的UI元素数据，并在内存中创建相应的数据结构），启用轮巡，在Profiles面板中启动堆时间线记录，持续十分钟，执行GC后停止记录，结果如下：

可以看到，大尺寸内存分配，周期非常稳定，这恰恰是轮巡切换实景图的周期。这些内存分配的大部分（蓝色）始终无法回收，说明实景图切换会导致相当严重的内存泄漏。为何实景图切换会导致内存泄漏？这很可能是大量界面元素的复杂引用关系没有被正确的清理，后面我们会证实这一点。

重新进入机房实景模块，等待模块预热完毕，禁用轮巡， 再次启动堆时间线记录，持续十分钟，执行GC后停止记录，结果如下：

可以看到，在禁用轮巡的情况下，只有2分钟左右存在一次可能的JavaScript内存泄漏，其它时间分配的内存都大多数被回收了（灰色）。

首先看看禁用轮巡时，那唯一高耸的蓝色柱子是怎么回事，缩小区间，查看对象列表面板：

这个所谓的system类型，是浏览器内部行为导致的内存分配，和应用程序没有直接关系。因此我们可以认为它不是内存泄漏，并进一步推断：禁用轮巡时机房实景模块没有明显的JavaScript内存泄漏。

我们着重分析启用轮巡时那一系列蓝色柱子，这些柱子高度常常以M计，再多的系统内存也经不起这样的泄漏。

缩小区间，选择第一个柱子，设置对象列表面板按Retained Size降序排列，Retainers面板按Distance排列，结果如下：

这样排序的根据是：

1. Retained Size大的对象，可能造成的内存泄漏量也大
2. 离目标对象距离一样的多个引用引用，其Distance值越小（即离GC Root越近）越可能是内存泄漏的根源。上图的cache、159两个引用前者更有可能导致了内存泄漏

注意第一个驻留对象Object@1483747，其导致1870.752KB的内存无法释放；第二个对象Object@1483541，其导致1870.556KB内存无法释放。然后，所有Object总计才导致1873.092KB内存无法释放，这是怎么回事呢？

其实展开Object@1483747你就可以看到原因何在——Object@1483747的events字段恰恰引用了Object@1483541：

在任何时候，你都可以按Esc调出Console。选中对象列表面板或者Retainers面板中一条数据后，在Console中输入

$0

我们选取Retained Size较大的一个Object进行分析，显示其详细信息：

可以看到这是一个简单对象，有events、handle两个属性。你会注意到events属性的Retained Size远远大于events的子属性Retained之和，这一现象我也没弄清楚是怎么回事。

查看Retainers面板，可以发现jQuery.cache引用了Object@8364337，而jQuery.cache导致的内存驻留接近28M。看起来这个cache在占据大量内存，它会不会随着时间不停变大呢？继续启用轮巡运行机房实景模块15分钟，证实了这一猜测，cache的Retained Size膨胀到120MB：

上节我们已经确认jQuery.cache存在大量的内存泄漏，那么这个cache是做什么用的呢，为何会无限制的膨胀呢？

我们看看Object@8364337是如何分配，并加入到cache中的，切换Retainers到Allocation stack，查看该对象被创建时的调用栈：

（注意：默认不会录制内存分配时的栈信息，需要在开发者工具设置 ⇨ General ⇨ Profiler中启用。）

有了这个调用栈，即使你不熟悉实景图模块，也能够下手进行调试了。通过单步跟踪，发现大概的程序逻辑如下：

1. Ext.define.onTick其实一个定时器，每过一定时间它就会调用mm.takeTurnTask.run()方法，即执行轮巡，切换实景图。切换是通过调用MapManager.switchTo()实现的
2. Ext.define.switchTo：轮巡定时器触发，切换实景图
   

   Ext.define( 'kssi.map.run.MapManager', {
       switchTo: function ( mapId ) {
           var me = this;
           var curMap = this.getCurMap();
           // 只在目标实景图不是当前实景图的情况下才切换
           if ( curMap && mapId == curMap.getId() ) {
               return;
           }
           me.show( mapId );
       },
       show: function ( mapId ) {
           var me = this;
           // 缓存当前实景图
           me.cache( me.getCurMap() );
           // 创建新的需要切换到的实景图
           me.createMapComp( mapId );  // ⇨
           me.updateMapView();
       }
   });

3. Ext.define.createMapComp：创建新的实景图UI包装器组件，在创建前总是会尝试移除原先的组件：
   

   Ext.define( 'kssi.map.run.MapManager', {
       createMapComp: function ( mapId ) {
           var me = this;
           if ( me.currMapComp ) {
               // 创建新实景图之前，移除老的实景图
               me.mapCntr.remove( me.currMapComp, true );
               me.currMapComp = null;
           }
           // 创建新的实景图并添加到容器
           var mapComp = Ext.create( 'kssi.map.design.MapComponent', mapData );
           me.afterMapCompCreated( mapComp );
           me.mapCntr.add( mapComp );
       }
   });

4. Map$d2d是实景图UI组件，基于Draw2D的实现。在其重绘（repaint）函数中，会创建Draw2D画布对象，并调用其初始化方法：
   

   Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
       extend: 'com.kingsmartsi.secmon.map.domain.Map',
       canvas: null,
       repaint: function () {
           var map = this;
           var items = map.painted ? map.marshalItems() : map.items;
           map.clear();
           map.dom.innerHTML = '';
           // 就是把当前ExtJS对应的DOM元素传递给Draw2d画布的构造函数
           map.canvas = new draw2d.Canvas( map.dom.id );  // ⇨ 
       }
   }

5. Draw2D画布类遵循Class.js的类继承模拟机制，其构造函数的职责实质上由初始化方法init()承担
   

   (function () {
       // 声明一个全局变量
       this.Class = function () {
       };
   
       Class.extend = function ( prop ) {
           // ...
           function Class() {
               // 实际的构造了逻辑是委托给init方法完成的
              if ( !initializing && this.init )
                   this.init.apply( this, arguments );
           }
           // ...
           return Class;
       };
   })();

    因此，repaint()传递给new draw2d.Canvas()的map.dom.id，会直接转给init()，作为画布的容器元素

   draw2d.Canvas = Class.extend(
       {
           init: function ( canvasId, width, height ) {
   
               this.canvasId = canvasId;
               // Map$d2d组件对应的DOM元素、Draw2D画布的html属性指向的DOM元素是同一个，只不过后者是一个jQuery元素封装
               this.html = $( "#" + canvasId );  // canvasId  ==  Map$d2d.dom.id 
               // 构建Raphael画布对象
               if ( typeof height !== "undefined" ) {
                   this.paper = Raphael( canvasId, width, height );
               }
               else {
                   this.paper = Raphael( canvasId, this.getWidth(), this.getHeight() );
               }
               // 对容器元素进行事件绑定
               this.html.bind( "mouseup touchend", function ( event ) { // ⇨
               } );
               // bind()方法只是on()的一个代理，可以认为两者一回事
               this.html.on( "dblclick", function ( event ) { // ⇨
               } );
               // 更多事件绑定...
           }
   }

   可以看到Draw2D画布在初始化时，调用jQuery的bind/on进行事件绑定。我们开始接近jQuery.cache膨胀的源头了

6. jQuery在进行事件绑定时，实际上是调用jQuery.event对象的add()方法：
   

   jQuery.fn.extend(
           {
               on: function ( types, selector, data, fn, /*INTERNAL*/ one ) {
                   // 遍历jQuery元素集合（这里只有一个id为canvasId的DIV元素），分别进行添加事件
                   return this.each( function () {
                       jQuery.event.add( this, types, fn, data, selector ); // ⇨
                   } );
               }
           }
   );

7. jQuery.event.add在一开始就会调用_data()方法：
   

   jQuery.event = {
       add: function( elem, types, handler, data, selector ) {
           // 这个_data()其实是从缓存中拿数据，下面可以看到这一点
           var elemData = jQuery._data( elem );  // ⇨ 
           if ( !elemData ) return;
       }
   };
   
   jQuery.extend({
       _data: function( elem, name, data ) {
           return internalData( elem, name, data, true );  // ⇨ 
       }
   });

8. 而_data()则是internalData的简单代理，后者会初始化元素缓存：
   

   function internalData( elem, name, data, pvt /* Internal Use Only */ ) {
       // 对于元素节点，使用jQuery.cache，也就是就是我们的泄漏对象
       var cache = isNode ? jQuery.cache : elem;
       // 分配缓存key
       if ( !id ) {
           // Only DOM nodes need a new unique ID for each element since their data
           // ends up in the global cache
           if ( isNode ) {
               id = elem[ internalKey ] = core_deletedIds.pop() || jQuery.guid++;
           }
           else {
               id = internalKey;
           }
       }
       // 如果尚未缓存，为元素建立缓存条目
       if ( !cache[ id ] ) {
           // Avoid exposing jQuery metadata on plain JS objects when the object
           // is serialized using JSON.stringify
           cache[ id ] = isNode ? {} : { toJSON: jQuery.noop };
       }
       thisCache = cache[ id ];
       // 缓存一条数据，以name为key，data为value
       if ( data !== undefined ) {
           thisCache[ jQuery.camelCase( name ) ] = data;
       }
       // ...
       return ret;
   }

从上面的分析可以看到，通过jQuery来注册事件监听器时，会创建目标元素的缓存，从而导致jQuery.cache膨胀。

jQuery的设计中，必然包含了控制jQuery.cache大小的合理逻辑，否则缓存可能会不断膨胀，最终导致内存耗尽。

很多缓存系统使用注入LRU之类的算法，来限制缓存的大小，jQuery.cache好像没有这样设计。

既然jQuery.cache是关于元素的缓存，那么元素销毁后，其缓存条目理当一并销毁。如果这一设想成立，你必须让jQuery知道你销毁了元素，这样jQuery才有机会删除缓存条目（缓存属于jQuery内部实现）。

我们先从代码中寻找删除jQuery.cache条目的逻辑。直接在jquery-1.10.2.js中搜索“jQuery.cache”，匹配结果只有4条，很容易找到清理缓存条目的函数：

function internalRemoveData( elem, name, pvt ) {
	if ( !jQuery.acceptData( elem ) ) {
		return;
	}
	var thisCache, i,
		isNode = elem.nodeType, //元素1，文本3，注释8，文档9，文档类型10，文档片段11
		cache = isNode ? jQuery.cache : elem,
		id = isNode ? elem[ jQuery.expando ] : jQuery.expando;

	// 如果缓存条目不存在，直接返回
	if ( !cache[ id ] ) {
		return;
	}

	if ( name ) {
	    // 获得当前元素的缓存对象
		thisCache = pvt ? cache[ id ] : cache[ id ].data;

		if ( thisCache ) {
			// 把name转换为缓存key的数组
			i = name.length;
			while ( i-- ) {
				// 删除name中所有key对应的缓存数据
				delete thisCache[ name[i] ];
			}
			// 如果缓存条目中还有数据，不销毁缓存条目
                        // isEmptyDataObject：data属性不影响为空判断
                        // isEmptyObject：必须真正的没有任何属性
			if ( pvt ? !isEmptyDataObject(thisCache) : !jQuery.isEmptyObject(thisCache) ) {
				return;
			}
		}
	}

	// 销毁缓存条目
	if ( isNode ) {
		jQuery.cleanData( [ elem ], true );  // ⇨ 
	} else if ( jQuery.support.deleteExpando || cache != cache.window ) {
		delete cache[ id ];
	} else {
		cache[ id ] = null;
	}
}

如果入参elem是DOM节点，则调用cleanData()执行复杂的处理逻辑；否则，仅仅将缓存条目从jQuery.cache中移除

jQuery.extend({
        cleanData: function (elems, /* internal */ acceptData) {
            var elem, type, id, data,
                i = 0,
                internalKey = jQuery.expando,
                cache = jQuery.cache,
                deleteExpando = jQuery.support.deleteExpando,
                special = jQuery.event.special;
            //在这里，elems必然是jQuery元素集合对象，遍历
            for (; (elem = elems[i]) != null; i++) {
                // 如果支持缓存
                if (acceptData || jQuery.acceptData(elem)) {

                    id = elem[internalKey]; // 缓存条目键
                    data = id && cache[id]; // 缓存条目值

                    if (data) {
                        // 移除事件处理函数
                        if (data.events) {
                            for (type in data.events) {
                                if (special[type]) {
                                    jQuery.event.remove(elem, type);
                                } else {
                                    jQuery.removeEvent(elem, type, data.handle);
                                }
                            }
                        }

                        if (cache[id]) {
                            // 从jQuery.cache中删除该缓存条目
                            delete cache[id];
                            if (deleteExpando) {
                                delete elem[internalKey];
                            } else if (typeof elem.removeAttribute !== core_strundefined) {
                                elem.removeAttribute(internalKey);
                            } else {
                                elem[internalKey] = null;
                            }
                            core_deletedIds.push(id);
                        }
                    }
                }
            }
        }
});

那么，哪些函数调用此函数呢？直接调用它的函数有两个：

jQuery.extend({
    cache: {},
    removeData: function (elem, name) {
        return internalRemoveData(elem, name);
    },
    _removeData: function (elem, name) {
        return internalRemoveData(elem, name, true);
    }
});

对于第二个函数，存在以下调用链：jQuery.off()  ⇨ jQuery.event.remove()  ⇨ jQuery._removeData()。因此，解除注册元素上的事件处理器，可能会让元素缓存条目被清理。

在上面的分析中，我们知道internalRemoveData()可能调用cleanData()来清理节点的缓存数据，那么还有其它函数调用cleanData()么？搜索发现，下面的方法也会调用它：

jQuery.fn.extend( {
    // 移除匹配的元素
    remove: function ( selector, keepData ) {
        var elem,
            elems = selector ? jQuery.filter( selector, this ) : this,
            i = 0;
        for ( ; (elem = elems[ i ]) != null; i++ ) {

            if ( !keepData && elem.nodeType === 1 ) {
                jQuery.cleanData( getAll( elem ) );
            }
        }

        return this;
    },
    // 清空子节点
    empty: function () {
        var elem,
            i = 0;

        for ( ; (elem = this[ i ]) != null; i++ ) {
            // Remove element nodes and prevent memory leaks
            if ( elem.nodeType === 1 ) {
                jQuery.cleanData( getAll( elem, false ) );
            }
        }
        return this;
    },
} );

小结一下：

1. 函数internalRemoveData负责：
   1. 从缓存条目中删除指定的键值对
   2. 当缓存条目“为空”时，清理DOM节点的事件监听器数据，并且从jQuery.cache中移除缓存条目
2. 方法cleanData负责：清理元素的缓存数据
3. 当通过jQuery API移除元素时，它的位于jQuery.cache中的缓存条目被删除
4. 当通过jQuery API移除元素的事件监听器时，它位于jQuery.cache中缓存条目的数据项会被删除，如果缓存条目在此数据项删除后变“空”，则删除缓存条目

因此：由于你通过jQuery API操控DOM，而导致其驻留jQuery.cache后，必须通过jQuery的API——例如remove()、off()进行清理操作，才能确保缓存条目在不需要时顺利移除。

通过上一节的分析，我们已经确信：必须通过jQuery的API进行清理操作，才能避免jQuery.cache的内存泄漏。实景图模块并没有直接使用jQuery，直接使用它的是Draw2D。那么，后者是否暴露了适当的接口供上层组件执行清理？

我们看一下实景图模块的清理逻辑。在前面的分析中我们已经看到，轮巡（switchTo）时，原有实景图UI包装器组件会被删除：

switchTo: function ( mapId ) {
    var me = this;
    me.show( mapId );
}
show: function ( mapId ) {
    var me = this;
    //首先缓存当前实景图UI包装器组件的数据内容
    me.cache( me.getCurMap() );
    //然后创新新实景图
    me.createMapComp( mapId );
    me.updateMapView();
}
createMapComp: function ( mapId ) {
    var me = this;
    if ( me.currMapComp ) {
        // 移除老的实景图
        me.mapCntr.remove( me.currMapComp, true );
        me.currMapComp = null;
    }
    var mapData = me.mapDataCache[ mapId ];
    // 创建新实景图并添加到容器中
    var mapComp = Ext.create( 'kssi.map.design.MapComponent', mapData );
}

上面的调用ExtJS标准API：Container.remove()用来移除原有的实景图UI包装器组件，由于实景图组件被设置为autoDestory，因此它会被销毁。除了ExtJS组件标准的销毁逻辑以外。实景图模块还扩展了一些逻辑：

// 实景图UI包装器组件
Ext.define( 'kssi.map.design.MapComponent', {
    map : null ,  //Map$d2d
    // 扩展的逻辑
    onDestroy : function()
    {
        this.map.onDestroy();
    }
    // 销毁从这里开始，这个是ExtJS框架的逻辑，复制过来便于理解流传
    destory : function() {
        me.onDestroy();
        if (!me.preserveElOnDestroy) {
            me.el.remove(); // 移除DOM元素
        }
    }
} );
//实景图UI组件
Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
    canvas: null,
    // 扩展的逻辑
    onDestroy: function () {
        this.canvas.destroy();
        this.tip.close();
    }
}

到这里为止，我们可以确认：

1. Draw2D画布的目标元素，亦即ExtJS组件MapComponent对应的DOM元素，最终被（ExtJS API）销毁了。注意上一节我们的结论——必须通过jQuery API对操纵过的元素进行清理操作，因此这里的销毁肯定不能阻止jQuery.cache的泄漏
2. 在销毁上述DOM之前，实景图模块调用Draw2D画布的destroy()方法

这个destroy()方法应当是删除Draw2D画布的相关资源，我们看看它的代码：

draw2d.Canvas = Class.extend(
        destroy: function () {
            // 清空
            this.clear();
            // 解除document上的事件绑定
            $( document ).unbind( "keydown", this.keydownCallback );
            $( document ).unbind( "keyup", this.keyupCallback );
            this.eventSubscriptions = {};
            // 删除Raphael画布对象
            this.paper.remove();
        },
        // 清理画布上的Figure、Line等元素
        clear: function () {
            this.fireEvent( "clear" );
            var _this = this;
            // 移除所有线条
            this.lines.clone().each( function ( i, e ) {
                _this.remove( e );
            } );
            // 移除所有图形
            this.figures.clone().each( function ( i, e ) {
                _this.remove( e );
            } );
            // 重置实例变量
            this.zoomFactor = 1.0;
            this.selection.clear();
            // ...
            return this;
        }
    }
);

注意到没有？Draw2D的Canvas类在初始化时注册了很多事件监听器（this.html.on/bind调用），但是在上面的destroy()方法中：

1. 没有通过off()调用解除this.html的监听器绑定
2. 也没有通过remove()调用删除this.html元素

（为了防止代码分析存在遗漏，你可以在jQuery的internalRemoveData、cleanData函数上添加断点，然后再运行实景图模块，如果断点没有命中或者调用针对的元素不是this.html，则证明上述结论无误）

因此，jQuery.cache导致的内存泄漏发生了。

弄清楚来龙去脉，解决这个问题就非常简单了，只需要再Map$d2d的onDestroy()钩子中添加一行代码即可：

Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
    onDestroy: function () {
        this.canvas.destroy();
        // 解决jQuery.cache内存泄漏问题
        this.canvas.html.remove();
        this.tip.close();
    }
});

上节我们通过修改Draw2D的代码，处理了jQuery.cache泄漏问题，现在我们需要验证一下，问题是不是真正解决了。重新录制10分钟的堆时间线： 

和一开始的录制的时间线对比一下可以看到，我们解决jQuery.cache泄漏后，实景图整体内存消耗有了很大改善。 观察此图，我们可以看到：

1. 每个高柱子（都大于1.0MB线）都是在轮巡切换实景图时发生的内存分配
2. 总有4-5个蓝色高柱子，它们总是位于时间线的最右侧。这是个好现象，说明随着时间的推移，以前分配的内存大多被回收了
3. 仍然有少量内存过了很久都没有被回收，注意观察那些非常低矮的蓝色短柱

通过多次重新录制、查看，发现上面第3条提及的蓝色短柱是随机出现的，其Retained Size也主要由Chrome本身导致，因此不需要刻意去分析。

那么，大片的灰色区域中，是否存在“肉眼不可见”（量太少以至于画不出蓝色柱子）的内存泄漏呢？选定一个大范围的区间查看：

那些带括号的一般是JS引擎内部使用，可以不去考虑。因此可能属于内存泄漏的类型包括：constructor、Object、Array、HasListeners。我们分别展开这些类型的第一个对象实例，合并到一张图片中进行对照：

注意在这4张图片的Retainers子面板中出现的ext-com-1035，很明显，后3个对象分别是第1个对象的events、protoEl.classList、hasListeners属性。只要第1个对象被回收，其它3个对象自然会被回收。因此，我们只需要搞清楚第1个对象是什么，为什么一直驻留就可以了。

下面看看constructor对象的列表，注意那些Retained Size一样的对象，它们往往是基于同样的逻辑创建出来了，一般你只需要分析其中一个就可以了：

以constructor@2398693为例，它的引用链是：

window.Ext.ComponentMgr.all.map['ext-comp-1035']

Ext.define('Ext.AbstractComponent', {
    constructor : function(config) {
        // ...
        me.initComponent();
        // 在initComponent阶段之后，把自己注册到组件管理器
        Ext.ComponentManager.register(me);
    },
    destroy : function() {
        // ...
        Ext.ComponentManager.unregister(me);
    }
});

constructor@2398693一直没有解除注册，可能因为实景图模块没有适当的销毁它。 

下面看一下该对象的Allocation stack，看看是什么代码创建了constructor@2398693：

从栈顶向下跟踪，可以发现实景图UI组件创建了它：

Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
    constructor: function () {
        this.callParent( arguments );
        this.tip = Ext.create( 'Ext.tip.Tip', {
            cls: 'tooltip'
        } );
        return this;
    }
});

原来constructor@2398693是一个Tooltip，其实你随时可以通过鼠标悬停或

$0

我们顺便看看Map$d2d是怎样销毁这个Tooltip的：

Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
    onDestroy: function () {
        this.canvas.destroy();
        //解决jQuery.cache内存泄漏问题
        this.canvas.html.remove();
        this.tip.close();
    }
});

Map$d2d调用Toltip的close()方法（这个方法从Ext.panel.Panel继承得到）。这个方法的行为是什么呢？官方文档描述如下：

关闭面板，默认行为是将其从DOM中移除，删除面板对象及其所有子组件。注意：该方法的行为受到closeAction设置的影响，如果要明确的控制，请使用destroy()或者hide()方法

注意到了吗，close()不一定销毁组件，也可能是隐藏组件，这取决于closeAction设置，而Ext.tip.ToolTip的closeAction默认是hide，这个ExtJS官方文档说明的很清楚。所以实景图模块存在BUG。

要解决上面的泄漏很简单，要么在onDestroy()时明确调用destroy()，要么修改closeAction设置：

Ext.define( 'com.kingsmartsi.secmon.map.domain.Map$d2d', {
    constructor: function () {
        this.tip = Ext.create( 'Ext.tip.Tip', {
            cls: 'tooltip',
            closeAction: 'destroy'
        } );
    },
    onDestroy: function () {
        this.tip.destroy();
    },
});

回过头来想想，真的需要为每个实景图UI组件配备单独的Tooltip实例吗？完全没必要，ToolTip本身就倾向于全局使用。 

处理好Tooltip泄漏后，更新服务器，再次录制10分钟的时间线：

可以看到，驻留的对象都是Chrome引擎内部使用的对象。连续运行实景图轮巡一小时，通过Chrome任务管理器观察，内存也没有明显增长。我们认为不存在内存泄漏了。

上面的分析结束后，我们认为内存泄漏问题已经解决。

但是，实景图轮巡是需要支持无限时间连续运行的，所以我们还要进行长期稳定性测试。连续运行16小时后，实景图模块占用的内存从100MB增长到400MB左右。看来，还是存在内存泄漏——平均每小时泄漏18MB内存，只是由于垃圾回收机制的干扰，我们无法在短时间内直观的察觉。

这里，我们还是首先考虑通过时间线分析。不要刷新浏览器，录制一个时间线。

和上一个时间线一样，我们选取一大片区间，中间并没有可供分析的对象。是不是泄漏都是在时间线之前分配的呢？毕竟实景图模块在录制前已经连续运行16小时了。这里有个技巧：将区间起点拉到最左边，可以看到在录制时间线之前分配的那些对象：

看到没有，在这16小时内：Object导致116MB内存驻留；constructor导致97MB内存驻留；Array导致80MB内存驻留。虽然这些内存可能会有重合、这些对象也不一定都是内存泄漏，但是，内存泄漏的存在是无容置疑的——最初运行的1小时内，实景图模块总计占据的内存还不到100MB。

我们先看看Object，大概浏览一下前面的几十条，发现它们都是window.mapManager.mapDataCache：

也就是说，内存中存在多个实景图管理器（kssi.map.run.MapManager）对象（它与mapDataCache是1:1关系）。这是严重的编程错误，在实景图模块，实景图管理器是全局唯一的对象，绝不应该存在多个实例。

检查代码，发现创建实景图管理器的逻辑是存放在Ext.onReady()方法中的，这意味着在页面的生命周期中，实景图只会创建一次。那么时间线中的多个mapManager，该如何解释？

页面的生命周期中，实景图只会创建一次，这个推论没有问题。出现多个mapManager，是因为时间线跨越了页面的生命周期，说它跨越的依据是 in Window@后面的数字。看到了吗，左边9601而右边是17947。window的标识符都变了，说明页面刷新了。我们重新录制时间线、结合console.log可以证明这一点：

看到没有，在运行1小时后，出现大量内存分配，日志也显示mapManager被创建。到这里我们可以确信实景图模块有自动刷新的逻辑，搜索reload找到：

Ext.TaskManager.start( {
    run: function () {
        mm.cacheTransientState( true );
        window.location.reload();
    },
    interval: 3600 * 1000
} );

这段代码原本是用作临时解决内存泄漏的，而现在，解药却变成了毒药。这是为什么？

页面刷新后、页面内存被清空，整个时间线信息应该丢失才对。而我们的时间线完整的记录了多个window对象实例。这个现象可能的原因是，实景图是运行在iframe中的。top窗口一直没有刷新。你可以切换到Elements面板，搜索iframe发现：

<iframe src="/pems-web-manager/maprun/group" name="frame-frame" width="100%" height="100%" frameborder="0" id="ext-gen1114">
</iframe>

页面刷新后，其内存仍然不能销毁，唯一可解释的原因是：其它iframe或者top窗口的某个变量直接/间接引用该页面中的变量。

通过查看top窗口的脚本monitoring.js，我们看到其中大量的引用了子页面的mapManager。

由于“每小时刷新实景图页面”是以前解决内存泄漏的临时方案，现在已经不需要了，删除定时器代码即可。

关于如何发现、定位并解决内存泄漏，请参考下面的几条建议：

1. 不要猜测！去测试、去剖析
2. 再小的内存泄漏，经过足够长的时间后也会对应用稳定性和性能产生严重影响，因此不能放过
3. 尽早测试，特别是那些需要长时间运行的程序。随着程序规模的增长、新框架和新组件的引入，定位内存泄漏变得越来越困难
4. 通过堆时间线去定位、隔离出内存泄漏
5. 识别Chrome引擎随机性的内存分配，这些分配在对象列表中，其类型往往有括号包围
6. 记录Allocation stack，快速的跟踪什么代码创建了对象
7. 必要时，开启Debug进行单步跟踪，了解自己不熟悉的第三方框架的行为
8. 解决了一个内存泄漏后，最好重新录制堆时间线，因为其它对象的驻留可能也是由这个已解决的内存泄漏引起

The post 使用Chrome开发者工具分析内存泄漏 appeared first on 绿色记忆.

Oracle  Java Mission Control（以下称JMC）是一个集成到JVM（jdk7u40+）的性能剖析和诊断工具，相比起JProfiler之类的性能剖析工具，JMC更加简单易用，界面友好。

JMC使用了JVM内部特定的基于事件的接口，不同于一般性能剖析工具使用JVMPI/JVMTI方式实现。因此JMC几乎不会给应用造成额外的压力，可以用在负载很高的生产环境中：

1. JFR在默认设置continuous下运行几乎对性能没有影响
2. JFR在默认设置profiling下运行通常造成小于2%的性能下降

在JDK 7 Update 40及其以后的版本中已经集成了JMC（%JDK_HOME%\bin\jmc.exe），打开此程序，会发现它是一个典型的Eclipse RCP应用。本文简单的介绍如何使用JMC来监控、记录JVM的运行过程。

-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=7777
-Dcom.sun.management.jmxremote
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder

如果要在目标JVM上启动持续不断的黑匣子记录，并在JVM正常退出时Dump记录为文件，可以参考下面的脚本设置JVM参数：

for /f "tokens=1-3 delims=/ " %%a in ('date /t') do (set md=%%a-%%b-%%c)
for /f "tokens=1-3 delims=/:." %%a in ("%TIME%") do (set mt=%%a%%b%%c)
set CUR_TIME=%md%-%mt%

rem 启用黑匣子默认记录行为。官方文档注明dumponexitpath支持目录，但我在7u71版本下测试失败
set JAVA_OPTS=%JAVA_OPTS% -XX:FlightRecorderOptions=defaultrecording=true,disk=true,dumponexit=true,dumponexitpath=%LOG_DIR%\jfr\dump-on-exit-%CUR_TIME%.jfr,maxage=3600s,settings=%JRE_HOME%\lib\jfr\profile.jfc

配置并重启目标JVM后，打开JMC，点击 File - Connect... - Create New connection，参考下图设置，完毕后点击Test connection确认可以连通，最后点击Finish结束配置。

在左侧窗格JVM Browser视图中，双击刚刚创建的JMC连接，点击MBean Server，即可在右侧主窗体查看实时的JVM状态信息，供6个选项卡，下面依次描述。

包含JVM概要性的实时图表，包含3个面板：

以树形结构显示目标JVM支持的所有MBean列表和属性、操作集。

包含若干预定义的触发器，可以在特定条件下，执行预定义的动作。支持的触发器包括：

此外，任何MBean属性均可以作为触发器使用，中间件（例如Tomcat、Weblogic、ActiveMQ）都有自己的扩展。 双击触发器后，右侧即显示规则详情（Rule Details），可以定义触发的阈值（到达时，或者从异常值恢复时）、执行的动作，可用的动作包括：

所谓LiveSet，是指在一次垃圾回收之后，堆内存的占用比率，取值在0-1之间。

如果GC后，可用的内存空间不足，则LiveSet接近100%，这预示可能存在OOM风险。在生产环境下，我们可以监控LiveSet，并在其过大时，把堆内存映像Dump出来供后续分析。

触发器配置示例：

其中Condition面板：

1. Current Value为指标的当前值，当发生GC后，自动刷新
2. Max trigger value为触发器激活时的指标值
3. Sustained period，指标必须到达Max trigger value至少多长时间，触发器才可能激活
4. Limit period，连续两次激活触发器的最小间隔时间

其中Action面板：

1. Only live，如果勾选，仅仅GCRoot可达的对象才被Dump出来
2. hprof路径为服务器的路径

其中Constraints面板：可以指定此触发器在什么日期、什么时间段启用。

要分析内存映像，你可以使用如下命令启动一个Web UI：

jhat -port 7770 -J-Xmx4G default.hprof

显示JVM和系统的概要信息，包含3个面板：

1. 系统信息：例如OS类型、硬件架构、系统内存、JVM的PID、JVM版本、Classpath、JVM启动时间、JVM参数（Java Options）
2. JVM统计：例如已加载的类数量、已运行时间
3. 系统属性：显示JVM的系统属性

显示JVM内存占用情况，分为上下两个面板。

显示JVM线程活动情况，分为三个面板。

正如民航的黑匣子一样，JMC的这个功能，可以用于事后分析系统性能低下，甚至崩溃的原因。JMC支持两种方式来启动黑匣子记录：通过触发器自动启动， 或者在左侧面板，双击Flight Recorder，手工启动。手工启动可以参考下图设置：

其中：Time fixed recording表示记录定长时间，时间到达后，自动停止记录；Continuous recording表示进行持续不断的记录，直到JVM退出或者接收到停止指令，这种记录方式下可以随时进行dump操作。

虽然黑匣子在JVM本地记录数据，但不在Java堆中记录，因此它并不会影响内存特性和垃圾收集。

黑匣子录制完成后，会在你选择的目录中生成一个.jfr文件，该文件包含录制期间JVM中发生的各种事件。

黑匣子通过JVM内部API来收集数据，并存放在一个线程本地（thread-local）的缓冲中，并最终刷入全局内存缓冲（global in-memory buffer），内存缓冲中的数据，会被刷入磁盘，磁盘文件时经过压缩的。每个记录数据块，要么在内存中，要么在磁盘中，这意味着——进程被停止或者宕机时，部分数据会丢失，JVM崩溃会也可能导致一部分数据丢失。

可以配置黑匣子不使用磁盘空间，这种场景下，全局内存缓冲被循环使用，旧的数据自动丢弃。

在JMC界面上，点击 Windows - Flight Recording Template Manager，看到类似如下界面。可以导入、导出、编辑JFR的设置文件。

我们可以导入%JDK_HOME%\jre\lib\jfr下的两个自带模板：default.jfc（Continuous）、profile.jfc（Profiling）。这两个模板的对比如下：

利用诊断命令，可以通过脚本控制黑匣子的行为，命令的示例如下：

rem 获取进程号为5361的JVM关于JFR.start命令的帮助
jcmd 5361 help JFR.start

rem 检查进程的JFR运行状态
jcmd 7648 JFR.check
rem 输出如下。注意recording=0表示正在运行的记录的标识符，后续操作需要用到这个标识符
rem 7648:
rem Recording: recording=0 name="HotSpot default" maxage=1h (running)

rem 启动一个15分钟的黑匣子记录，延迟5分钟启动，使用JDK自带的默认设置（default.jfc），保存Dump文件到D盘
jcmd 7648 JFR.start name=SampleRcd delay=300 duration=900s filename=D:\temp\SampleRcd.jfr 
     \ settings=D:\JavaEE\jdk\x64\jre\lib\jfr\default.jfc

rem 相对路径取决于目标JVM
jcmd 1234 JFR.start delay=0s duration=${jfr_du}s name=$name filename=$PWD/$name.jfr settings=profile

rem 下面的脚本，可以用于定期进行记录，按记录时间保存为不同的文件
setlocal
set DUMP_DIR=D:\temp
set SERVICE_NAME=Tomcat7
set JAVA_HOME=D:\JavaEE\jdk\x64\1.7
pushd %JAVA_HOME%\bin
for /f "tokens=1-3 delims=/ " %%a in ('date /t') do (set md=%%a-%%b-%%c)
for /f "tokens=1-3 delims=/:." %%a in ("%TIME%") do (set mt=%%a%%b%%c)
set CUR_TIME=%md%-%mt%
for /F "tokens=1,3" %%a in ('sc queryex %SERVICE_NAME%') do (
    if "%%a" == "PID" set "JPID=%%b"
)

rem 启动飞行记录，如果目标JVM是以SYSTEM身份启动的NT Service，可以使用PSTools发起jcmd命令，否则会报错：insufficient memory or insufficient privileges to attach
rem psexec -s jcmd %JPID% JFR.start ...
jcmd %JPID% JFR.start name=rcd-%CUR_TIME% duration=900s compress=true filename=%DUMP_DIR%\rcd-%CUR_TIME%.jfr settings=%JAVA_HOME%\jre\lib\jfr\profile.jfc
popd
endlocal

rem 导出JFR的Dump文件
rem 如果目标JVM正在在运行持续不断的黑匣子记录，使用该命令，再结合定时任务机制，可以定期保存黑匣子记录的Dump文件
jcmd 7648 JFR.dump recording=0 filename=F:\temp\dump.jfr

打开黑匣子记录的.jfr文件，即可看到类似下面的界面：左侧是记录的不同视图，可以点击切换；右侧主面板，顶部是事件的时间轴，拖动滑块，可以改变聚焦的时间范围（勾选右边的同步选择可以在切换视图时保持聚集范围），底部有若干选项卡。

下面，按照视图分别描述。

包含4个选项卡：

可以看到聚焦时间范围内的实时仪表（堆占用、CPU占用、GC停顿时间），以及CPU、堆使用情况的曲线图。

可以看到JVM的一些基本信息，包括启动时间、JVM参数等。

可以看到JVM的系统属性列表

可以显示记录的事件的列表

包含6个选项卡

Memory Usage：可以显示聚焦时间范围内OS总内存、OS已使用内存、提交的堆、使用的堆的大小曲线图。

GC Configuration：显示简单的GC配置

GC Statistics：显示简单的GC统计，包括垃圾回收次数、停顿时间

上面的面板，包含4个选项卡：

Heap：堆的使用情况曲线，红色小柱形显示了GC停顿的持续时间（刻度在右边）

Reference Objects：包含软引用、弱引用、幻引用、一般引用的数量变化区域图

Failed Promotions：失败的晋升列表，所谓晋升是指：年轻代对象向年老代转移的GC动作，包含对象个数和大小等信息

Failed Evacuations：

下面的面板，左侧显示历次GC的列表，右侧显示单次GC的详细信息，如下：

General：显示GC类型、触发原因、ID、开始结束时间、暂停时间

GC Phase：GC每个步骤的开始和持续时间

Reference Objects：本次GC涉及的各类引用的数量

Heap：堆在GC前后的大小对比

Perm Gen：永久代在GC前后的大小对比

显示各代、各次GC所消耗的时间

显示GC的详细配置，包括GC基本配置、堆的配置、年轻代的配置

显示聚焦时间范围内的内存分配统计信息

General：在线程本地分配缓冲（TLAB）内、外（即Eden区域）中分配的对象个数、内存大小。面板下部是内存分配大小按时间的柱形图

Allocation in new TLAB：在TLAB中分配的内存，按对象类型、或者按执行分配的线程的占比饼图；Allocation Profile可以剖析分配内存热点所在的调用栈

Allocation outside TLAB：在Eden区域的内存分配情况，包含的子选项卡同上

示例：

在Allocation By Class选项卡中：

1. 上面板Allocation Pressure，按对象类型，显示内存占用最大的对象
2. 下面板Stack Trace，选中上面板的某个对象类型后，在此显示分配对象的调用栈。第一行为直接分配对象的代码

显示对象数量和内存占用的统计信息，包含上下两部分

上面的面板：显示占有堆内存百分比大于0.5%的类型的列表

下面的面板：显示增长数量最快的类型的列表

包含6个选项卡：

显示占用CPU时间最多的代码，分为上下两部分

上面的面板：显示CPU时间占用最多的包，包括列表和饼图

下面的面板：显示CPU占用最多的类，按占比降序排列

显示热点方法（CPU占用时间最多），按占比降序排列，点击左侧小箭头可以向下钻取（找到哪些代码调用了这个方法导致的热点）

类似于热点方法选项卡，但是会显示所有热点方法的完整调用栈

包含3个选项卡，显示异常（包括错误）的统计信息

Overview：显示异常和错误的总数、最频繁发生异常的调用栈

Exceptions、Error：单独显示异常或者错误的总数、频繁调用栈，注意，异常默认是不记录的

显示即时编译的次数、编译大小、失败的日志

显示按时间的类加载、卸载的数量曲线图

分为上下两部分：

上面的面板：显示OS、JVM的CPU占用率的按时间统计的区域图

下面的面板：显示守护线程、活动线程数量的曲线图

显示CPU占用最多的线程，及选中线程的热点方法，分为上下两部分

上面的面板：显示CPU占用最多的线程，按占比降序排列

下面的面板：显示上面板选中线程的热点方法、调用栈 

显示因为锁争用导致的线程阻塞的统计信息，分为3个选项卡：

Top Blocking Locks：发生阻塞最多的监视器（锁）对象的列表，包含了锁定次数、最长时间

Top Blocked Threads：因为等待锁被阻塞时间最长的线程的列表

Top Blocking Threads：因为占用锁导致其他线程等待时间最长的线程的列表

显示因为：Java线程休眠、监视器等待、Socket读取、监视器阻塞等原因导致的线程执行延迟的情况，包括延迟信息的列表和饼图，已经导致延迟的线程调用栈。延迟相关的事件包括：Java Thread Park（Waiting）、Java Monitor Wait（等待被唤醒）、Java Monitor  Blocked（积极进入同步区被阻塞）等。

包含定时捕获的JVM中所有线程的瞬时调用栈镜像

Lock Instances：监视器对象的列表，包含锁定次数、总计持续时间

Trace Tree：选中监视器对象的锁定调用栈，每个调用栈锁定的次数

Top Threads：占用监视器次数最多的线程列表

分为两个选项卡

File Overview：

File Reads and Writes：显示按时间读写文件字节数的曲线

File Read、File Write：显示针对具体文件的读写字节数、次数的列表

Socket Overview：

Socket Read and Writes：显示按时间读写Socket字节数的曲线

Socket  Read、Socket Writes：显示针对具体目标主机、端口读写字节数、次数的列表

按文件、线程、事件统计文件读操作的列表，以及每个文件读取按时间的变化、线程调用栈

按文件、线程、事件统计文件写操作的列表，以及每个文件写入按时间的变化、线程调用栈

按目标主机、线程、事件统计文Socket读操作的列表，以及每个Socket读取按时间的变化、线程调用栈

按目标主机、线程、事件统计文Socket写操作的列表，以及每个Socket写入按时间的变化、线程调用栈

显示黑匣子记录的事件的相关信息，左侧面板Event Types可以过滤关注的事件类型。总体来说，事件可以分为三类：持续事件（duration，持续一段时间，例如GC事件）；瞬时事件（instant，立即发生和结束，例如内存溢出）；样本事件（sample，通过定期采样获取，例如栈dump）。

Producers：显示事件生产者的列表，以及制造事件的占比饼图

Event Types：显示各类型事件持续总时间、次数，占比饼图

显示每一个事件的记录，按时间排列，为每个事件显示：开始时间、结束时间、持续时间、产生事件的线程

以时间轴的形式展示事件历史

以列表形式展示各线程产生事件的数量、持续时间

按产生事件持续时间长短，降序排列相关的调用栈

可以按单个事件类型进行简单的统计分析，支持不同的分组方式，支持总数、平均数、次数等指标，选中单个统计结果，可以显示调用栈。

The post 使用Oracle Java Mission Control监控JVM运行状态 appeared first on 绿色记忆.

该视图专注于对象的内存分配情况，包含以下选项卡：

All Objects	显示堆中实时的对象情况：显示某种类型（聚合级别可以是类、包等）对象的数量（Instance Count）、浅尺寸（Shallow size）关于浅尺寸的计算： 普通对象大小的计算不包括引用、类变量，由变量本身地址、基本类型的变量占用的内存等组成 数组整体计算，不分为单个元素计算大小/数量 注意，有些对象虽然没有引用，但是可能没被GC回收，可以手工Run GC 右击某一类型，可以转到Class Tracker或者Heaper Walker视图
Recorded Objects	显示已经进行记录的对象。与All Objects相比，可以查看对象分配调用树（Allocation Call Tree）、分配热点（Allocation Hot Sports）点击工具栏：Start Memory，可以录制对象分配
Allocation Call Tree	显示选中的、已录制对象类型的分配调用数，分析调用栈的哪些栈帧比较消耗资源。从线程执行开始处，一直追溯到对象被创建的地方，对象占用内存的大小被显示，效果如下图：
Allocation Hot Sports	显示选中的、已录制对象类型的分配热点：以创建对象的方法为根显示调用树，效果如下图：
Class Tracker	显示选中类型对象的实例个数的曲线图（按时间）

该视图用于静态分析堆快照，在生成快照之前，会进行一次Full GC。包含以下选项卡：

该视图用于分析方法的CPU占用时间，包括以下选项卡：

该视图用于分析线程的状态和历史分析、检测死锁，并可以获取线程快照，包含以下选项卡：

Thread History	线程状态时间线，可以选择显示活着的或者死去的线程 绿色：Runnable：表示线程可以接受CPU调度，但不一定正在占用CPU，和线程优先级、调度算法、系统负载有关 黄色：Waiting：表示线程正在睡眠（java.lang.Thread.Sleep），或者在监视器上等待（java.lang.Object.wait），前者不会放弃占有的监视器 红色：Blocked：表示线程被阻塞，正在积极尝试进入同步区 浅蓝色：Net I/O：线程正在等待网络操作的完成，监听Socket或者读写Socket时产生此状态 效果图如下：
Thread Monitor	显示线程的开始结束时间、父线程、状态等信息
Thread Dumps	获取线程快照，可以分析瞬时系统各线程的调用栈

该视图用于锁状态检测，包含以下选项卡：

该视图可以显示时间线上的系统宏观信息，包括以下选项卡：

可以使用多种探针来检测不同的应用领域，包括：JDBC、JPA/Hibernate、JNDI、JMS、Servlet、RMI、Socket、WebServices、Files等。

用于在特定条件下触发剖析动作
触发条件：方法被调用、堆使用阈值、CPU使用率阈值、内存溢出异常、定时器、虚拟机启动、虚拟机关闭等
剖析动作：启/停录制、调用跟踪、监视器跟踪，触发堆dump、线程dump，启/停探针录制，保存快照，保存HPROF快照，运行脚本等

使用场景：脚本启动剖析、定期快照保存、剖析远程服务器

java 
"-agentpath:D:\JavaEE\jprofiler\7.2.2\bin\windows-x64\jprofilerti.dll=offline,id=109,config=D:\JavaEE\Config\jprofiler-offline.xml"
"-Xbootclasspath/a:D:\JavaEE\jprofiler\7.2.2\\bin\agent.jar"
-classpath myapp.jar cc.gmem.demo.MyApp

The post JProfiler学习笔记 appeared first on 绿色记忆.