线上故障排查思路

思想者001

已于 2022-04-19 14:39:08 修改

阅读量2.2k

点赞数

分类专栏：数据库文章标签： mysql 数据库 java

于 2022-03-11 15:19:25 首次发布

本文链接：https://blog.csdn.net/zhouwenjun0820/article/details/123425774

版权

数据库专栏收录该内容

19 篇文章 0 订阅

订阅专栏

思维导图

在这里插入图片描述

MySQL 排查常用命令

# 查询慢SQL查询是否开启
show variables like 'slow_query_log';
# 查询慢SQL的时间
show variables like 'long_query_time';
# 查看慢SQL存放路径，一般：/home/mysql/data3016/mysql/slow_query.log
show variables like 'slow_query_log_file';


# 查看数据库的事务隔离级别,RDS:READ-COMMITTED   Mysql:Repeatable read
show variables like 'tx_isolation'; 
 # innodb数据页大小  16384
show variables like 'innodb_page_size'; 

show status  like 'innodb_row_%';

# 查看慢SQL
SHOW SLOW limit 10;
show full slow limit 10;

# 查看autocommit配置
select @@autocommit; 
 # 同上
show variables like 'autocommit'; 
#设置SQL自动提交模式  1:默认,自动提交   0:需要手动触发commit,否则不会生效
set autocommit=1;　　
# 查看默认的搜索引擎
show variables like '%storage_engine%'; 

# 设置事务隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

CPU飙高怎么办？

我们有个线上应用，单节点在运行一段时间后，CPU 的使用会飙升，一旦飙升，一般怀疑某个业务逻辑的计算量太大，或者是触发了死循环（比如著名的 HashMap 高并发引起的死循环），但排查到最后其实是 GC 的问题。

（1）使用 top 命令，查找到使用 CPU 最多的某个进程，记录它的 pid。使用 Shift + P 快捷键可以按 CPU 的使用率进行排序。

（2）再次使用 top 命令，加 -H 参数，查看某个进程中使用 CPU 最多的某个线程，记录线程的 ID。

top -Hp $pid

（3）使用 printf 函数，将十进制的 tid 转化成十六进制。

printf %x $tid

（4）使用 jstack 命令，查看 Java 进程的线程栈。

jstack $p i d >$ pid.log

（5）使用 less 命令查看生成的文件，并查找刚才转化的十六进制 tid，找到发生问题的线程上下文。我们在 jstack 日志搜关键字DEAD，以及中找到了 CPU 使用最多的几个线程id。

（6）看到问题发生的根源，是我们的堆已经满了，但是又没有发生 OOM，于是 GC 进程就一直在那里回收，回收的效果又非常一般，造成 CPU 升高应用假死。接下来的具体问题排查，就需要把内存 dump 一份下来，使用 MAT 等工具分析具体原因了。

内存溢出 | Cache调优

内存溢出是一个结果，而内存泄漏是一个原因。内存溢出的原因有内存空间不足、配置错误等因素。一些错误的编程方式，不再被使用的对象、没有被回收、没有及时切断与 GC Roots 的联系，这就是内存泄漏。

（1）HashMap 缓存
使用HashMap 做了一个无界缓存，没有设置超时时间或者 LRU 策略，在使用上又没有重写key类对象的hashcode和equals方法，对象无法取出也直接造成了堆内存占用一直上升，后来，将这个缓存改成 guava 的 Cache，并设置了弱引用，故障就消失了。
即使提供了 equals 方法和 hashCode 方法，也要非常小心，尽量避免使用自定义的对象作为 Key。

（2）文件未关闭
再看一个例子，关于文件处理器的应用，在读取或者写入一些文件之后，由于发生了一些异常，close 方法又没有放在 finally 块里面，造成了文件句柄的泄漏。由于文件处理十分频繁，产生了严重的内存泄漏问题。

（3）死循环导致局部缓存一直无法被回收