高性能MySQL：捕获诊断数据（3），高性能MySQL：捕获诊断数据（1）[2]...
高性能MySQL：捕获诊断数据（3）
捕获诊断数据（ ） 堆栈需要自下而上来看 也就是说 线程当前正在执行的是pthread_cond_wait 函数 这是由os_event_wait_low 调用的 继续往下 看起来是线程试图进入到InnoDB 内核（srv_conc_enter_innodb） 但被放入了一个内部队列中（os_event_wait_low） 原因应该是内核中的线程数已经超过innodb_thread_concurrency 的限制 当然 要真正地发挥堆栈跟踪的价值需要将很多的信息聚合在一起来看 这种技术是由Domas Mituzas推广的 他以前是MySQL 的支持工程师 开发了著名的穷人剖析器 poor man sprofiler 他目前在Facebook 工作 和其他人一起开发了更多的收集和分析堆栈跟踪的工具 可以从他的这个网站发现更多的信息 // poormansprofiler 在Percona Toolkit 中我们也开发了一个类似的穷人剖析器 叫做pt pmp 这是一个用shell 和awk 脚本编写的工具 可以将类似的堆栈跟踪输出合并到一起 然后通过sort|uniq|sort 将最常见的条目在最前面输出 下面是一个堆栈跟踪的完整例子 通过此工具将重要的信息展示了出来 使用了 l 选项指定了堆栈跟踪不超过 层 以免因太多前面部分相同而后面部分不同的跟踪信息而导致无法聚合到一起的情况 这样才能更好地显示到底在哪里产生了等待 $ pt pmp l stacktraces txt pthread_cond_wait one_thread_per_connection_end handle_one_connection start_thread clone pthread_cond_wait os_event_wait_low srv_conc_enter_innodb innodb_srv_conc_enter_innodb ha_innodb::index_read pthread_cond_wait os_event_wait_low sync_array_wait_event mutex_spin_wait mutex_enter_func pthread_cond_wait os_event_wait_low os_aio_simulated_handle fil_aio_wait io_handler_thread pthread_cond_wait os_event_wait_low srv_conc_enter_innodb innodb_srv_conc_enter_innodb ha_innodb::general_fetch pthread_cond_wait os_event_wait_low sync_array_wait_event rw_lock_s_lock_spin rw_lock_s_lock_func sigwait signal_hand start_thread clone ?? select os_thread_sleep srv_lock_timeout_and_monitor_thread start_thread clone select os_thread_sleep srv_error_monitor_thread start_thread clone select handle_connections_sockets main read vio_read_buff ::?? my_net_read cli_safe_read pthread_cond_wait os_event_wait_low sync_array_wait_event rw_lock_x_lock_low rw_lock_x_lock_func pthread_cond_wait MYSQL_BIN_LOG::wait_for_update mysql_binlog_send dispatch_mand do_mand fsync os_file_fsync os_file_flush fil_flush log_write_up_to 第一行是MySQL 中非常典型的空闲线程的一种特征 所以可以忽略 第二行才是最有意思的地方 看起来大量的线程正在准备进入到InnoDB 内核中 但都被阻塞了 从第三行则可以看到许多线程都在等待某些互斥锁 但具体的是什么锁不清楚 因为堆栈跟踪更深的层次被截断了 如果需要确切地知道是什么互斥锁 则需要使用更大的 l 选项重跑一次 一般来说 这个堆栈跟踪显示很多线程都在等待进入到InnoDB 这是为什么呢？这个工具并不清楚 需要从其他的地方来入手 从前面的堆栈跟踪和oprofile 报表来看 如果不是MySQL 和InnoDB 源码方面的专家 这种类型的分析很难进行 如果用户在进行此类分析时碰到问题 通常需要求助于这样的专家才行 在下面的例子中 通过剖析和等待分析都无法发现服务器的问题 需要使用另外一种不同的诊断技术 返回目录 高性能MySQL 编辑推荐 ASP NET开发培训视频教程 数据仓库与数据挖掘培训视频教程 lishixinzhi/Article/program/MySQL/201311/29698
高性能MySQL：捕获诊断数据（1）[2]
需要收集什么样的数据 现在已经确定了诊断触发器 可以开始启动一些进程来收集数据了 但需要收集什么样的数据呢？就像前面说的 答案是尽可能收集所有能收集的数据 但只在需要的时间段内收集 包括系统的状态 CPU 利用率 磁盘使用率和可用空间 ps 的输出采样 内存利用率 以及可以从MySQL 获得的信息 如SHOW STATUS SHOW PROCESSLIST 和SHOWINNODB STATUS 这些在诊断问题时都需要用到（可能还会有更多） 执行时间包括用于工作的时间和等待的时间 当一个未知问题发生时 一般来说有两种可能 服务器需要做大量的工作 从而导致大量消耗CPU ;或者在等待某些资源被释放 所以需要用不同的方法收集诊断数据 来确认是何种原因 剖析报告用于确认是否有太多工作 而等待分析则用于确认是否存在大量等待 如果是未知的问题 怎么知道将精力集中在哪个方面呢？没有更好的办法 所以只能两种数据都尽量收集 在GNU/Linux 平台 可用于服务器内部诊断的一个重要工具是oprofile 后面会展示一些例子 也可以使用strace 剖析服务器的系统调用 但在生产环境中使用它有一定的风险 后面还会继续讨论它 如果要剖析查询 可以使用tcpdump 大多数MySQL 版本无法方便地打开和关闭慢查询日志 此时可以通过监听TCP 流量来模拟 另外 网络流量在其他一些分析中也非常有用 对于等待分析 常用的方法是GDB 的堆栈跟踪注 MySQL 内的线程如果卡在一个特定的地方很长时间 往往都有相同的堆栈跟踪信息 跟踪的过程是先启动gdb 然后附加（attach）到mysqld 进程 将所有线程的堆栈都转储出来 然后可以利用一些简短的脚本将类似的堆栈跟踪信息做汇总 再利用sort|uniq|sort 的 魔法 排序出总计最多的堆栈信息 稍后将演示如何用pt pmp 工具来完成这个工作 也可以使用SHOW PROCESSLIST 和SHOW INNODB STATUS 的快照信息观察线程和事务的状态来进行等待分析 这些方法都不完美 但实践证明还是非常有帮助的 收集所有的数据听起来工作量很大 或许读者之前已经做过类似的事情 但我们提供的工具可以提供一些帮助 这个工具名为pt collect 也是Percona Toolkit 中的一员 pt collect 一般通过pt stalk 来调用 因为涉及很多重要数据的收集 所以需要用root 权限来运行 默认情况下 启动后会收集 秒的数据 然后退出 对于大多数问题的诊断来说 这已经足够 但如果有误报（false positive）的问题出现 则可能收集的信息就不够 这个工具很容易下载到 并且不需要任何配置 配置都是通过pt stalk 进行的 系统中最好安装gdb 和oprofile 然后在pt stalk 中配置使用 另外mysqld 也需要有调试符号信息注 当触发条件满足时 pt collect 会很好地收集完整的数据 它也会在目录中创建时间戳文件 在本书写作之际 这个工具是基于GNU/Linux 的 后续会迁移到其他操作系统 这是一个好的开始 解释结果数据 如果已经正确地设置好触发条件 并且长时间运行pt stalk 则只需要等待足够长的时间来捕获几次问题 就能够得到大量的数据来进行筛选 从哪里开始最好呢？我们建议先根据两个目的来查看一些东西 第一 检查问题是否真的发生了 因为有很多的样本数据需要检查 如果是误报就会白白浪费大量的时间 第二 是否有非常明显的跳跃性变化 在服务器正常运行时捕获一些样本数据也很重要 而不只是在有问题时捕获数据 这样可以帮助对比确认是否某些样本 或者样本中的某部分数据有异常 例如 在查看进程列表（process list）中查询的状态时 可以回答一些诸如 大量查询处于正在排序结果的状态是不是正常的 的问题 查看异常的查询事务的行业 以及异常的服务器内部行业通常都是最有收获的 查询或事务的行为可以显示是否是由于使用服务器的方式导致的问题 性能低下的SQL查询 使用不当的索引 设计糟糕的数据库逻辑架构等 通过抓取TCP 流量或者SHOWPROCESSLIST 输出 可以获得查询和事务出现的地方 从而知道用户对数据库进行了什么操作 通过服务器的内部行为则可以清楚服务器是否有bug 或者内部的性能和扩展性是否有问题 这些信息在类似的地方都可以看到 包括在oprofile 或者gdb 的输出中 但要理解则需要更多的经验 如果遇到无法解释的错误 则最好将收集到的所有数据打包 提交给技术支持人员进行分析 MySQL 的技术支持专家应该能够从数据中分析出原因 详细的数据对于支持人员来说非常重要 另外也可以将Percona Toolkit 中另外两款工具pt mysql summary 和pt summary 的输出结果打包 这两个工具会输出MySQL 的状态和配置信息 以及操作系统和硬件的信息 Percona Toolkit 还提供了一款快速检查收集到的样本数据的工具 pt sift 这个工具会轮流导航到所有的样本数据 得到每个样本的汇总信息 如果需要 也可以钻取到详细信息 使用此工具至少可以少打很多字 少敲很多次键盘 返回目录 高性能MySQL 编辑推荐 ASP NET开发培训视频教程 数据仓库与数据挖掘培训视频教程 Oracle索引技术 lishixinzhi/Article/program/MySQL/201311/29701
下一篇：没有了
