系统慢看cpu和内存，报错看日志，接口慢也看日志。

而且日志没错，返回的数据正确肯定是前端的问题。

实在是找不到报错，用户也忘了报错的时间，就让他再复现一次错误，我们这边再去看日志。

 

测试系统去debug

 

接口慢：

第一步习惯性看jvm有没有异常，服务器的spu和内存都看看。

先用arthas

第二步使用explain排查索引命中情况。

第三步优化代码，是否能异步处理

 

整个系统变慢：

看jvm，服务器的cpu和内存

 

接口报错：

问客户报错的时间点，报错的频率，报错的截图。看日志，用grep关键字过滤error和时间点，（不然会过滤出全部的error），然后再使用grep -c过滤刚才报错中的关键字的上下文，看报错原因，看是第几行代码。

特别紧急的话，先回滚版本。再去解决。

 

 

 

 

 

 

 

慢sql

第一步：开启慢查询日志

第二步：设置阈值

第三步：日志记录后，使用explain进行分析。

有没有用到索引，像多表的关联字段，条件查询字段，能走索引尽量走索引。

创建索引：creat index 索引名 on 表名（字段名）

优化sql：尽量走覆盖索引

 

文件导入导出

 

文件大的话很容易内存溢出

可以逐行处理，避免一次性把文件的所有内容加载到内存

也要检查一下堆内存大小，经常导入导出，1g很容易就不够用了啊

 

jvm

正常full gc可能几个小时几天才做一次，那几分钟做一次肯定对网站性能有影响

 

分析gc日志尽量用工具，自己看还是很复杂的

 

开启gc日志，用GCViewer工具看下full gc频率，每次full gc的执行时间，比如每次3秒，每次用户卡3秒就体验很不好，对网站性能就有很大的影响。

 

full gc后，老年代内存使用率在80%以上，很有可能有内存泄漏的问题

 

像集合的list，map，这种集合很容易内存溢出

 

工具：visualvm，jconsole，jmp（线上导出dump文件，系统会停顿），MAT

 

---------------------------------------------------------------------------------------------

堆，栈，元空间（永久代）

总内存 ≈ 堆内存 (-Xmx) + (线程数量 × -Xss) + 其他

-xmx=最大堆内存

-xms=初始堆内存

-xss=栈大小

-xx：这个参数设置的东西挺多

 

“-XX:SurvivorRatio” 默认值为8.伊甸园：s0：s1=8：1：1

“-XX:NewRatio”：默认值是2.老年代/新生代=2

 

早生夕死的对象坚决不能进入老年代

不能因为survivor区太小导致直接进入老年代

 

动力节点把新生代的年龄15岁改成5岁，我服了。

 

堆大小小于6g，使用cms垃圾回收器，大于等于6g，使用g1垃圾回收器

"XX:+UseConcMarkSweepGC"：老年代使用cms垃圾回收器

"XX:+UseParNewGC"：新生代使用ParNew垃圾回收器

 

 

 

 

 

 

 

服务器cpu飙高

top查看占cpu高的java进程

jstack 进程号 > xxx.txt  把线程堆栈输出到xxx.txt文件

top -H -p 进程号  找到进程中占cpu高的线程

线程号转16进制，然后去xxx.txt文件中搜索，找我们的包名，定位到代码行

 

服务器内存飙高

top+  （shift+m）内存排序。可以找到占内存大的进程

jps：看下是哪个jar包，就知道是哪个项目了

jmap -histo 进程号：打印堆的使用情况

jmap -histo 进程号 | grep '包名'。类太多了，过滤出我们的包名，找到哪个类的对象多。

jmap -dump:format=b,file=heap.hprof pid，把进程堆内存快照（Heap Dump）导出来（注意，这个文件有可能很大，线上导出必须谨慎），人家说把其中一个服务器从负载均衡上摘下来，再去执行这个命令。

后面动力节点用MAT工具分析gc root找到代码

 

-histo查看堆内存中的对象实例数目，内存占用大小，类名等。

 

我悟了，这个就是排查内存泄漏的吧

 

日志排查：

一般其他部门的邮件过来说有bug，

tail -n 500 supply.log，这个命令适合日志少的文件，有些项目日志实在太多，不好找error。
cat supply.log | grep "09:1[5-9]"，这个命令查看九点15到九点19的日志，也不一定找得到。

cat supply.log | grep "0[8-9]" | grep -i "error"，这个命令就很好用，过滤时间和关键字'error'。
grep -C 10 "ACTION_DATE" supply.log，找到出bug的字段ACTION_DATE，然后查看上下文，-C就是查看日志上下文的命令。

（第一次不熟练，其实直接过滤时间和查看error关键字的上下文就行）
 

-------

日志太大，用tail也找不到，一定要过滤时间，不然真的找不到的。