MySQL性能诊断与调优之：`MySQL`的`Pstack`：其在`MySQL`进程堆栈跟踪中的应用。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

MySQL性能诊断与调优：Pstack在进程堆栈跟踪中的应用

大家好，今天我们来深入探讨MySQL性能诊断与调优的一个重要工具：pstack。在MySQL服务器遇到性能瓶颈，例如CPU占用率过高、响应时间过长、甚至hang住时，pstack可以帮助我们查看MySQL进程的当前堆栈信息，从而定位问题的根源。

什么是堆栈跟踪？

在理解pstack之前，我们需要了解什么是堆栈跟踪。简单来说，堆栈跟踪（Stack Trace）是程序在执行过程中函数调用链的记录。当程序执行到某个函数时，会将当前函数的返回地址压入堆栈，然后跳转到被调用函数执行。当被调用函数执行完毕后，会从堆栈中取出返回地址，返回到调用函数继续执行。

堆栈跟踪记录了这一系列的函数调用关系，从程序的入口点开始，一直到当前执行的函数。通过分析堆栈跟踪，我们可以看到程序执行到当前位置的路径，以及每个函数被调用的顺序和上下文。

为什么堆栈跟踪对性能诊断有用？

当MySQL进程出现性能问题时，往往是由于某个或某些函数执行时间过长，或者进入了死循环、死锁等状态。通过查看堆栈跟踪，我们可以知道当前MySQL进程正在执行哪些函数，以及这些函数被调用的顺序。如果某个函数长时间出现在堆栈跟踪中，或者堆栈跟踪显示程序正在死循环或死锁，那么我们就可以怀疑该函数是性能瓶颈的所在，从而有针对性地进行优化。

`pstack`命令介绍

pstack是一个用于打印进程堆栈跟踪的命令行工具，通常包含在gdb或binutils软件包中。它可以显示指定进程的每个线程的堆栈信息，包括函数调用链、函数地址、以及可能的参数值。

pstack命令的基本语法:

pstack <pid>

其中 <pid> 是要跟踪的进程ID。

pstack的原理:

pstack的底层实现依赖于ptrace系统调用。 ptrace允许一个进程（通常是调试器）控制另一个进程的执行，并可以读取和修改目标进程的内存、寄存器等信息。

pstack使用ptraceattach到目标进程，然后读取目标进程的寄存器信息，从中获取栈指针（Stack Pointer，SP）和帧指针（Frame Pointer，FP）。通过FP和SP，pstack可以遍历堆栈，找到每个函数的返回地址，从而构建出函数调用链。最后，pstack将函数调用链打印出来，形成堆栈跟踪。

`pstack`的应用场景

pstack在MySQL性能诊断和调优中有很多应用场景，以下是一些常见的例子：

CPU占用率过高： 当MySQL服务器的CPU占用率持续很高时，可以使用pstack查看MySQL进程的堆栈信息，找出占用CPU时间最多的函数。
响应时间过长： 当某个SQL查询的响应时间异常长时，可以使用pstack查看执行该查询的MySQL线程的堆栈信息，找出导致延迟的瓶颈。
MySQL进程hang住： 当MySQL进程hang住，没有任何响应时，可以使用pstack查看所有MySQL线程的堆栈信息，找出导致hang住的原因，例如死锁、死循环等。
死锁检测： pstack可以结合SHOW ENGINE INNODB STATUS命令，帮助我们分析死锁的原因。 SHOW ENGINE INNODB STATUS会显示死锁的详细信息，包括涉及的线程ID和SQL语句。然后，我们可以使用pstack查看这些线程的堆栈信息，找出导致死锁的函数。
性能分析： pstack可以结合其他性能分析工具，例如perf，帮助我们更全面地了解MySQL的性能瓶颈。 perf可以收集更详细的性能数据，例如CPU周期、指令数等。然后，我们可以使用pstack查看perf报告中热点函数的堆栈信息，从而更深入地了解性能瓶颈。

使用`pstack`进行性能诊断的步骤

使用pstack进行性能诊断的一般步骤如下：

确定MySQL进程ID： 使用ps或top命令找到MySQL服务器的进程ID。
```
ps aux | grep mysqld
```
通常会找到类似这样的输出：
```
mysql    12345  0.0  1.2 1234567 89012 ?        Ssl  Jan01   0:00 /usr/sbin/mysqld
```
其中 12345 就是MySQL进程ID。
使用pstack命令： 运行 pstack <pid> 命令，将 <pid> 替换为实际的MySQL进程ID。
```
pstack 12345
```
分析堆栈跟踪： 仔细阅读pstack的输出，分析函数调用链，找出可疑的函数。
- 关注长时间出现在堆栈中的函数： 这些函数可能是性能瓶颈的所在。
- 关注与锁相关的函数： 例如 pthread_mutex_lock、pthread_mutex_unlock、os_mutex_lock、os_mutex_unlock 等。如果这些函数长时间阻塞，可能存在死锁或锁竞争。
- 关注I/O相关的函数： 例如 read、write、fread、fwrite 等。如果这些函数长时间阻塞，可能存在磁盘I/O瓶颈。
- 关注网络相关的函数： 例如 socket、send、recv 等。如果这些函数长时间阻塞，可能存在网络瓶颈。
- 查找循环调用的函数： 循环调用可能导致死循环或栈溢出。
重复步骤2和3： 多次运行 pstack 命令，以便观察堆栈信息的变化。这可以帮助我们更准确地确定性能瓶颈。
结合其他工具： 结合其他性能分析工具，例如 perf、gdb、SHOW ENGINE INNODB STATUS 等，进行更深入的分析。

`pstack`实例分析

下面我们通过几个实例来演示如何使用pstack进行性能诊断。

实例1：CPU占用率过高

假设MySQL服务器的CPU占用率持续很高，我们首先使用 top 命令找到MySQL进程ID，然后使用 pstack 命令查看堆栈信息。

pstack 12345

pstack输出如下：

Thread 1 (Thread 0x7f2a40e00700 (LWP 12345)):
#0  0x00007f2a406e78e0 in epoll_wait () from /lib64/libc.so.6
#1  0x0000000000e7a89f in my_epoll_wait (epoll_fd=15, event=0x7f2a40dfedb0, max_number_of_events=1024, timeout=1000) at /path/to/mysql/source/mysys/my_epoll.c:164
#2  0x0000000000e7b49d in mysql_socket_dispatcher (arg=0x14061290) at /path/to/mysql/source/mysys/my_thread.c:371
#3  0x000000000136e3e5 in pfs_spawn_thread (arg=0x14061290) at /path/to/mysql/source/storage/innobase/os/os0thread.cc:944
#4  0x00007f2a4039fdd5 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f2a406f0ead in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f2a3c13e700 (LWP 12346)):
#0  0x00007f2a406e78e0 in epoll_wait () from /lib64/libc.so.6
#1  0x0000000000e7a89f in my_epoll_wait (epoll_fd=18, event=0x7f2a3c13ddb0, max_number_of_events=1024, timeout=1000) at /path/to/mysql/source/mysys/my_epoll.c:164
#2  0x0000000000e7b49d in mysql_socket_dispatcher (arg=0x140624f0) at /path/to/mysql/source/mysys/my_thread.c:371
#3  0x000000000136e3e5 in pfs_spawn_thread (arg=0x140624f0) at /path/to/mysql/source/storage/innobase/os/os0thread.cc:944
#4  0x00007f2a4039fdd5 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f2a406f0ead in clone () from /lib64/libc.so.6

... (其他线程) ...

从上面的堆栈信息可以看出，大部分线程都在 epoll_wait 函数中等待事件。这表明MySQL服务器正在处理大量的网络连接，可能是由于大量的客户端请求或者慢查询导致连接阻塞。

可能的解决方案：

优化SQL查询： 找出慢查询，并进行优化，例如添加索引、重写SQL语句等。
增加MySQL连接数： 适当增加 max_connections 参数的值，以允许更多的客户端连接。
使用连接池： 使用连接池可以减少连接创建和销毁的开销。
检查网络： 检查网络是否存在瓶颈，例如带宽不足、延迟过高等。

实例2：死锁检测

假设MySQL服务器发生了死锁，我们首先使用 SHOW ENGINE INNODB STATUS 命令查看死锁信息。

SHOW ENGINE INNODB STATUSG

SHOW ENGINE INNODB STATUS 输出中会包含 LATEST DETECTED DEADLOCK 部分，其中会显示死锁的详细信息，包括涉及的线程ID和SQL语句。

*** (1) TRANSACTION:
TRANSACTION 2153631, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 12345, OS thread handle 140157631043584, query id 123456 localhost root updating
UPDATE account SET balance = balance - 100 WHERE id = 1;
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 4 n bits 72 index PRIMARY of table `test`.`account` trx id 2153631 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION 2153632, ACTIVE 15 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 12346, OS thread handle 140157639432448, query id 123457 localhost root updating
UPDATE account SET balance = balance + 100 WHERE id = 1;
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 58 page no 4 n bits 72 index PRIMARY of table `test`.`account` trx id 2153632 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 58 page no 4 n bits 72 index PRIMARY of table `test`.`account` trx id 2153632 lock_mode X locks rec but not gap waiting
*** WE ROLL BACK TRANSACTION (1)

从上面的死锁信息可以看出，线程ID为 12345 和 12346 的线程发生了死锁。然后，我们使用 pstack 命令查看这两个线程的堆栈信息。

pstack 12345
pstack 12346

通过分析堆栈信息，我们可以找到导致死锁的函数，例如：

#0  0x00007f2a403a6e70 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000137c15d in row_mysql_lock_data_dictionary (thd=0x14061290, table=0x140637a0, lock_type=LOCK_SHARED) at /path/to/mysql/source/storage/innobase/row/row0mysql.cc:1420
#2  0x000000000128977d in ha_innobase::index_read_map (thd=0x14061290, key=0x7f2a40dfef00, find_flag=HA_READ_KEY_EXACT, part_id=0x0, read_flags=HA_READ_AFTER_KEY) at /path/to/mysql/source/storage/innobase/handler/ha_innodb.cc:8610
#3  0x0000000000d6512d in handler::ha_index_read_map (thd=0x14061290, key=0x7f2a40dfef00, find_flag=HA_READ_KEY_EXACT) at /path/to/mysql/source/sql/handler.cc:2815
#4  0x0000000000e10699 in rr_index_read (info=0x14062c20, find_flag=HA_READ_KEY_EXACT) at /path/to/mysql/source/sql/records.cc:4728
#5  0x0000000000f81b27 in mysql_update (thd=0x14061290, table_list=0x140627e0, fields=0x14062840, values=0x140628a0, conds=0x14062900, order=0x0, limit=0x0, procedure_name=0x0, flags=0) at /path/to/mysql/source/sql/sql_update.cc:1818
#6  0x0000000000f83a9f in mysql_execute_command (thd=0x14061290, first_level=1) at /path/to/mysql/source/sql/sql_parse.cc:3283
#7  0x0000000000f84e37 in mysql_parse (thd=0x14061290, inBuf=0x14060940 "UPDATE account SET balance = balance - 100 WHERE id = 1", inLength=57, found_semicolon=0) at /path/to/mysql/source/sql/sql_parse.cc:5524
#8  0x0000000000f8613c in dispatch_command (thd=0x14061290, com_data=0x14060940, command=COM_QUERY) at /path/to/mysql/source/sql/sql_parse.cc:2055
#9  0x0000000000f8732f in do_command (thd=0x14061290) at /path/to/mysql/source/sql/sql_parse.cc:1443
#10 0x0000000000f0f40d in handle_one_connection (arg=0x14060780) at /path/to/mysql/source/sql/sql_connect.cc:574
#11 0x00007f2a4039fdd5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f2a406f0ead in clone () from /lib64/libc.so.6

从上面的堆栈信息可以看出，两个线程都在 row_mysql_lock_data_dictionary 函数中等待锁。这表明死锁是由于行锁竞争引起的。

可能的解决方案：

优化事务： 尽量减少事务的持有时间，避免长时间持有锁。
调整事务隔离级别： 调整事务隔离级别，例如从 REPEATABLE READ 降到 READ COMMITTED，可以减少锁的竞争。
使用更细粒度的锁： 使用更细粒度的锁，例如行级锁，可以减少锁的竞争。
避免交叉更新： 尽量避免多个事务交叉更新同一行数据。

实例3：I/O瓶颈

假设MySQL服务器的I/O负载很高，我们可以使用 iotop 或 iostat 命令查看磁盘I/O情况。如果发现某个MySQL线程的I/O很高，可以使用 pstack 命令查看该线程的堆栈信息。

pstack 12345

pstack输出如下：

Thread 1 (Thread 0x7f2a40e00700 (LWP 12345)):
#0  0x00007f2a406e300d in read () from /lib64/libc.so.6
#1  0x000000000133a42a in os_file_read (file=0x14061290, buf=0x7f2a40dfedb0, len=16384) at /path/to/mysql/source/storage/innobase/os/os0file.cc:291
#2  0x000000000133b2a8 in fil_io (type=FIL_IO_READ, space_id=0, page_no=12345, offset=0, buf=0x7f2a40dfedb0, len=16384) at /path/to/mysql/source/storage/innobase/fil/fil0io.cc:1334
#3  0x000000000125e8e7 in buf_read_page_low (bpage=0x140624f0, zip_size=0) at /path/to/mysql/source/storage/innobase/buf/buf0rea.cc:787
#4  0x000000000125f44d in buf_read_page (space_id=0, page_no=12345, zip_size=0) at /path/to/mysql/source/storage/innobase/buf/buf0rea.cc:1017
#5  0x0000000001261572 in buf_page_get (space_id=0, page_no=12345, zip_size=0, rw_latch=BUF_NO_LATCH, page_origin=BUF_ORIGIN) at /path/to/mysql/source/storage/innobase/buf/buf0buf.cc:2563
#6  0x000000000129194d in ha_innobase::index_read (thd=0x14061290, key=0x7f2a40dfef00, find_flag=HA_READ_KEY_EXACT, part_id=0x0, read_flags=HA_READ_AFTER_KEY) at /path/to/mysql/source/storage/innobase/handler/ha_innodb.cc:9358
#7  0x0000000000d6512d in handler::ha_index_read_map (thd=0x14061290, key=0x7f2a40dfef00, find_flag=HA_READ_KEY_EXACT) at /path/to/mysql/source/sql/handler.cc:2815
#8  0x0000000000e10699 in rr_index_read (info=0x14062c20, find_flag=HA_READ_KEY_EXACT) at /path/to/mysql/source/sql/records.cc:4728
#9  0x0000000000f81b27 in mysql_update (thd=0x14061290, table_list=0x140627e0, fields=0x14062840, values=0x140628a0, conds=0x14062900, order=0x0, limit=0x0, procedure_name=0x0, flags=0) at /path/to/mysql/source/sql/sql_update.cc:1818
#10 0x0000000000f83a9f in mysql_execute_command (thd=0x14061290, first_level=1) at /path/to/mysql/source/sql/sql_parse.cc:3283
#11 0x0000000000f84e37 in mysql_parse (thd=0x14061290, inBuf=0x14060940 "UPDATE account SET balance = balance - 100 WHERE id = 1", inLength=57, found_semicolon=0) at /path/to/mysql/source/sql/sql_parse.cc:5524
#12 0x0000000000f8613c in dispatch_command (thd=0x14061290, com_data=0x14060940, command=COM_QUERY) at /path/to/mysql/source/sql/sql_parse.cc:2055
#13 0x0000000000f8732f in do_command (thd=0x14061290) at /path/to/mysql/source/sql/sql_parse.cc:1443
#14 0x0000000000f0f40d in handle_one_connection (arg=0x14060780) at /path/to/mysql/source/sql/sql_connect.cc:574
#15 0x00007f2a4039fdd5 in start_thread () from /lib64/libpthread.so.0
#16 0x00007f2a406f0ead in clone () from /lib64/libc.so.6

从上面的堆栈信息可以看出，线程正在 read 函数中读取数据。这表明该线程正在进行大量的磁盘I/O操作。

可能的解决方案：

优化SQL查询： 找出需要大量I/O的查询，并进行优化，例如添加索引、重写SQL语句等。
增加InnoDB缓冲池大小： 增加 innodb_buffer_pool_size 参数的值，以减少磁盘I/O。
使用更快的存储设备： 使用SSD等更快的存储设备，可以提高I/O性能。
优化操作系统I/O调度器： 调整操作系统I/O调度器，例如使用 noop 或 deadline 调度器，可以提高I/O性能。

`pstack`的局限性

pstack虽然是一个非常有用的工具，但也存在一些局限性：

需要root权限： 通常需要root权限才能使用pstack查看其他进程的堆栈信息。
符号信息缺失： 如果MySQL服务器没有编译调试信息，pstack的输出可能只显示函数地址，而没有函数名。这会增加分析的难度。
快照信息： pstack只能提供进程在运行那一刻的堆栈信息，是快照信息。要找到问题，可能需要多次执行并分析。

为了解决这些局限性，我们可以采取以下措施：

使用sudo命令： 使用 sudo pstack <pid> 命令可以以root权限运行pstack。
编译调试信息： 在编译MySQL服务器时，添加 -g 选项可以生成调试信息。这可以使pstack的输出包含函数名和行号，方便分析。
结合其他工具： 结合其他性能分析工具，例如 perf、gdb，可以更全面地了解MySQL的性能瓶颈。

其他相关工具

除了pstack之外，还有一些其他的工具可以用于MySQL性能诊断和调优：

工具名称	功能
`gdb`	GNU调试器，可以用于调试MySQL进程，查看内存、寄存器等信息。
`perf`	Linux性能分析工具，可以收集CPU周期、指令数等详细的性能数据。
`SHOW ENGINE INNODB STATUS`	MySQL命令，可以显示InnoDB存储引擎的详细信息，包括死锁信息、事务信息等。
`mysqldumpslow`	MySQL慢查询日志分析工具，可以统计慢查询的次数、平均执行时间等。
`pt-query-digest`	Percona Toolkit中的慢查询日志分析工具，功能比`mysqldumpslow`更强大。
`tcpdump`	网络抓包工具，可以捕获MySQL服务器和客户端之间的网络数据包，用于分析网络瓶颈。
`strace`	系统调用跟踪工具，可以跟踪MySQL进程的系统调用，用于分析I/O瓶颈。
`lsof`	查看打开文件工具，可以查看MySQL进程打开的文件，用于分析文件I/O瓶颈。
`iotop` / `iostat`	磁盘I/O监控工具，可以监控磁盘I/O情况，用于分析磁盘I/O瓶颈。

这些工具可以与pstack结合使用，帮助我们更全面地了解MySQL的性能瓶颈，并制定相应的优化方案。

总结

pstack是一个强大的工具，可以帮助我们快速定位MySQL进程的性能瓶颈。通过分析堆栈跟踪，我们可以了解MySQL进程正在执行哪些函数，以及这些函数被调用的顺序，从而找出导致性能问题的根源。但是，pstack也有一些局限性，需要结合其他工具一起使用，才能更全面地了解MySQL的性能状况。

最后

理解堆栈跟踪对于诊断和解决MySQL性能问题至关重要，掌握pstack工具的使用是每个MySQL DBA和开发人员必备的技能。结合实际案例，灵活运用pstack，能够有效地提升MySQL服务器的性能和稳定性。

MySQL性能诊断与调优：Pstack在进程堆栈跟踪中的应用

什么是堆栈跟踪？

pstack命令介绍

pstack的应用场景

使用pstack进行性能诊断的步骤

pstack实例分析

pstack的局限性

其他相关工具

总结

最后

发表回复 取消回复

`pstack`命令介绍

`pstack`的应用场景

使用`pstack`进行性能诊断的步骤

`pstack`实例分析

`pstack`的局限性

发表回复取消回复