本文通过两次服务出现CPU100%问题的实例，阐述了排查和解决这类问题的思路。首先，检查服务及数据库的资源使用情况，发现内存使用过高。接着，通过日志分析定位到问题原因，如用户请求导致内存溢出或堆内存设置不合理。最后，提出了解决方案，包括参数校验、堆内存调整和预留系统资源，强调了内存使用率保持在60%-80%的高效区间，并推荐了监控和分析工具。
一天，业务突然反馈说服务没法访问，于是我把java服务的堆内存dump出来，赶紧重启服务，毕竟让业务恢复正常是第一紧急的。重启完服务开始分析原因，调取了服务监控信息，发现cpu突然在一个时间点飙升到100%了，又看了数据库所在的服务器监控信息，数据库的cpu和内存都是正常的，cpu使用率在同一个时间点有所提升，但不是很明显
服务所在的服务器cpu和内存使用情况：
数据库所在的服务器cpu和内存使用情况：
于是，开始查这个时间点附近的日志，这个服务没有定时任务，所以这个可能性排除，那剩余的就是用户请求和mq消息处理了，于是挨个看每条日志，突然一个可疑的日志出现在眼前：
2022-03-26 16:55:48.304 [xxx] [0a000c1e16482849483047016] [http-nio-9077-exec-7-http-nio-9077-exec-7] INFO - 用户发起请求,请求方法:XXXmethod,请求参数:[{}] 这个请求前端传了空的map，于是我开始找到后端对应的代码，发现后端没有对参数做校验，这个参数缺失最终导致把表的全部数据加载到内存了，然后服务就直接OOM了。
接下来就是解决问题，找到原因解决起来就轻松多了，对参数加上校验，问题解决。
2023.11.7 今天再次遇到了cpu100%的问题，经查是由于堆内存设置过大导致的，
机器是8C16G(实际上物理内存只有15G)，部署了4个应用，4个应用堆内存一共用掉12G，再加系统本来和jvm使用的其他内存，内存使用率达到90%多，一开始也发现内存使用率偏高，但是没有太重视这个问题。结果今天就出现了服务响应超时的情况，一看内存使用率已经100%了，然后找运维重新调整了堆内存，下调到8G，再观察内存使用率稳定在66%-72%之间。所以堆内存的设置并不是越大越好，要给机器预留一些内存空间。
根据平时的维护经验来看，物理内存资源占用在60%-80%时使用效率很高。大约20%-40%的内存需要预留，其中一部分内存给系统缓冲，还有一部分内存以备用流量突发等异常情况。这样可以防止所有资源被进程占用而系统无法执行处理任务，以致于程序被强制终止，出现服务器卡死或死机等情况。
总结下解决的思路：
1.首先检查服务的cpu，内存，磁盘，网络带宽，负载是不是正常
2.检查数据库的cpu，内存，磁盘，网络带宽，负载是不是正常
3.如果是服务cpu100%，检查下发生问题的时间点有没有定时任务执行，或者那个时间段业务量是不是突然增高，比如大量图片压缩，几百万行数据转json或者利用反射转对象，或者某个请求加载了大量数据。
4.如果是数据库cpu100%，检查下是不是有慢查询，导出慢查询日志分析下。
5.检查下堆内存是否存在内存泄漏，可以用MAT，或者JVisualVM分析，另外推荐一个不错的工具arthas，可以很方便排查线上问题。
扫一扫
1064
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
