发布于 由admin

如何通过 `Pstack` 和 `GDB` 等`工具`对`MySQL`进程进行`栈跟踪`和`故障`诊断？

好的，下面进入正题。

MySQL 进程栈跟踪与故障诊断：Pstack 和 GDB 实战

各位同学，大家好！今天我们来深入探讨一下如何利用 pstack 和 gdb 这两个强大的工具对 MySQL 进程进行栈跟踪和故障诊断。在实际的生产环境中，MySQL 数据库出现问题是不可避免的，掌握这些技能对于快速定位问题、减少损失至关重要。

1. 为什么要进行栈跟踪？

当 MySQL 进程出现 hang 住、崩溃、性能下降等异常情况时，仅仅通过查看日志文件往往无法直接找到问题的根源。栈跟踪，也称为堆栈回溯（stack trace），可以帮助我们了解进程在特定时刻的函数调用关系，从而追踪到问题的源头。

简单来说，栈跟踪就是记录了程序在执行过程中，每个函数被调用的顺序和位置。通过分析栈跟踪信息，我们可以：

  • 定位崩溃点： 知道程序崩溃发生在哪个函数中。
  • 了解调用链： 知道崩溃函数是被哪些函数调用的，以及调用路径。
  • 分析死锁原因： 多个线程同时请求资源，导致相互等待，形成死锁。栈跟踪可以揭示线程之间的资源竞争关系。
  • 性能瓶颈分析： 某些函数执行时间过长，导致性能下降。栈跟踪可以帮助我们找到耗时函数。

2. 工具介绍：Pstack 和 GDB

  • Pstack： 一个简单易用的工具，用于打印进程的栈跟踪信息。它不需要停止进程，属于非侵入式的诊断方法。
  • GDB (GNU Debugger)： 一个强大的调试器，可以用于调试各种程序，包括 MySQL。GDB 提供了更多的功能，例如设置断点、单步执行、查看变量值等，但同时也需要停止进程，属于侵入式的诊断方法。
工具 优点 缺点 适用场景
Pstack 简单易用，非侵入式，不会影响 MySQL 服务的正常运行。 信息有限，只能打印栈跟踪信息，无法进行更深入的调试。 适用于快速查看 MySQL 进程的栈跟踪信息，初步判断问题类型，例如 hang 住、死锁等。
GDB 功能强大，可以进行深入的调试，例如设置断点、单步执行、查看变量值等。 需要停止进程，可能会影响 MySQL 服务的正常运行；学习曲线较陡峭，需要一定的调试经验。 适用于需要深入分析 MySQL 进程的内部状态，例如定位崩溃点、分析死锁原因、性能瓶颈等。在测试环境或可以接受服务中断的情况下使用。

3. Pstack 实战

3.1 安装 Pstack

在大多数 Linux 发行版中，pstack 通常包含在 gdb 或 binutils 包中。如果没有安装，可以通过以下命令安装：

# Debian/Ubuntu
sudo apt-get install gdb

# CentOS/RHEL
sudo yum install gdb

3.2 使用 Pstack

  1. 找到 MySQL 进程 ID：

    可以使用 ps 命令或者 pgrep 命令找到 MySQL 进程的 ID。

    ps -ef | grep mysqld
# 或者
pgrep mysqld

    假设 MySQL 进程 ID 为 12345。

  2. 运行 Pstack：

    pstack 12345

    pstack 会打印出进程 12345 中所有线程的栈跟踪信息。

3.3 Pstack 输出分析

pstack 的输出信息包含了线程 ID 和栈帧信息。每个栈帧对应一个函数调用。

一个典型的 pstack 输出如下所示：

Thread 1 (Thread 0x7f7a20e1a700 (LWP 12345)):
#0  0x00007f7a208b842d in epoll_wait () from /lib64/libc.so.6
#1  0x0000000000e1a8a7 in mysqld_epoll_wait (epfd=12, events=0x7f7a20e19dd0, maxevents=1024, timeout=1000) at /path/to/mysql/source/sql/mysqld.cc:5778
#2  0x0000000000e1b691 in handle_connection (arg=0x558796a23220) at /path/to/mysql/source/sql/mysqld.cc:6120
#3  0x000000000103f817 in pfs_spawn_thread (arg=0x558796a23220) at /path/to/mysql/source/storage/perfschema/pfs.cc:2910
#4  0x0000003269007aa1 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f7a208c3bcd in clone () from /lib64/libc.so.6
  • Thread ID： Thread 1 表示线程 ID，0x7f7a20e1a700 是线程的十六进制标识符，LWP 12345 是线程的 Linux 线程 ID。
  • 栈帧： 每个 # 开头的行表示一个栈帧。
    • #0 表示栈帧编号，从 0 开始，表示栈顶。
    • 0x00007f7a208b842d 表示函数的地址。
    • in epoll_wait () from /lib64/libc.so.6 表示函数名和函数所在的库文件。
    • at /path/to/mysql/source/sql/mysqld.cc:5778 表示函数所在的源文件和行号（如果可用）。

分析示例：

上面的 pstack 输出显示，线程 1 当前正在 epoll_wait 函数中等待事件。这通常表示线程正在等待网络连接或 I/O 操作。如果所有线程都处于等待状态，并且 MySQL 进程长时间没有响应，那么可能存在死锁或性能瓶颈。

3.4 Pstack 结合符号表

如果 pstack 输出的函数名都是地址，而不是符号名，那么需要确保 MySQL 编译时包含了调试信息，并且 pstack 能够找到符号表。

  1. 确认 MySQL 编译时包含调试信息：

    通常，MySQL 的 Debug 版本会包含调试信息。可以通过查看 MySQL 的编译选项来确认。

  2. 确保 Pstack 能够找到符号表：

    • 如果 MySQL 安装在标准位置，pstack 通常可以自动找到符号表。
    • 如果 MySQL 安装在非标准位置，可以通过设置 LD_LIBRARY_PATH 环境变量来告诉 pstack 符号表的位置。
    export LD_LIBRARY_PATH=/path/to/mysql/lib:$LD_LIBRARY_PATH
pstack 12345

    其中 /path/to/mysql/lib 是 MySQL 库文件所在的目录。

4. GDB 实战

4.1 安装 GDB

# Debian/Ubuntu
sudo apt-get install gdb

# CentOS/RHEL
sudo yum install gdb

4.2 使用 GDB

  1. 启动 GDB 并附加到 MySQL 进程：

    gdb -p 12345

    其中 12345 是 MySQL 进程 ID。

  2. 获取栈跟踪信息：

    在 GDB 提示符下，输入 bt 命令（backtrace 的缩写）获取栈跟踪信息。

    (gdb) bt

    GDB 会打印出当前线程的栈跟踪信息。

  3. 查看其他线程的栈跟踪信息：

    使用 info threads 命令查看所有线程的信息。

    (gdb) info threads
  Id   Target Id         Frame
  2    Thread 0x7f7a20e1a700 (LWP 12345) "mysqld" 0x00007f7a208b842d in epoll_wait () from /lib64/libc.so.6
* 1    Thread 0x7f7a20e1b000 (LWP 12346) "mysqld" 0x00007f7a208c3bcd in clone () from /lib64/libc.so.6

    * 表示当前线程。使用 thread <thread_id> 命令切换到其他线程。

    (gdb) thread 2
[Switching to thread 2 (Thread 0x7f7a20e1a700 (LWP 12345))]
#0  0x00007f7a208b842d in epoll_wait () from /lib64/libc.so.6
(gdb) bt

  4. 查看变量值：

    可以使用 print <variable_name> 命令查看变量的值。

    (gdb) frame 1  # 切换到栈帧 1
(gdb) print arg  # 打印 arg 变量的值

  5. 设置断点：

    可以使用 break <function_name> 命令在函数入口处设置断点。

    (gdb) break handle_connection

    当程序执行到 handle_connection 函数时，GDB 会暂停程序的执行。

  6. 单步执行：

    可以使用 next 命令单步执行程序，跳过函数调用。

    (gdb) next

    可以使用 step 命令单步执行程序，进入函数调用。

    (gdb) step

  7. 继续执行：

    可以使用 continue 命令继续执行程序。

    (gdb) continue

  8. 退出 GDB：

    可以使用 quit 命令退出 GDB。

    (gdb) quit

4.3 GDB 结合符号表

与 pstack 类似，如果 gdb 输出的函数名都是地址，而不是符号名，那么需要确保 MySQL 编译时包含了调试信息，并且 gdb 能够找到符号表。

  1. 启动 GDB 时指定符号表：

    可以使用 -s 选项指定符号表文件。

    gdb -p 12345 -s /path/to/mysql/bin/mysqld

  2. 在 GDB 中加载符号表：

    可以使用 symbol-file 命令加载符号表。

    (gdb) symbol-file /path/to/mysql/bin/mysqld

4.4 GDB 脚本

为了方便调试，可以将常用的 GDB 命令写成脚本，然后使用 source 命令执行脚本。

例如，创建一个名为 mysql_debug.gdb 的脚本，内容如下：

# 设置断点
break handle_connection

# 继续执行
continue

然后，在 GDB 提示符下执行脚本：

(gdb) source mysql_debug.gdb

5. 诊断案例

5.1 Hang 住

  1. 现象： MySQL 进程长时间没有响应，无法处理新的连接请求。
  2. 诊断步骤：
    • 使用 pstack 查看所有线程的栈跟踪信息。
    • 如果所有线程都处于等待状态，例如 epoll_wait 或 pthread_cond_wait，那么可能存在死锁或性能瓶颈。
    • 使用 gdb 附加到 MySQL 进程，查看线程之间的资源竞争关系。
    • 分析代码，找出导致死锁或性能瓶颈的原因。

5.2 崩溃

  1. 现象： MySQL 进程突然崩溃，服务中断。

  2. 诊断步骤：

    • 查看 MySQL 的错误日志，找到崩溃时的错误信息。
    • 使用 gdb 附加到 core 文件，获取崩溃时的栈跟踪信息。
    • 分析栈跟踪信息，找到崩溃点。
    • 分析代码，找出导致崩溃的原因。

    生成 Core 文件

    首先需要确保系统开启了 core dump 功能。可以通过以下命令查看：

    ulimit -c

    如果输出为 0，表示 core dump 功能未开启。可以通过以下命令开启：

    ulimit -c unlimited

    然后，需要修改 MySQL 的配置文件 /etc/my.cnf，添加以下配置：

    [mysqld]
core-file

    重启 MySQL 服务。

    当 MySQL 进程崩溃时，会在当前目录下生成一个名为 core 的文件。可以使用 gdb 附加到 core 文件进行调试。

    gdb /path/to/mysql/bin/mysqld core

5.3 死锁

  1. 现象： 多个线程同时请求资源，导致相互等待，形成死锁。

  2. 诊断步骤：

    • 查看 MySQL 的错误日志，找到死锁相关的错误信息。
    • 使用 gdb 附加到 MySQL 进程，查看线程之间的资源竞争关系。
    • 分析代码，找出导致死锁的原因。

    MySQL 提供了一个工具 InnoDB Monitor，可以用来检测死锁。可以通过以下命令开启：

    SET GLOBAL innodb_status_output = ON;
SET GLOBAL innodb_status_output_locks = ON;

    然后，查看 MySQL 的错误日志，可以找到 InnoDB Monitor 的输出信息，其中包含了死锁相关的详细信息。

6. 注意事项

  • 在生产环境中，尽量避免直接使用 gdb 附加到 MySQL 进程，因为这可能会影响 MySQL 服务的正常运行。
  • 如果需要使用 gdb 进行调试，建议在测试环境或可以接受服务中断的情况下进行。
  • 确保 MySQL 编译时包含了调试信息，以便 pstack 和 gdb 能够正确解析符号表。
  • 熟悉 MySQL 的源代码，可以更好地理解栈跟踪信息，从而更快地定位问题。
  • 使用 GDB 命令的时候，注意区分大小写，参数之间用空格分隔。

7. 案例代码

假设我们有以下代码模拟了一个简单的死锁场景：

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mutex1, mutex2;

void thread1() {
    mutex1.lock();
    std::cout << "Thread 1: locked mutex1" << std::endl;
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
    mutex2.lock();
    std::cout << "Thread 1: locked mutex2" << std::endl;
    mutex2.unlock();
    mutex1.unlock();
}

void thread2() {
    mutex2.lock();
    std::cout << "Thread 2: locked mutex2" << std::endl;
    std::this_thread::sleep_for(std::chrono::milliseconds(100));
    mutex1.lock();
    std::cout << "Thread 2: locked mutex1" << std::endl;
    mutex1.unlock();
    mutex2.unlock();
}

int main() {
    std::thread t1(thread1);
    std::thread t2(thread2);

    t1.join();
    t2.join();

    return 0;
}

这段代码中，thread1 先锁定 mutex1，然后尝试锁定 mutex2，而 thread2 先锁定 mutex2，然后尝试锁定 mutex1。由于两个线程的锁定顺序相反，因此可能会导致死锁。

编译代码：

g++ -g dead_lock.cpp -o dead_lock -pthread

运行代码：

./dead_lock

使用 GDB 调试：

  1. 找到进程 ID：

    ps -ef | grep dead_lock

    假设进程 ID 为 67890。

  2. 启动 GDB 并附加到进程：

    gdb -p 67890

  3. 查看所有线程的信息：

    (gdb) info threads
  Id   Target Id         Frame
  2    Thread 0x7f7a20e1a700 (LWP 67891) 0x00007f7a208b842d in __lll_lock_wait () from /lib64/libpthread.so.0
* 1    Thread 0x7f7a20e1b000 (LWP 67890) 0x00007f7a208c3bcd in clone () from /lib64/libc.so.6

  4. 切换到线程 2：

    (gdb) thread 2

  5. 获取栈跟踪信息：

    (gdb) bt
#0  0x00007f7a208b842d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f7a208b3164 in _L_lock_1043 () from /lib64/libpthread.so.0
#2  0x00007f7a208b3030 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000000000400d20 in thread2 () at dead_lock.cpp:22
#4  0x00007f7a208baea5 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f7a20924b0d in clone () from /lib64/libc.so.6

    从栈跟踪信息可以看出，线程 2 正在 pthread_mutex_lock 函数中等待锁。

  6. 切换到线程 1，重复步骤 5。

    (gdb) thread 1
    (gdb) bt
#0  0x00007f7a208b842d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007f7a208b3164 in _L_lock_1043 () from /lib64/libpthread.so.0
#2  0x00007f7a208b3030 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000000000400c10 in thread1 () at dead_lock.cpp:12
#4  0x00007f7a208baea5 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f7a20924b0d in clone () from /lib64/libc.so.6

    从栈跟踪信息可以看出，线程 1 也在 pthread_mutex_lock 函数中等待锁。

通过分析两个线程的栈跟踪信息，可以确定发生了死锁。线程 1 正在等待 mutex2，而线程 2 正在等待 mutex1。

8. 总结

今天我们学习了如何使用 pstack 和 gdb 对 MySQL 进程进行栈跟踪和故障诊断。希望大家能够在实际工作中灵活运用这些工具，快速定位问题，保障 MySQL 数据库的稳定运行。

9. 深入分析需要更多耐心和经验

掌握 pstack 和 gdb 是诊断 MySQL 问题的关键技能，通过实践和学习，可以更有效地解决实际问题。

10. 持续学习，不断提升

MySQL 的内部机制非常复杂，需要不断学习和实践才能掌握。希望今天的分享能够帮助大家更好地理解 MySQL 的工作原理，提升故障诊断能力。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注