一、发现问题的系统检查
一个管理平台门户网页进行统计页面提示请求超时，随进服务器操作系统 top 命令进行检查load average的负载状况
二、定位故障
根据这种故障的一般处理思路，先找出问题进程内CPU占用率高的线程，再通过线程信息找出该线程当时在运行的问题代码端
根据思路查看高占用的进程中占用高的线程
追踪发现某个进程中的的某个线程占用较高
]# top -Hbp PID | awk '/进程名/ && $9>10'
将PID对应占用高的线程ID转为16进制的线程ID
]# printf '%x\n' 线程ID
输出16进制的线程ID
通过 jvm的 jstack查看进程信息，发现调用的是哪个服务的问题
]# jstack 进程ID | grep '16进制的线程ID' -A 30
既然查出来了就检查该应用服务
思路是先打印所有在跑的服务线程，检查后发现跟进情况找到问题所在
- 举例：
]# top -Hbp 7163 | awk '/java/ && $9>50' #7163占用高的进程Id
]# printf '%x\n' 16298 #16298 为7163进程中线程占用较高的
输出 3faa
]# jstack 7163 | grep '3faa' -A 30 #匹配后的30行
发现是数据库的问题，打印所有在跑的数据库线程，检查并发现情况找到问题表
1.打印mysql现有进程信息，并生成log文件
]# mysql -uroot -p -e 'show full processlist' > mysql_fill_process.log
2.过滤log文件发现查询最多的表
grep Query mysql_fill_process.log
3.确认表中的数据，发现表中已经有将近300万条数据，判断是查询时间过长导致的
> use databases_name;
> select count(1) from table_name;
4.确认表是否有索引，发现表未创建索引
> show create table table_name\G
三、确认及处理问题
询问该表的数据是否重要，确认不重要，检查字段有时间字段，根据时间确认只留一个人的数据
> delete from tabel_name where xxx_time < '2019-09-01 00:00:00' or xxx_time is null;
由于表未加索引，给表创建索引
> alter table table_nam add index (device_uid);
检查索引
> show create table table_name;
四、结果
处理后进程的CPU占用到了40%。本次排查用到了jvm进程查看及dump进程详细信息的操作，确认问题、原因，对其进行处理。
五、其他
处理完问题后，查询一下相关问题的优化
如：有方案说在mysql配置文件添加innodb_buffer_pool_size参数，可以优化查询时间,但该参数的意义吧数据放到了内存，也就是说数据更新了，还会导致buffer失效，通常优化还是添加索引
innodb_buffer_pool_size=4G
