好的，让我们开始深入探讨 MySQL 性能诊断与调优中的 pstack 工具及其在 MySQL 进程堆栈跟踪中的应用。
MySQL 性能诊断与调优之：MySQL 的 Pstack：进程堆栈跟踪应用
大家好，今天我们来聊聊 MySQL 性能诊断中一个非常实用的工具：pstack。 相信很多同学在排查 MySQL 性能问题时，都会遇到 CPU 占用率过高、查询卡顿、死锁等情况。 当我们尝试通过 show processlist 或者 performance_schema 发现问题时，往往只能看到一些表象，比如哪个 SQL 语句执行时间过长，哪个线程处于阻塞状态，但却无法深入了解其背后的原因。 这时，pstack 就可以帮助我们深入到进程内部，查看线程的调用堆栈，从而定位问题的根源。
1. 什么是 Pstack？
pstack 是一个用于打印进程（process）堆栈跟踪（stack trace）的命令行工具。 它可以显示指定进程中每个线程的当前函数调用链，这对于分析程序在运行时的问题，例如死锁、无限循环、崩溃等，非常有帮助。 pstack 通常包含在 gdb (GNU Debugger) 工具包中，所以安装了 gdb 之后，一般就可以直接使用 pstack 命令。
2. Pstack 的作用
- 定位死锁： 当 MySQL 发生死锁时，
pstack可以显示参与死锁的线程正在执行的 SQL 语句和锁等待情况，帮助我们分析死锁的原因。 - 分析 CPU 占用率过高： 当 MySQL 进程 CPU 占用率过高时，
pstack可以显示占用 CPU 最高的线程正在执行的函数，从而定位性能瓶颈。 - 诊断查询卡顿： 当某个查询卡顿时，
pstack可以显示执行该查询的线程正在等待的资源，例如 I/O、锁等，帮助我们分析查询卡顿的原因。 - 排查崩溃问题： 当 MySQL 发生崩溃时，
pstack可以显示崩溃时的函数调用堆栈，帮助我们分析崩溃的原因。 - 理解代码执行流程： 通过查看函数的调用堆栈，可以帮助我们理解 MySQL 内部代码的执行流程，加深对 MySQL 架构的理解。
3. 如何使用 Pstack
pstack 的基本用法非常简单：
pstack <pid>其中 <pid> 是要跟踪的进程的 ID。 要获取 MySQL 进程的 ID，可以使用 ps 命令或者 pgrep 命令：
ps -ef | grep mysqld
pgrep mysqld例如，如果 mysqld 进程的 ID 是 12345，那么可以使用以下命令来打印其堆栈跟踪：
pstack 12345pstack 会输出 MySQL 进程中每个线程的堆栈信息。 每个线程的堆栈信息都包含一系列的函数调用，从最顶层的函数（当前正在执行的函数）到最底层的函数（线程的入口函数）。
4. Pstack 输出解读
pstack 的输出信息可能比较复杂，但是我们可以通过以下几个方面来解读：
- 线程 ID (TID)： 每个线程都有一个唯一的 ID，
pstack会在每个线程的堆栈信息前面显示线程 ID。 - 函数名： 堆栈信息中的每一行都表示一个函数调用，显示了函数名和参数信息。
- 文件名和行号： 有些堆栈信息还会显示函数所在的文件名和行号，这对于定位代码问题非常有帮助。
- 库名： 有些堆栈信息还会显示函数所在的库名，例如
libpthread.so.0表示线程库。
下面是一个 pstack 输出的示例：
Thread 1 (Thread 0x7f7a3c720700 (LWP 12345)):
#0 0x00007f7a3c5d09a0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000c1e1a3 in mysqld_cond_wait (cond=0x7f7a3c998760, mutex=0x7f7a3c998720) at /path/to/mysql/source/mysys/thr_cond.c:52
#2 0x0000000000c1e436 in thr_lock_wait (lock=0x7f7a3c998720) at /path/to/mysql/source/mysys/thr_lock.c:147
#3 0x0000000000c1e56e in lock_wait (lock=0x7f7a3c998720) at /path/to/mysql/source/mysys/thr_lock.c:243
#4 0x0000000000e52855 in MDL_lock::acquire_lock (this=0x7f7a3c9986f0, thr=0x7f7a3c720700, type=MDL_SHARED_READ, duration=MDL_TRANSACTION, wait=true) at /path/to/mysql/source/sql/mdl.cc:663
#5 0x0000000000e534d1 in MDL_context::acquire_lock (this=0x7f7a3c9986c0, thr=0x7f7a3c720700, table=0x7f7a3c998690, type=MDL_SHARED_READ, duration=MDL_TRANSACTION) at /path/to/mysql/source/sql/mdl.cc:1062
#6 0x0000000000e3a89f in open_table (thd=0x7f7a3c720700, table=0x7f7a3c998660, lock_type=MDL_SHARED_READ) at /path/to/mysql/source/sql/sql_base.cc:5730
#7 0x0000000000e3b576 in open_tables (thd=0x7f7a3c720700, tables=0x7f7a3c998630, flags=0) at /path/to/mysql/source/sql/sql_base.cc:6098
#8 0x0000000000e3d3c2 in mysql_execute_command (thd=0x7f7a3c720700, first_level=true) at /path/to/mysql/source/sql/sql_parse.cc:3637
#9 0x0000000000e40335 in mysql_parse (thd=0x7f7a3c720700, parser_state=0x7f7a3c998600, inBuf=0x7f7a3c9985d0, inLen=100, found_semicolon=0) at /path/to/mysql/source/sql/sql_parse.cc:5542
#10 0x0000000000e40711 in dispatch_command (thd=0x7f7a3c720700, com_data=0x7f7a3c9985a0, command=COM_QUERY) at /path/to/mysql/source/sql/sql_parse.cc:5811
#11 0x0000000000e41864 in do_command (thd=0x7f7a3c720700) at /path/to/mysql/source/sql/sql_parse.cc:4134
#12 0x0000000000f0b757 in handle_connection (arg=0x7f7a3c720700) at /path/to/mysql/source/sql/conn_handler/connection_handler_per_thread.cc:309
#13 0x00007f7a3c5cbdd5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f7a3c522ead in clone () from /lib64/libc.so.6在这个示例中，我们可以看到线程 1 正在等待一个条件变量 pthread_cond_wait， 并且正在尝试获取一个 MDL_SHARED_READ 锁， 这可能表示该线程正在等待其他线程释放锁， 从而导致查询卡顿。
5. Pstack 的局限性
pstack 虽然是一个非常有用的工具，但是它也有一些局限性：
- 需要 root 权限： 默认情况下，
pstack需要 root 权限才能访问其他进程的内存空间。 - 输出信息可能不完整： 如果 MySQL 进程使用了大量的第三方库，
pstack可能无法显示所有函数的调用信息。 - 需要符号表： 为了能够显示函数名和文件名，
pstack需要 MySQL 进程包含调试符号表。 如果 MySQL 进程在编译时没有包含调试符号表，pstack只能显示函数的地址，而无法显示函数名。 - 动态性：
pstack只能显示进程在执行pstack命令那一刻的堆栈信息。 进程的状态是不断变化的，因此pstack的输出信息可能只是问题发生时的一个快照，而不是问题的全貌。
6. Pstack 与 GDB
虽然 pstack 已经非常方便，但在一些复杂情况下，我们可能需要更强大的调试工具，例如 gdb (GNU Debugger)。 gdb 可以让我们更深入地分析进程的内存空间，设置断点，单步执行代码，查看变量的值等等。
pstack 本身就是基于 gdb 实现的，它相当于 gdb 的一个简化版本。 我们可以使用 gdb 来 attach 到 MySQL 进程，然后使用 bt (backtrace) 命令来打印堆栈信息，效果与 pstack 类似。
gdb -p <pid>
(gdb) btgdb 提供了更多的灵活性和控制力，但是使用起来也更复杂。
7. 结合 Performance Schema 诊断
pstack 通常需要结合 MySQL 的 Performance Schema 才能更好地定位问题。 Performance Schema 提供了丰富的性能监控数据，例如线程的执行时间、锁等待时间、I/O 等待时间等等。 我们可以通过 Performance Schema 找到性能瓶颈所在的线程，然后使用 pstack 来查看该线程的堆栈信息，从而定位问题的根源。
例如，我们可以使用以下 SQL 语句来查询执行时间最长的线程：
SELECT
thread_id,
processlist_id,
processlist_user,
processlist_host,
processlist_db,
processlist_command,
processlist_time,
processlist_state,
processlist_info
FROM performance_schema.threads
WHERE resource_group = 'USER'
ORDER BY processlist_time DESC
LIMIT 10;找到执行时间最长的线程 ID 后，就可以使用 pstack 来查看该线程的堆栈信息。
8. 案例分析：死锁
假设我们遇到了一个死锁问题，通过 show engine innodb status 命令，我们看到了以下死锁信息：
*** (1) TRANSACTION:
TRANSACTION 234567, ACTIVE 10 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 100, OS thread handle 0x7f7a3c720700, query id 123456 localhost user updating
UPDATE table1 SET column1 = 'value1' WHERE id = 1;
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `db`.`table1` trx id 234567 lock_mode X locks rec but not gap waiting
*** (2) TRANSACTION:
TRANSACTION 234568, ACTIVE 5 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 101, OS thread handle 0x7f7a3c8a0700, query id 123457 localhost user updating
UPDATE table2 SET column2 = 'value2' WHERE id = 2;
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 123 page no 456 n bits 72 index PRIMARY of table `db`.`table1` trx id 234568 lock_mode X locks rec but not gap
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 123 page no 789 n bits 72 index PRIMARY of table `db`.`table2` trx id 234568 lock_mode X locks rec but not gap waiting
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 123 page no 789 n bits 72 index PRIMARY of table `db`.`table2` trx id 234567 lock_mode X locks rec but not gap
*** WE ROLL BACK TRANSACTION (1)从死锁信息中，我们可以看到线程 100 和线程 101 发生了死锁。 线程 100 正在等待表 table1 的记录锁，而线程 101 持有该锁，并且正在等待表 table2 的记录锁，而线程 100 持有该锁。
接下来，我们可以使用 pstack 来查看线程 100 和线程 101 的堆栈信息：
pstack 100
pstack 101通过分析堆栈信息，我们可以找到线程 100 和线程 101 正在执行的 SQL 语句，以及它们正在等待的锁。 这可以帮助我们理解死锁的发生过程，并找到解决死锁的方法，例如优化 SQL 语句，调整事务隔离级别等等。
9. 案例分析：CPU 占用率过高
假设我们发现 MySQL 进程的 CPU 占用率过高，可以使用 top 命令来查看哪个线程占用了最多的 CPU 资源：
top -H -p <mysqld_pid>其中 <mysqld_pid> 是 MySQL 进程的 ID。 top 命令会显示每个线程的 CPU 占用率。 找到 CPU 占用率最高的线程 ID 后，就可以使用 pstack 来查看该线程的堆栈信息，从而定位性能瓶颈。
例如，如果 top 命令显示线程 12345 占用了最多的 CPU 资源，那么可以使用以下命令来查看其堆栈信息：
pstack 12345通过分析堆栈信息，我们可以找到占用 CPU 最高的函数，例如某个复杂的 SQL 语句的执行函数，或者某个耗时的 I/O 操作的函数。 这可以帮助我们找到性能瓶颈，并进行相应的优化，例如优化 SQL 语句，调整 I/O 参数等等。
10. 案例分析：查询卡顿
当某个查询卡顿时，我们可以使用 show processlist 命令来查看该查询的状态：
show processlist;如果 show processlist 命令显示该查询的状态为 Locked 或者 Waiting for table metadata lock，那么表示该查询正在等待锁。 我们可以使用 pstack 来查看执行该查询的线程的堆栈信息，从而了解该线程正在等待哪个锁，以及哪个线程持有该锁。
例如，如果 show processlist 命令显示线程 12345 正在等待锁，那么可以使用以下命令来查看其堆栈信息：
pstack 12345通过分析堆栈信息，我们可以找到该线程正在等待的锁的类型和资源，例如表锁、行锁等等。 这可以帮助我们理解查询卡顿的原因，并找到解决卡顿的方法，例如优化 SQL 语句，减少锁冲突等等。
11. 注意事项：生产环境的使用
在生产环境中使用 pstack 时，需要注意以下几点：
- 尽量避免高峰期使用：
pstack会暂停目标进程的执行，虽然时间很短，但在高峰期可能会对性能产生影响。 - 小心使用 root 权限： 使用 root 权限执行
pstack时，需要确保不会对系统安全造成威胁。 - 保护敏感信息：
pstack的输出信息可能包含敏感信息，例如密码、用户名等等，需要妥善保管。 - 不要频繁执行： 频繁执行
pstack可能会对性能产生累积影响。
12. 调试符号表的重要性
调试符号表包含了程序中函数名、变量名、文件名、行号等调试信息。 如果 MySQL 进程在编译时没有包含调试符号表，pstack 只能显示函数的地址，而无法显示函数名和文件名，这会大大降低 pstack 的可用性。
因此，建议在编译 MySQL 时包含调试符号表，例如使用 -g 选项。
13. 更多选项与高级用法
pstack 还有一些其他的选项，可以提供更多的信息：
-l：显示 LWP (lightweight process) ID，也就是线程 ID。-s：显示信号掩码。-v：显示更详细的信息。
此外，还可以将 pstack 的输出信息保存到文件中，以便后续分析：
pstack <pid> > pstack.log14. 总结与扩展
pstack 是一个非常实用的 MySQL 性能诊断工具，可以帮助我们深入到进程内部，查看线程的调用堆栈，从而定位问题的根源。 通过结合 Performance Schema 和其他性能监控工具，我们可以更全面地了解 MySQL 的运行状态，并进行有针对性的优化。 熟练掌握 pstack 的使用方法，可以大大提高我们排查 MySQL 性能问题的效率。
希望今天的分享能够帮助大家更好地理解和使用 pstack 工具。
Pstack 的强大之处在于其能够深入到进程内部，展示线程的函数调用链，为性能诊断提供关键线索。
结合 Performance Schema 的监控数据，可以更精准地定位性能瓶颈，并进行针对性优化。
熟练掌握 Pstack 的使用，能有效提升 MySQL 性能问题排查效率，成为 DBA 工具箱中的利器。