记一次单个服务将cpu占满的问题排查

BetaRabbit 发布于2019-08-16 17:00 / 2529人阅读

摘要：一发生故障今天发现服务查询一直卡住，就看了一下服务器当时就愣住了就这一个服务就把占满了，再看了下端口号出现了大量的。

一、发生故障

今天发现服务查询一直卡住，就看了一下服务器：

当时就愣住了就这一个服务就把CPU占满了，再看了下端口号：

出现了大量的CLOSE_WAIT。看到这里我就只有一个想法：程序代码有问题或者是配置的问题

二、排查

为此我先重启了服务并加上参数用jconsole查看服务状况：
-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=10000
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

再打印GC日志：
-verbose:gc
-Xloggc:/usr/app/ydjAgent/gc_log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps

启动参数太长了我又把它添加到环境变量里：
vim /etc/profile

export JAVA_OPTS="-Xms1024m -Xmx4096m -Djava.rmi.server.hostname=120.0.0.1 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -verbose:gc -Xloggc:/usr/app/ydjAgent/gc_log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

根据jconsole概览和GC日志可以看的出，是因为系统频繁进行GC导致的：

一般情况下，young gc频繁是正常的，full gc如果非常频繁，一般情况下有问题的就是接口查询中的集合的数据，存起来了，一直没删除，导致gc没有及时回收。

然后将堆信息dump下来后用Eclipse memory analyze分析了一下，发现char[]数组和byte[]数组占了大部分内存。

综上分析后查明，因为业务需要统计一个月内的所有订单中的商品以及品牌排行，因为原有表的设计的主键id是UUID，服务在启动的时候只给了最大4G内存，即使是只查询订单id，都占了很大一部分空间，更别说后面查询出来的订单信息会占用更大的内存空间，而因为这样，数据库的压力和应用的压力也会很大，应用一直处于FULL GC状态，把cpu占满。

三、解决办法

因为该应用和数据库是在同一个服务器上，所以就先把应用部署到另一个服务器上然后用nginx通过内网将请求转发，把内存设置8G，缓解原来服务器的CPU压力，即便如此，在数据访问的时候还是对数据库造成了很大的压力。因为我代码写的太烂了哈哈。。事发之后先向老板做了汇报，老板表示理解。。给我时间去重新设计原有的架构。。。不说了写代码去。。。

混合云服务器托管记一次在阿里云搭建服务器记一次阿里云服务器集体中毒服务器一般问题排查 apache问题排查

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/74324.html

记一次单个服务将cpu占满的问题排查

摘要：一发生故障今天发现服务查询一直卡住，就看了一下服务器当时就愣住了就这一个服务就把占满了，再看了下端口号出现了大量的。一、发生故障今天发现服务查询一直卡住，就看了一下服务器： showImg(https://segmentfault.com/img/bVbrL5i?w=842&h=57); 当时就愣住了就这一个服务就把CPU占满了，再看了下端口号： showImg(https://s...

CoderStudy 2019-08-08 13:58 评论0 收藏0
记一次解决线上 Redis 集群单节点 CPU 偏高问题

摘要：问题线上已经运行很久的一个阿里云节点集群版经常会报偏高，经确认后发现只有节点偏高，且是其他节点的倍以上，即大部分节点的占用率在到，大约是，问题节点的占用率超过，是。问题线上已经运行很久的一个 Redis （阿里云64节点集群版）经常会报 CPU 偏高，经确认后发现只有 13 节点 CPU 偏高，且是其他节点的 3 倍以上，即大部分节点的 CPU 占用率在 20% 到 30%，QPS...

meislzhua 2019-07-24 16:36 评论0 收藏0
记一次MongoDB高负载的性能优化

摘要：年月日本文是关于记录某次游戏服务端的性能优化此处涉及的技术包括引擎随着游戏导入人数逐渐增加单个集合的文档数已经超过经常有玩家反馈说卡特别是在服务器迁移后从核降到核卡顿更严重了遂开始排查问题确认服务器压力首先使用命令查看总体情况此时占用不高 Last-Modified: 2019年6月13日11:08:19 本文是关于记录某次游戏服务端的性能优化, 此处涉及的技术包括: MongoDB...

huhud 2019-07-01 13:57 评论0 收藏0
记一次MongoDB高负载的性能优化

摘要：年月日本文是关于记录某次游戏服务端的性能优化此处涉及的技术包括引擎随着游戏导入人数逐渐增加单个集合的文档数已经超过经常有玩家反馈说卡特别是在服务器迁移后从核降到核卡顿更严重了遂开始排查问题确认服务器压力首先使用命令查看总体情况此时占用不高 Last-Modified: 2019年6月13日11:08:19 本文是关于记录某次游戏服务端的性能优化, 此处涉及的技术包括: MongoDB...

vibiu 2019-06-26 18:05 评论0 收藏0
串行还是并行？——记一次 AsyncTask 问题排查

摘要：当然，如果你的核心数够多，到个线程的并行度不满足的话，也可以自定义一个线程池来执行，不过这样的话，要注意自己维护这个线程池的初始化，释放等等操作了。事情起源于一个bug排查，一个AsyncTask的子类，执行的时候发现onPreExecute方法执行了，doInBackground却迟迟没有被调用。懂AsyncTask一些表面原理的都知道，onPreExecute方法是在主线程执行，...

mo0n1andin 2019-08-15 11:12 评论0 收藏0