最近在做性能调优,我采取的策略是以应用为中心,优先分析应用,再分析中间件,步骤如下:
- 先保证应用的功能是正常的,也就是说应用本身的业务处理逻辑是没有bug的,否则在排查性能问题的时候容易走偏,我也掉了这个坑.
- 接下来使用visual VM监控服务器的cpu和内存,这里说一下如果是监控内存的和gc的情况可以再下载一个插件visual gc, 然后把线程dump出来,进一步通过调用栈看在哪一步有耗时.
- 根据上一步的耗时分析,解析的结果可能是数据库,redis,我的应用本身没有多线程并发处理等情况,通过explain命令查看数据库查询是否又慢查询,如果有的话可以仔细分析并添加对应的index并确认是起作用的.
- 这里重点是排查了redis的查询,登录上去,然后
redis-cli -h 127.0.0.1 -p 6379 -a 密码
- 此时进入了redis命令行界面,执行
可以看到所有的慢语句执行记录以及对应的耗时.slowlog get
-
参数解释
1) (integer) 14 # 唯一性(unique)的日志标识符 2) (integer) 1522808219 # 被记录命令的执行时间点,以 UNIX 时间戳格式表示 3) (integer) 16 # 查询执行时间,以微秒为单位 4) 1) "keys" # 执行的命令,以数组的形式排列 2) "*" # 这里完整的命令是 "keys *"
然后通过上面的执行时间进行排除和整理,可以通过命令设置要看多少条
SLOWLOG LEN
通过
slowlog get 5
这里以5条为例,会列出每条指令执行的时长,然后根据具体的业务场景进行调整,如果想重新开始抓取log,需要执行
SLOWLOG RESET
这样就可以重新开始记录慢日志信息,然后开始查看,在这个地方发现了一个问题,如果get的时候不加任何参数会有很多的记录,想把日志拖到本地来看一下,研究了一下可以通过执行如下命令解决
slowlog get > slowlog.txt
大概就是根据这些方法取排查,性能方面的问题排查没有太多的经验,想学更多.