查看原文
其他

Linux命令拾遗-剖析工具

扣钉日记 扣钉日记 2022-11-27

原创:打码日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。

简介

这是Linux命令拾遗系列的第五篇,本篇主要介绍Linux中常用的线程与内存剖析工具,以及更高级的perf性能分析工具等。

本系列文章索引
Linux命令拾遗-入门篇
Linux命令拾遗-文本处理篇
Linux命令拾遗-软件资源观测
Linux命令拾遗-硬件资源观测

像vmstat,top等资源观测命令,只能观测到资源整体使用情况,以及在各进程/线程上的使用情况,但没法了解到进程/线程为什么会使用这么多资源?

这种情况下,可以通过剖析(profile)工具做进一步分析,如jstack,jmap,pstack,gcore,perf等。

jstack

jstack是JVM下的线程剖析工具,可以打印出当前时刻各线程的调用栈,这样就可以了解到jvm中各线程都在干什么了,如下:

$ jstack 3051
2021-11-07 21:55:06
Full thread dump OpenJDK 64-Bit Server VM (11.0.12+7 mixed mode):

Threads class SMR info:
_java_thread_list=0x00007f3380001f00, length=10, elements={
0x00007f33cc027800, 0x00007f33cc22f800, 0x00007f33cc233800, 0x00007f33cc24b800,
0x00007f33cc24d800, 0x00007f33cc24f800, 0x00007f33cc251800, 0x00007f33cc253800,
0x00007f33cc303000, 0x00007f3380001000
}

"main" 1 prio=5 os_prio=0 cpu=2188.06ms elapsed=1240974.04s tid=0x00007f33cc027800 nid=0xbec runnable  [0x00007f33d1b68000]
   java.lang.Thread.State: RUNNABLE
        at java.io.FileInputStream.readBytes(java.base@11.0.12/Native Method)
        at java.io.FileInputStream.read(java.base@11.0.12/FileInputStream.java:279)
        at java.io.BufferedInputStream.read1(java.base@11.0.12/BufferedInputStream.java:290)
        at java.io.BufferedInputStream.read(java.base@11.0.12/BufferedInputStream.java:351)
        - locked <0x00000007423a5ba8> (a java.io.BufferedInputStream)
        at sun.nio.cs.StreamDecoder.readBytes(java.base@11.0.12/StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(java.base@11.0.12/StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(java.base@11.0.12/StreamDecoder.java:178)
        - locked <0x0000000745ad1cf0> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(java.base@11.0.12/InputStreamReader.java:181)
        at java.io.Reader.read(java.base@11.0.12/Reader.java:189)
        at java.util.Scanner.readInput(java.base@11.0.12/Scanner.java:882)
        at java.util.Scanner.findWithinHorizon(java.base@11.0.12/Scanner.java:1796)
        at java.util.Scanner.nextLine(java.base@11.0.12/Scanner.java:1649)
        at com.example.clientserver.ClientServerApplication.getDemo(ClientServerApplication.java:57)
        at com.example.clientserver.ClientServerApplication.run(ClientServerApplication.java:40)
        at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:804)
        at org.springframework.boot.SpringApplication.callRunners(SpringApplication.java:788)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:333)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1309)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1298)
        at com.example.clientserver.ClientServerApplication.main(ClientServerApplication.java:27)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.12/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.12/NativeMethodAccessorImpl.java:62)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.12/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@11.0.12/Method.java:566)
        at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:107)
        at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
        at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)

"Reference Handler" 2 daemon prio=10 os_prio=0 cpu=2.76ms elapsed=1240973.97s tid=0x00007f33cc22f800 nid=0xbf3 waiting on condition  [0x00007f33a820a000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.ref.Reference.waitForReferencePendingList(java.base@11.0.12/Native Method)
        at java.lang.ref.Reference.processPendingReferences(java.base@11.0.12/Reference.java:241)
        at java.lang.ref.Reference$ReferenceHandler.run(java.base@11.0.12/Reference.java:213)

实例:找占用CPU较高问题代码

如果你发现你的java进程CPU占用一直都很高,可以用如下方法找到问题代码: 
1,找出占用cpu的线程号pid

# -H表示看线程,其中312是java进程的pid
$ top -H -p 312

2,转换线程号为16进制

# 其中62是从top中获取的高cpu的线程pid
printf "%x" 314
13a

3,获取进程中所有线程栈,提取对应高cpu线程栈

$ jstack 312 | awk -v RS= '/0x13a/'

通过这种方法,可以很容易找到类似大循环或死循环之类性能极差的代码。

实例:查看各线程数量

$ jstack 10235|grep -oP '"[^"]+"'|sed -E 's/[0-9]+/n/g'|sort|uniq -c|sort -nr
      8 "GC Thread#n"
      2 "Gn Conc#n"
      2 "Cn CompilerThreadn"
      1 "main"
      1 "VM Thread"
      1 "VM Periodic Task Thread"
      1 "Sweeper thread"
      1 "Signal Dispatcher"
      1 "Service Thread"
      1 "Reference Handler"
      1 "Gn Young RemSet Sampling"
      1 "Gn Refine#n"
      1 "Gn Main Marker"
      1 "Finalizer"
      1 "Common-Cleaner"
      1 "Attach Listener"

如上,通过uniq等统计jvm各线程数量,可用于快速确认业务线程池中线程数量是否正常。

jmap

jmap是JVM下的内存剖析工具,用来分析或导出JVM堆数据,如下:

# 查看对象分布直方图,其中3051是java进程的pid
$ jmap -histo:live 3051 | head -n20
 num      instances          bytes  class name (module)
-------------------------------------------------------
   1:         19462        1184576  [B (java.base@11.0.12)
   2:          3955         469920  java.lang.Class (java.base@11.0.12)
   3:         18032         432768  java.lang.String (java.base@11.0.12)
   4:         11672         373504  java.util.concurrent.ConcurrentHashMap$Node (java.base@11.0.12)
   5:          3131         198592  [Ljava.lang.Object; (java.base@11.0.12)
   6:          5708         182656  java.util.HashMap$Node (java.base@11.0.12)
   7:          1606         155728  [I (java.base@11.0.12)
   8:           160         133376  [Ljava.util.concurrent.ConcurrentHashMap$Node; (java.base@11.0.12)
   9:          1041         106328  [Ljava.util.HashMap$Node; (java.base@11.0.12)
  10:          6216          99456  java.lang.Object (java.base@11.0.12)
  11:          1477          70896  sun.util.locale.LocaleObjectCache$CacheEntry (java.base@11.0.12)
  12:          1403          56120  java.util.LinkedHashMap$Entry (java.base@11.0.12)
  13:          1322          52880  java.lang.ref.SoftReference (java.base@11.0.12)
  14:           583          51304  java.lang.reflect.Method (java.base@11.0.12)
  15:           999          47952  java.lang.invoke.MemberName (java.base@11.0.12)
  16:            29          42624  [C (java.base@11.0.12)
  17:           743          41608  java.util.LinkedHashMap (java.base@11.0.12)
  18:           877          35080  java.lang.invoke.MethodType (java.base@11.0.12)

也可以直接将整个堆内存转储为文件,如下:

$ jmap -dump:format=b,file=heap.hprof 3051
Heap dump file created

$ ls *.hprof
heap.hprof

堆转储文件是二进制文件,没法直接查看,一般是配合mat(Memory Analysis Tool)等堆可视化工具来进行分析,如下:

mat打开hprof文件后,会看下如下一个概要界面。

点击Histogram可以按类维度查询内存占用大小

点击Dominator Tree可以看到各对象总大小(Retained Heap,包含引用的子对象),以及所占内存比例,可以看到一个ArrayList对象占用99.31%,看来是个bug,找到创建ArrayList的代码,修改即可。

可以看到,使用jmap+mat很容易分析内存泄露bug,但需要注意的是,jmap执行时会让jvm暂停,对于高并发的服务,最好先将问题节点摘除流量后再操作。

另外,可以在jvm上添加参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dump/,使得在发生内存溢出时,自动生成堆转储文件到dump目录。

mat下载地址:http://www.eclipse.org/mat/

pstack

pstack是c/c++等原生程序的线程剖析工具,类似jstack,不过是面向原生程序的,用法如下:

$ pstack $pid

例如,mysql是用c/c++写的,当mysql运行hang住时,可以通过pstack来查看线程栈。
如下,执行一个update SQL卡住了,我们来分析分析为啥?
1,使用processlist找出问题SQL的线程id

mysql> select t.thread_id,t.thread_os_id,pl.* from information_schema.processlist pl 
 join performance_schema.threads t on pl.id = t.processlist_id;
+-----------+--------------+----+------+---------------------+------+---------+------+-----------+---------------------------------------------------------------------------------------------------------->
| thread_id | thread_os_id | ID | USER | HOST                | DB   | COMMAND | TIME | STATE     | INFO                                                                                                     >
+-----------+--------------+----+------+---------------------+------+---------+------+-----------+---------------------------------------------------------------------------------------------------------->
|        32 |         4850 |  7 | root | 10.142.72.126:34934 | NULL | Query   |    0 | executing | select t.thread_id,t.thread_os_id,pl.* from information_schema.processlist pl join performance_schema.thr>
|        33 |         5771 |  8 | root | 10.142.112.35:54795 | NULL | Sleep   |  488 |           | NULL                                                                                                     >
|        34 |         4849 |  9 | root | 10.142.112.35:54796 | demo | Sleep   |  442 |           | NULL                                                                                                     >
|        35 |         5185 | 10 | root | 10.142.112.35:54797 | demo | Query   |  403 | updating  | update order set status=1 where oid=1                                                                    >
|        37 |        28904 | 12 | root | 10.142.72.126:34936 | demo | Sleep   |  411 |           | NULL                                                                                                     >
+-----------+--------------+----+------+---------------------+------+---------+------+-----------+---------------------------------------------------------------------------------------------------------->
5 rows in set (0.00 sec)

可以看到,处理update SQL的线程的thread_os_id是5185
2,使用pstack获取线程栈

# 其中3287是mysqld进程的pid
$ pstack 3287 > mysqld_stack.log

3,在线程栈中找到卡住线程

$ cat mysqld_stack.log | awk -v RS= '$1 ~ /5185/'
Thread 33 (Thread 0x7fe3c05ea700 (LWP 5185)):
0  futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fe358025474) at ../sysdeps/nptl/futex-internal.h:183
1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7fe358025420, cond=0x7fe358025448) at pthread_cond_wait.c:508
2  __pthread_cond_wait (cond=0x7fe358025448, mutex=0x7fe358025420) at pthread_cond_wait.c:638
3  0x000055c1b85b55f8 in os_event::wait (this=0x7fe358025408) at /home/work/softwares/mysql-5.7.30/storage/innobase/os/os0event.cc:179
4  0x000055c1b85b4a24 in os_event::wait_low (this=0x7fe358025408, reset_sig_count=6) at /home/work/softwares/mysql-5.7.30/storage/innobase/os/os0event.cc:366
5  0x000055c1b85b51bc in os_event_wait_low (event=0x7fe358025408, reset_sig_count=0) at /home/work/softwares/mysql-5.7.30/storage/innobase/os/os0event.cc:611
6  0x000055c1b8579097 in lock_wait_suspend_thread (thr=0x7fe35800ab60) at /home/work/softwares/mysql-5.7.30/storage/innobase/lock/lock0wait.cc:315
7  0x000055c1b863f860 in row_mysql_handle_errors (new_err=0x7fe3c05e6cf4, trx=0x7fe41c3c18d0, thr=0x7fe35800ab60, savept=0x0) at /home/work/softwares/mysql-5.7.30/storage/innobase/row/row0mysql.cc:783
8  0x000055c1b868514b in row_search_mvcc (buf=0x7fe35801eab0 "\377", mode=PAGE_CUR_GE, prebuilt=0x7fe35800a3a0, match_mode=1, direction=0) at /home/work/softwares/mysql-5.7.30/storage/innobase/row/row0sel.cc:6170
9  0x000055c1b84d83e1 in ha_innobase::index_read (this=0x7fe35801e7c0, buf=0x7fe35801eab0 "\377", key_ptr=0x7fe35800c400 "\001", key_len=8, find_flag=HA_READ_KEY_EXACT) at /home/work/softwares/mysql-5.7.30/storage/innobase/handler/ha_innodb.cc:8755
10 0x000055c1b7a7c4fc in handler::index_read_map (this=0x7fe35801e7c0, buf=0x7fe35801eab0 "\377", key=0x7fe35800c400 "\001", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /home/work/softwares/mysql-5.7.30/sql/handler.h:2818
11 0x000055c1b7a6ca36 in handler::ha_index_read_map (this=0x7fe35801e7c0, buf=0x7fe35801eab0 "\377", key=0x7fe35800c400 "\001", keypart_map=1, find_flag=HA_READ_KEY_EXACT) at /home/work/softwares/mysql-5.7.30/sql/handler.cc:3046
12 0x000055c1b7a7774a in handler::read_range_first (this=0x7fe35801e7c0, start_key=0x7fe35801e8a8, end_key=0x7fe35801e8c8, eq_range_arg=true, sorted=true) at /home/work/softwares/mysql-5.7.30/sql/handler.cc:7411
13 0x000055c1b7a7556e in handler::multi_range_read_next (this=0x7fe35801e7c0, range_info=0x7fe3c05e7af8) at /home/work/softwares/mysql-5.7.30/sql/handler.cc:6476
14 0x000055c1b7a764c7 in DsMrr_impl::dsmrr_next (this=0x7fe35801ea20, range_info=0x7fe3c05e7af8) at /home/work/softwares/mysql-5.7.30/sql/handler.cc:6868
15 0x000055c1b84ebb84 in ha_innobase::multi_range_read_next (this=0x7fe35801e7c0, range_info=0x7fe3c05e7af8) at /home/work/softwares/mysql-5.7.30/storage/innobase/handler/ha_innodb.cc:20574
16 0x000055c1b830debe in QUICK_RANGE_SELECT::get_next (this=0x7fe358026ed0) at /home/work/softwares/mysql-5.7.30/sql/opt_range.cc:11247
17 0x000055c1b801a01c in rr_quick (info=0x7fe3c05e7d90) at /home/work/softwares/mysql-5.7.30/sql/records.cc:405
18 0x000055c1b81cbb1d in mysql_update (thd=0x7fe358000e10, fields=..., values=..., limit=18446744073709551615, handle_duplicates=DUP_ERROR, found_return=0x7fe3c05e8338, updated_return=0x7fe3c05e8340) at /home/work/softwares/mysql-5.7.30/sql/sql_update.cc:819
19 0x000055c1b81d262d in Sql_cmd_update::try_single_table_update (this=0x7fe3580090e0, thd=0x7fe358000e10, switch_to_multitable=0x7fe3c05e83d7) at /home/work/softwares/mysql-5.7.30/sql/sql_update.cc:2906
20 0x000055c1b81d2b9a in Sql_cmd_update::execute (this=0x7fe3580090e0, thd=0x7fe358000e10) at /home/work/softwares/mysql-5.7.30/sql/sql_update.cc:3037
21 0x000055c1b8108f4e in mysql_execute_command (thd=0x7fe358000e10, first_level=true) at /home/work/softwares/mysql-5.7.30/sql/sql_parse.cc:3616
22 0x000055c1b810ed9b in mysql_parse (thd=0x7fe358000e10, parser_state=0x7fe3c05e9530) at /home/work/softwares/mysql-5.7.30/sql/sql_parse.cc:5584
23 0x000055c1b8103afe in dispatch_command (thd=0x7fe358000e10, com_data=0x7fe3c05e9de0, command=COM_QUERY) at /home/work/softwares/mysql-5.7.30/sql/sql_parse.cc:1491
24 0x000055c1b81028b2 in do_command (thd=0x7fe358000e10) at /home/work/softwares/mysql-5.7.30/sql/sql_parse.cc:1032
25 0x000055c1b824a4bc in handle_connection (arg=0x55c1bdca11f0) at /home/work/softwares/mysql-5.7.30/sql/conn_handler/connection_handler_per_thread.cc:313
26 0x000055c1b8955119 in pfs_spawn_thread (arg=0x55c1bdb3fc20) at /home/work/softwares/mysql-5.7.30/storage/perfschema/pfs.cc:2197
27 0x00007fe4253f8609 in start_thread (arg=<optimized out>) at pthread_create.c:477
28 0x00007fe424fd3103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

从调用栈不难了解到,ha_innobase::index_read应该是读取索引数据的函数,调用row_search_mvcc时,走到一个lock_wait_suspend_thread函数中去了,看起来SQL执行过程中好像由于等待什么锁,被阻塞住了。

接下来,通过如下语句获取一下锁等待信息:

mysql> SELECT r.trx_mysql_thread_id waiting_thread,r.trx_query waiting_query,
    -> concat(timestampdiff(SECOND,r.trx_wait_started,CURRENT_TIMESTAMP()),'s') AS duration,
    -> b.trx_mysql_thread_id blocking_thread,t.processlist_command state,b.trx_query blocking_current_query,e.sql_text blocking_last_query
    -> FROM information_schema.innodb_lock_waits w
    -> JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id
    -> JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id
    -> JOIN performance_schema.threads t on t.processlist_id = b.trx_mysql_thread_id
    -> JOIN performance_schema.events_statements_current e USING(thread_id);
+----------------+------------------------------------------+----------+-----------------+-------+------------------------+----------------------------------------------------+
| waiting_thread | waiting_query                            | duration | blocking_thread | state | blocking_current_query | blocking_last_query                                |
+----------------+------------------------------------------+----------+-----------------+-------+------------------------+----------------------------------------------------+
|             10 | update order set status=1 where oid=1    | 48s      |              12 | Sleep | NULL                   | select * from order where oid=1 for update         |
+----------------+------------------------------------------+----------+-----------------+-------+------------------------+----------------------------------------------------+
1 row in set, 1 warning (0.00 sec)

喔,原来有个for update查询语句,对这条数据加了锁,导致这个update SQL阻塞了。

注:ubuntu中pstack包年久失修,基本无法使用,想在ubuntu中使用,可以将centos中的pstack命令复制过来

gcore

gcore是原生程序的内存转储工具,类似jmap,可以将程序的整个内存空间转储为文件,如下:

# 其中10235是进程的pid
$ gcore -o coredump 10235

$ ll coredump*
-rw-r--r-- 1 work work 3.7G 2021-11-07 23:05:46 coredump.10235

转储出来的dump文件,可以直接使用gdb进行调试,如下:

$ gdb java coredump.10235 
For helptype "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from java...
(No debugging symbols found in java)
[New LWP 10235]
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `java'.
#0  __pthread_clockjoin_ex (threadid=139794527459072, thread_return=0x7ffd83e54538, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
145     pthread_join_common.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2474987040 (LWP 10235))]
(gdb)

另外,可以如下配置内核参数,使得程序发生内存访问越界/段错误时,自动生成coredump文件。

# 开启coredump
ulimit -c unlimited
# 持久化方式
echo "ulimit -c unlimited" >> /etc/profile

# 设置coredump的命名规则
$ vi /etc/sysctl.conf
kernel.core_pattern=%e.core.%s_%t
# core_pattern占位变量解释
  %p  pid
  %u  uid
  %g  gid
  %s  signal number
  %t  UNIX time of dump
  %h  hostname
  %e  executable filename
# 查看coredump命名规则配置
$ cat /proc/sys/kernel/core_pattern

有时,在java进程上执行jmap时,会无法执行成功,这时可以使用gcore替代生成coredump,然后使用jmap转换为mat可以分析的hprof文件。

$ jmap -dump:format=b,file=heap.hprof `which java` coredump.10235   

线程栈分析方法

一般来说,jstack配合top只能定位类似死循环这种非常严重的性能问题,由于cpu速度太快了,对于性能稍差但又不非常差的代码,单次jstack很难从线程栈中捕捉到问题代码。

因为性能稍差的代码可能只会比好代码多耗1ms的cpu时间,但这1ms就比我们的手速快多了,当执行jstack时线程早已执行到非问题代码了。

既然手动执行jstack不行,那就让脚本来,快速执行jstack多次,虽然问题代码对于人来说执行太快,但对于正常代码来说,它还是慢一些的,因此当我快速捕捉多次线程栈时,问题代码出现的次数肯定比正常代码出现的次数要多。

# 每0.2s执行一次jstack,并将线程栈数据保存到jstacklog.log
while sleep 0.2;do \
      pid=$(pgrep -n java); \
      [[ $pid ]] && jstack $pid; \
  done > jstacklog.log

$ wc -l jstacklog.log
291121 jstacklog.log

抓了这么多线程栈,如何分析呢?我们可以使用linux中的文本命令来处理,按线程栈分组计数即可,如下:

$ cat jstacklog.log \
    |sed -E -e 's/0x[0-9a-z]+/0x00/g' -e '/^"/ s/[0-9]+/n/g' \
    |awk -v RS="" 'gsub(/\n/,"\\n",$0)||1' \
    |sort|uniq -c|sort -nr \
    |sed 's/$/\n/;s/\\n/\n/g' \
    |less


出现次数最多的线程栈,大概率就是性能不佳或阻塞住的代码,上图中com.example.demo.web.controller.TestController.select方法栈抓取到2053次,是因为我一直在压测这一个接口,所以它被抓出来最多。

火焰图

可以发现,用文本命令分析线程栈并不直观,好在性能优化大师Brendan Gregg发明了火焰图,并开发了一套火焰图生成工具。
工具下载地址:https://github.com/brendangregg/FlameGraph
将jstack抓取的一批线程栈,生成一个火焰图,如下:

$ cat jstacklog.log \
    | ./FlameGraph/stackcollapse-jstack.pl --no-include-tname \
    | ./FlameGraph/flamegraph.pl --cp > jstacklog.svg


如上,生成的火焰图是svg文件,使用浏览器打开即可,在火焰图中,颜色并没有实际含义,它将相同的线程栈聚合在一起显示,因此,图中越宽的栈表示此栈在运行过程中,被抓取到的次数越多,也是我们需要重点优化的地方。

perf

perf是Linux官方维护的性能分析工具,它可以观测很多非常细非常硬核的指标,如IPC,cpu缓存命中率等,如下:

# ubuntu安装perf,包名和内核版本相关,可以直接输入perf命令会给出安装提示
sudo apt install linux-tools-5.4.0-74-generic linux-cloud-tools-5.4.0-74-generic

# cpu的上下文切换、cpu迁移、IPC、分支预测
sudo perf stat -a sleep 5
# cpu的IPC与缓存命中率
sudo perf stat -e cycles,instructions,cache-references,cache-misses,bus-cycles -a sleep 10
# cpu的1级数据缓存命中率
sudo perf stat -e L1-dcache-loads,L1-dcache-load-misses,L1-dcache-stores -a sleep 10
# 页表缓存TLB命中率
sudo perf stat -e dTLB-loads,dTLB-load-misses,dTLB-prefetch-misses -a sleep 10
# cpu的最后一级缓存命中率
sudo perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-prefetches -a sleep 10

# Count system calls by type for the specified PID, until Ctrl-C:
sudo perf stat -e 'syscalls:sys_enter_*' -p PID -I1000 2>&1 | awk '$2 != 0'
# Count system calls by type for the entire system, for 5 seconds:
sudo perf stat -e 'syscalls:sys_enter_*' -a sleep 5 2>&1| awk '$1 != 0'
# Count syscalls per-second system-wide:
sudo perf stat -e raw_syscalls:sys_enter -I 1000 -a

当然,它也可以用来抓取线程栈,并生成火焰图,如下:

# 抓取60s的线程栈,其中1892是mysql的进程pid
$ sudo perf record -F 99 -p 1892 -g sleep 60
[ perf record: Woken up 5 times to write data ]
[ perf record: Captured and wrote 1.509 MB perf.data (6938 samples) ]

# 生成火焰图
$ sudo perf script \
    | ./FlameGraph/stackcollapse-perf.pl \
    | ./FlameGraph/flamegraph.pl > mysqld_flamegraph.svg


如上所示,使用perf生成的mysql的火焰图,perf抓取线程栈相比jstack的优点是,抓取精度比jstack更高,运行开销比jstack更小,并且还可以抓到Linux内核调用栈!

当然,如此强大的它,也需要像root这样至高无上的权限才能使用。

注:perf抓取线程栈,是顺着cpu上的栈寄存器找到当前线程的调用栈的,因此它只能抓到当前正在cpu上运行线程的线程栈,因此通过perf可以非常容易做oncpu分析,分析high cpu问题。

注意:某些情况下,perf获取到的mysql线程栈是破碎的,类似_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command这种,非常难读,这种情况下,可以先使用sudo perf script | c++filt命令处理下c++函数命名问题,再将输出给到stackcollapse-perf.pl脚本,c++filt使用效果如下:

# 破碎的函数名
$ objdump -tT `which mysqld` | grep dispatch_command
00000000014efdf3 g     F .text  000000000000252e              _Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command
00000000014efdf3 g    DF .text  000000000000252e  Base        _Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command

# 使用c++filt处理过后的函数名
$ objdump -tT `which mysqld` | grep dispatch_command | c++filt
00000000014efdf3 g     F .text  000000000000252e              dispatch_command(THD*, COM_DATA const*, enum_server_command)
00000000014efdf3 g    DF .text  000000000000252e  Base        dispatch_command(THD*, COM_DATA const*, enum_server_command)

offcpu火焰图

线程在运行的过程中,要么在CPU上执行,要么被锁或io操作阻塞,从而离开CPU进去睡眠状态,待被解锁或io操作完成,线程会被唤醒而变成运行态。
如下:

当线程在cpu上运行时,我们称其为oncpu,当线程阻塞而离开cpu后,称其为offcpu。

而线程离开CPU和之后被唤醒,就是我们常说的线程上下文切换,如果线程是因为io或锁等待而主动让出cpu,称为自愿上下文切换,如果是时间片用尽而让出cpu,称为非自愿上下文切换。

如果当线程在睡眠之前记录一下当前时间,然后被唤醒时记录当前线程栈与阻塞时间,再使用FlameGraph工具将线程栈绘制成一张火焰图,这样我们就得到了一张offcpu火焰图,火焰图宽的部分就是线程阻塞较多的点了,这就需要再介绍一下bcc工具了。

bcc

bcc是使用Linux ebpf机制实现的一套工具集,包含非常多的底层分析工具,如查看文件缓存命中率,tcp重传情况,mysql慢查询等等,如下: 
另外,它还可以做offcpu分析,生成offcpu火焰图,如下:

# ubuntu安装bcc工具集
$ sudo apt install bpfcc-tools
# 使用root身份进入bash
$ sudo bash
# 获取jvm函数符号信息
$ ./FlameGraph/jmaps
# 抓取offcpu线程栈30s,83101是mysqld的进程pid
$ offcputime-bpfcc -df -p 83101 30 > offcpu_stack.out
# 生成offcpu火焰图
$ cat offcpu_stack.out \
    | sed 's/;::/:::/g'  \
    | ./FlameGraph/flamegraph.pl --color=io --title="Off-CPU Time Flame Graph" --countname=us > offcpu_stack.svg


如上图,我绘制了一张mysql的offcpu火焰图,可以发现大多数线程的offcpu都是由锁引起的,另外,offcpu火焰图与oncpu火焰图稍有不同,oncpu火焰图宽度代表线程栈出现次数,而offcpu火焰图宽度代表线程栈阻塞时间。

在我分析此图的过程中,发现JOIN::make_join_plan()函数最终竟然去调用了btr_estimate_n_rows_in_range_low这个函数,显然JOIN::make_join_plan()应该是用于制定SQL执行计划的,为啥好像去读磁盘数据了?经过在网上尝试搜索btr_estimate_n_rows_in_range_low,发现mysql有个机制,当使用非唯一索引查询数据时,mysql为了执行计划的准确性,会实际去访问一些索引数据,来辅助评估当前索引是否应该使用,避免索引统计信息不准导致的SQL执行计划不优。

我看了看相关表与SQL,发现当前使用的索引,由于之前研究分区表而弄成了非唯一索引了,实际上它可以设置为唯一索引的,于是我把索引调整成唯一索引,再次压测SQL,发现QPS从2300增加到了2700左右。

这里,也可以看出,对于一些没读过源码的中间件(如mysql),也是可以尝试使用perf或bcc生成火焰图来分析的,不知道各函数是干啥用的,可以直接把函数名拿到baidu、google去搜索,瞄一瞄别人源码解析的文章了解其作用。

bcc项目地址:https://github.com/iovisor/bcc

往期内容

Linux命令拾遗-入门篇
原来awk真是神器啊
Linux文本命令技巧(上)
Linux文本命令技巧(下)
字符编码解惑


长按关注【打码日记】


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存