java服务宕机原因查询

背景

在java服务项目上线之后经常会出现宕机的情况

常见原因

内存溢出

1.查到服务进程号

[[email protected] ~]# ps -ef|grep java
root      6399  6069  0 08:57 pts/2    00:00:00 grep --color=auto java
root     25374     1  0 Oct17 ?        00:21:19 /usr/local/jdk/jre/bin/java -Djava.util.logging.config.file=/home/tomcat-wmsweb/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms3072m -Xmx3072m -Xss512K -XX:PermSize=256m -XX:MaxPermSize=512m -Djdk.tls.ephemeralDHKeySize=2048 -Djava.endorsed.dirs=/home/tomcat-wmsweb/endorsed -classpath /home/tomcat-wmsweb/bin/bootstrap.jar:/home/tomcat-wmsweb/bin/tomcat-juli.jar -Dcatalina.base=/home/tomcat-wmsweb -Dcatalina.home=/home/tomcat-wmsweb -Djava.io.tmpdir=/home/tomcat-wmsweb/temp org.apache.catalina.startup.Bootstrap start
root     25401     1  2 Oct17 ?        03:14:13 /usr/local/jdk/jre/bin/java -Djava.util.logging.config.file=/home/tomcat-wms/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms3000m -Xmx3000m -Xss512K -XX:PermSize=256m -XX:MaxPermSize=512m -XX:-UseGCOverheadLimit -Djdk.tls.ephemeralDHKeySize=2048 -Djava.endorsed.dirs=/home/tomcat-wms/endorsed -classpath /home/tomcat-wms/bin/bootstrap.jar:/home/tomcat-wms/bin/tomcat-juli.jar -Dcatalina.base=/home/tomcat-wms -Dcatalina.home=/home/tomcat-wms -Djava.io.tmpdir=/home/tomcat-wms/temp org.apache.catalina.startup.Bootstrap start
[[email protected] ~]#

2、查看内存使用情况

[[email protected] ~]# jmap -heap 25401
Attaching to process ID 25401, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.211-b12

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 3145728000 (3000.0MB)
   NewSize                  = 1048576000 (1000.0MB)
   MaxNewSize               = 1048576000 (1000.0MB)
   OldSize                  = 2097152000 (2000.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 607649792 (579.5MB)
   used     = 607649792 (579.5MB)
   free     = 0 (0.0MB)
   100.0% used
From Space:
   capacity = 213385216 (203.5MB)
   used     = 0 (0.0MB)
   free     = 213385216 (203.5MB)
   0.0% used
To Space:
   capacity = 201326592 (192.0MB)
   used     = 0 (0.0MB)
   free     = 201326592 (192.0MB)
   0.0% used
PS Old Generation
   capacity = 2097152000 (2000.0MB)
   used     = 2097149664 (1999.9977722167969MB)
   free     = 2336 (0.002227783203125MB)
   99.99988861083985% used

121339 interned Strings occupying 10592008 bytes.

发现 Eden Space 100.0% used
PS Old Generation 100.0% used
确认为内存溢出

接下来我们需要查看到底是那个大对象造成的这个问题
由于堆内对象信息太多,因此需要输出到问题中查看

[[email protected] ~]# jmap -histo:live 25401 >aaa.log

查看大对象信息

[[email protected] ~]# vim aaa.log

 num     #instances         #bytes  class name
----------------------------------------------
   1:      23798913      925276392  [C
   2:      23791642      570999408  java.lang.String
   3:        879806      201469128  [Ljava.lang.Object;
   4:        717239      189351096  com.demo.inventory.query.GetTaskCountQueryItem
   5:       5247003      125928072  java.lang.Double
   6:        932106       82025328  java.lang.reflect.Method
   7:       2144995       68639840  java.util.HashMap$Node
   8:       1457567       46642144  java.sql.Timestamp
   9:        725212       40611872  org.hibernate.engine.EntityEntry
  10:        725213       34810224  org.hibernate.engine.EntityKey
  11:        180443       26468992  [Ljava.util.HashMap$Node;
  12:        549431       26372688  org.aspectj.weaver.reflect.ShadowMatchImpl
  13:        655720       26228800  java.util.LinkedHashMap$Entry
  14:        239773       25712128  java.lang.Class
  15:        780484       24975488  org.apache.commons.collections.SequencedHashMap$Entry
  16:       1535589       24569424  java.lang.Integer
  17:        656230       20999360  java.util.concurrent.ConcurrentHashMap$Node
  18:        869529       20868696  java.util.ArrayList
  19:        822486       20851440  [Ljava.lang.String;
  20:         66016       19964336  [B
  21:        549431       17581792  org.aspectj.weaver.patterns.ExposedState
  22:        705540       15311776  [Z
  23:        549431       11702568  [Lorg.aspectj.weaver.ast.Var;
  24:        725212       11603392  org.hibernate.util.IdentityMap$IdentityKey
  25:        158941        8900696  java.util.LinkedHashMap
  26:        324828        7247936  [I
  27:        162778        6511120  java.lang.ref.SoftReference
  28:           476        6288080  [Ljava.util.concurrent.ConcurrentHashMap$Node;
  29:        110595        5308560  java.util.HashMap
  30:        155487        4975584  java.lang.ref.WeakReference
  31:         16090        3732880  com.demo.inventory.query.WmInvLotLocTraceIdQueryItem
  32:        163337        3313312  [Ljava.lang.Class;
  33:         41098        3287840  java.lang.reflect.Constructor
  34:         51249        3279936  org.hibernate.mapping.Column
  35:         81913        3276520  java.util.WeakHashMap$Entry
  36:         35571        3047840  [[Ljava.lang.String;
  37:         51247        2869832  org.hibernate.mapping.Property
  38:         51249        2459952  org.hibernate.mapping.SimpleValue
  39:         49720        1988800  org.hibernate.annotations.common.reflection.java.JavaXProperty
  40:         48352        1934080  org.hibernate.tuple.StandardProperty
  41:         78677        1888248  java.beans.MethodRef

由上可知com.demo.inventory.query.GetTaskCountQueryItem 导致内存过大,应优化处理。

本博文来源于:https://blog.csdn.net/weixin_43159039/article/details/102676161

原文地址:https://www.cnblogs.com/Small-sunshine/p/11733881.html

时间: 2024-10-31 11:26:49

java服务宕机原因查询的相关文章

解决SpringCloud Gateway Finchley.SR2服务宕机,不走熔断报fallbackCmd failed and fallback failed.问题

在项目中,遇到网关Gateway路由的服务宕机,但是最后并没有走熔断的重定向. 在Gateway的application.yml文件中有配置: filters: - RewritePath=/olesellercenter/(?<segment>.*), /$\{segment} #路由重写 - name: Hystrix #熔断过滤器 args: name: fallbackCmd #符合Java命名规范即可 fallbackUri: forward:/fallback/serviceFai

由Redis的hGetAll函数所引发的一次服务宕机事件

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累.这篇博客,算作一个复盘和记录吧... 先来看看Redis的缓存淘汰算法思维导图: 说明:当实际占用的内存超过Redis配置的maxmemory时,Redis就会根据用户选择淘汰策略清除被选中的key. 业务场景:用户通过微信入口来访问一个页面: 测试场景:通过多线程模拟定量的并发来访问页面服务: 涉及架构:springsession+Redis集群,容器部署: 问题描述:固定并发数压测10分钟,压测开始后半小时,Redis连接数激增,

云服务宕机后果严重 用户如何防范于未然

前段时间出现的不管是云服务宕机还是数据中心遭受自然灾害,都说明即使再靠谱的运行商也有飞来横祸的一天,所以为了我们的数据安全,不要在选择一个运营商后就觉得高枕无忧了,还要做好以下三件事,才不至于在意外来临时措手不及. 数据备份 传统数据备份还将继续存续下去.在某些环境下,它还可以很好地发挥作用,现在还没有理由和/或预算去替换它. 云存储.云备份等产品及服务的确为众多企业,尤其是中小企业带来了便利,但云存储同时又是一把双刃剑,在发生问题时给企业带来等影响和损失也是非常巨大的.因此,如果你在云端存储重

Redis(六)——高可用之哨兵sentinel配置与启动及主从服务宕机与恢复

.主从复制高可用 #主从复制存在的问题: 1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master 2 主从复制,只能主写数据,所以写能力和存储能力有限 哨兵是对Redis的系统的运行情况的监控,它是一个独立进程,它会独立运行,功能有二个: 通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器. 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

Solr4.8.0源码分析(26)之Recovery失败造成的宕机原因分析

最近在公司做SolrCloud的容灾测试,刚好碰到了一个比较蛋疼的问题,跟SolrCloud的Recovery和leader选举有关,正好拿出来分析下. 现象是这样的:比如我有一台3个shard的SolrCloud,每一个shard又有一个leader和replica.由于SolrCloud的leader选举策略,造成了IP1中同时出现了shard1和shard2的leader. 这个时候往collection update数据进去,以shard1为例,数据转发过程,IP1_leader –>

模拟http服务宕机 模拟jsf不提供服务(只能用物理机)

只适用于物理机 1.首先查看iptables -L -n查看规则 2.用iptables -F取消掉所有规则 3.执行sh脚本,drop掉一些ip 3.屏蔽指定ip 有时候我们发现某个ip不停的往服务器发包,这时我们可以使用以下命令,将指定ip发来的包丢弃: BLOCK_THIS_IP="x.x.x.x" iptables -A INPUT -i eth0 -p tcp -s "$BLOCK_THIS_IP" -j DROP 以上命令设置将由x.x.x.x ip发往

网易视频云:HBase —— RegionServer宕机案件侦查

今天网易视频云技术专家给大家分享一下HBase–RegionServer宕机案件侦查,欢迎参与讨论. 本来静谧的晚上,吃着葡萄干看着球赛,何等惬意.可偏偏一条报警短信如闪电一般打破了夜晚的宁静,线上集群一台RS宕了!于是倏地从床上坐起来,看了看监控,瞬间惊呆了:单台机器的读写吞吐量竟然达到了5w ops/sec!RS宕机是因为这么大的写入量造成的?如果真是这样,它是怎么造成的?如果不是这样,那又是什么原因?各种疑问瞬间从脑子里一一闪过,甭管那么多,先把日志备份一份,再把RS拉起来.接下来还是Bu

Redis的KEYS命令引起RDS数据库雪崩,RDS发生两次宕机,造成几百万的资金损失

最近的互联网线上事故发生比较频繁,20180919顺丰发生了一起线上删库事件,在这里就不介绍了. 在这里讲述一下最近发生在我公司的事故,以及如何避免,并且如何处理优化. 间接原因还有很多,技术跟不上业务的发展,由每日百万量到千万级是一个大的跨进,公司对于系统优化的处理优先级不高,技术开发人手的短缺 第一次宕机20180913某个点,公司某服务化项目的RDS实例连接飙升,CPU升到100%,拒绝了其他应用的所有请求服务整个过程如下: 监控报警,显示RDS的CPU使用率达到80%以上,DBA介入,准

云平台数据库主机意外宕机问题

问题引入: 很多公司在使用自己的私有云环境时,会选择划分主机集合,像这种 很好,做得很好,但是新建主机集合的精髓在于:区分对待,每个zone内包含物理节点拥有不同的物理配置 比方说: 1.zone1用来新建cpu密集型云主机 2.zone2用来新建内存要求较高的云主机 3.zone3用来新建硬盘io要求较高云主机 如果不区分对待,那划分什么主机集合. 下列就是发生在我们公司的一个案例: 一:问题:生产环境DB主机主节点在19号中午突然宕机,导致公司某业务中断. 二:问题解决: 生产以第一时间恢复