1.性能问题定位
系统信息
- /proc虚拟目录,是内存的映射
- cat /proc/version
- cat /proc/cpuinfo
- cat /proc/meminfo free -m
- df -h
CPU占用高
- top 找到异常java进程的pid
- top -Hp pid --- 查看进程中CPU或着MEM占用较高的线程
- printf "%x\n" 42746 ---线程转成十六进制
- jstack 25720 | less --- 进程的堆栈信息,找线程(十六进制)
- jmap -histo 25720 | head -n 100 查看实例最多的可疑对象
内存占用高
- jmap -heap 21957 -- 打印heap的概要信息,GC使用的算法,heap的配置及使用情况,可以用此来判断内存目前的使用情况以及垃圾回收情况
- jmap -histo 21957 | head -n 100 -- 打印堆的对象统计,包括对象数、内存大小等等
- jmap -histo:live 21957 | head -n 100 -- 会触发一次FGC后,收集统计信息
检查项
- gc:
jstat -gcutil 25720 1000 -- gc情况 - io:
iostat -d -x -k 1 10 - 与数据库连接:
pid: netstat -anp | grep 21643
port: netstat -anp | grep 3306
响应慢
线上问题
- CPU占用过高
耗cpu的代码
线程空转 - MEM占用过高
- java进程挂掉了
- 数据库CPU告警
没有索引惹的祸
线上操作使用命令要小心
- jmap,jstack等
- vi 大文件
vi 1个多G的日志文件,刚打开时
2.--MEM占用过高
业务对象占用
ibatis,jdbc,OrgUserDO,DingtalkOapiEmployeeListResponse$EmpFieldVO
代码块
Plain Text
1
5: 2213141 123935896 org.apache.ibatis.mapping.ParameterMapping
2
9: 243070 31112960 com.dingtalent.salary.dal.model.OrgUserDO
3
10: 1641498 26263968 com.alibaba.druid.proxy.jdbc.JdbcParameterString
4
12: 1164 21258760 [Lcom.alibaba.druid.proxy.jdbc.JdbcParameter;
5
17: 438456 14030592 com.dingtalk.top.api.service.isv.response.DingtalkOapiEmployeeListResponse$EmpFieldVO
POI对象占用
老年代 2个G,猜测可能的原因
- excel本质上是xml文件的集合体。从office 2007起开始使用xml来存档和数据交换。
- poi默认是使用dom方式解析excel,因此文件中String的数量越多,其dom树越大。
手动触发一次FGC后恢复正常
3.nginx的access.log,error.log自动按天切割
nginx 1.16版本开始自带了日志切割功能
但是目前我们线上的nginx都是1.12版本。目前有集中办法可以做到按天切割。
第一种方法:通过shell脚本+crontab定时任务自动扫描
第二种方法:通过linux自带的logrotate实现
编辑/etc/logrotate.d/nginx文件,内容替换为下面内容(含义是:日志按天分割,最多保留15份,10m以下的不处理,执行完了分割以后reload nginx,防止日志不写到新的文件中)
/home/admin/logs/nginx/*.log{
daily
rotate 15
minsize 10M
sharedscripts
postrotate
sudo service nginx reload>/dev/null 2>&1
endscript
}
然后执行sudo/usr/sbin/logrotate /etc/logrotate.conf 重新加载
另附上邵庆的建议:日志应该放在单独挂载在单独的磁盘中
4.通过haproxy让外网可以访问rds(mysql数据库)