java cms cpu占用率_cms yonggc频率突然暴增，cpu被打满---如何定位是什么原因导致的这个现象？...

最新推荐文章于 2022-02-12 19:00:29 发布
最新推荐文章于 2022-02-12 19:00:29 发布
阅读量451 收藏
点赞数
文章标签： java cms cpu占用率
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_30151565/article/details/114934419
版权

1.昨天中午服务器监控提示：服务器xx.xx.xx.xx机器cpu使用率连续36次超过20%

2.服务器基础信息：javaweb项目，提供查询，导出等功能。

3.监控信息如下：

yonggc监控：

2baefab8bcec4e474f4a7fd3e124e7fe.png

堆内存监控：

deb437732999f4bcc06ac0ee24733235.png

cpu监控：

262a54dd96e633f16f4dd3b889f26e60.png

full-gc监控：

b5b56ad6071f2cd37078d56a67697d26.png

机器运行实例监控

691edf072840ea5ffbbf2edf97ea4e9e.png

当时机器的gclog：

以上是监控信息~

由于其他同事在14：32时手动执行了一次fullgc导致，内存的一回收，才恢复平静。

当时，启动参数：-Xms4g -Xmx4g -XX:PermSize=300m -XX:MaxPermSize=300m -XX:NewSize=2g -XX:MaxNewSize=2g -XX:SurvivorRatio=20 -XX:MaxTenuringThreshold=10 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:ParallelGCThreads=4 -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection -XX:CMSInitiatingPermOccupancyFraction=70 -XX:+ExplicitGCInvokesConcurrent -XX:CMSFullGCsBeforeCompaction=5 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=30 -Xloggc:/tomcat7-gc-cms.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintReferenceGC -XX:+PrintTenuringDistribution

通过查看tomcat7-gc-cms.log分析过程：

14：23有一次fullgc log位置：

fullgc--start

2018-04-16T14:23:45.747+0800: 356595.145: [CMS-concurrent-mark: 1.508/1.538 secs] [Times: user=12.08 sys=0.00, real=1.54 secs]

2018-04-16T14:23:45.748+0800: 356595.145: [CMS-concurrent-preclean-start]

2018-04-16T14:23:45.748+0800: 356595.145: [Preclean SoftReferences, 0.0005960 secs]2018-04-16T14:23:45.748+0800: 356595.145: [Preclean WeakReferences, 0.0001810 secs]2018-04-16T14:23:45.748+0800: 356595.146: [Preclean FinalReferences, 0.0000650 secs]2018-04-16T14:23:45.748+0800: 356595.146: [Preclean PhantomReferences, 0.0000160 secs]2018-04-16T14:23:45.756+0800: 356595.153: [CMS-concurrent-preclean: 0.008/0.009 secs] [Times: user=0.07 sys=0.00, real=0.01 secs]

2018-04-16T14:23:45.756+0800: 356595.154: [CMS-concurrent-abortable-preclean-start]

{Heap before GC invocations=652 (full 1):

par new generation total 2001856K, used 1915155K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 100% used [0x00000006ed400000, 0x00000007619e0000, 0x00000007619e0000)

from space 95296K, 9% used [0x00000007619e0000, 0x0000000762244da8, 0x00000007676f0000)

to space 95296K, 0% used [0x00000007676f0000, 0x00000007676f0000, 0x000000076d400000)

concurrent mark-sweep generation total 2097152K, used 629223K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143890K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

2018-04-16T14:23:45.976+0800: 356595.373: [GC2018-04-16T14:23:45.976+0800: 356595.373: [ParNew2018-04-16T14:23:45.988+0800: 356595.385: [SoftReference, 0 refs, 0.0000510 secs]2018-04-16T14:23:45.988+0800: 356595.385: [WeakReference, 25 refs, 0.0000140 secs]2018-04-16T14:23:45.988+0800: 356595.385: [FinalReference, 45 refs, 0.0000290 secs]2018-04-16T14:23:45.988+0800: 356595.385: [PhantomReference, 0 refs, 0.0000100 secs]2018-04-16T14:23:45.988+0800: 356595.385: [JNI Weak Reference, 0.0000100 secs]

Desired survivor size 48791552 bytes, new threshold 10 (max 10)

- age 1: 3537312 bytes, 3537312 total

- age 2: 1668536 bytes, 5205848 total

- age 3: 337152 bytes, 5543000 total

- age 4: 14496 bytes, 5557496 total

- age 5: 16456 bytes, 5573952 total

- age 6: 10904 bytes, 5584856 total

- age 7: 12664 bytes, 5597520 total

- age 8: 14056 bytes, 5611576 total

- age 9: 11808 bytes, 5623384 total

- age 10: 18184 bytes, 5641568 total

: 1915155K->8115K(2001856K), 0.0122020 secs] 2544378K->637347K(4099008K), 0.0124670 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

Heap after GC invocations=653 (full 1):

par new generation total 2001856K, used 8115K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 0% used [0x00000006ed400000, 0x00000006ed400000, 0x00000007619e0000)

from space 95296K, 8% used [0x00000007676f0000, 0x0000000767edcca0, 0x000000076d400000)

to space 95296K, 0% used [0x00000007619e0000, 0x00000007619e0000, 0x00000007676f0000)

concurrent mark-sweep generation total 2097152K, used 629232K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143890K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

}

2018-04-16T14:23:46.346+0800: 356595.743: [CMS-concurrent-abortable-preclean: 0.274/0.590 secs] [Times: user=4.61 sys=0.00, real=0.59 secs]

2018-04-16T14:23:46.351+0800: 356595.748: [GC[YG occupancy: 1249269 K (2001856 K)]{Heap before GC invocations=653 (full 1):

par new generation total 2001856K, used 1249269K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 65% used [0x00000006ed400000, 0x00000007390109d8, 0x00000007619e0000)

from space 95296K, 8% used [0x00000007676f0000, 0x0000000767edcca0, 0x000000076d400000)

to space 95296K, 0% used [0x00000007619e0000, 0x00000007619e0000, 0x00000007676f0000)

concurrent mark-sweep generation total 2097152K, used 629232K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143890K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

2018-04-16T14:23:46.351+0800: 356595.748: [GC2018-04-16T14:23:46.351+0800: 356595.748: [ParNew2018-04-16T14:23:46.363+0800: 356595.760: [SoftReference, 0 refs, 0.0000360 secs]2018-04-16T14:23:46.363+0800: 356595.760: [WeakReference, 24 refs, 0.0000140 secs]2018-04-16T14:23:46.363+0800: 356595.760: [FinalReference, 48 refs, 0.0000200 secs]2018-04-16T14:23:46.363+0800: 356595.760: [PhantomReference, 0 refs, 0.0000100 secs]2018-04-16T14:23:46.363+0800: 356595.760: [JNI Weak Reference, 0.0000090 secs]

Desired survivor size 48791552 bytes, new threshold 10 (max 10)

- age 1: 2807512 bytes, 2807512 total

- age 2: 1240272 bytes, 4047784 total

- age 3: 487568 bytes, 4535352 total

- age 4: 86712 bytes, 4622064 total

- age 5: 8384 bytes, 4630448 total

- age 6: 12944 bytes, 4643392 total

- age 7: 9152 bytes, 4652544 total

- age 8: 10872 bytes, 4663416 total

- age 9: 11560 bytes, 4674976 total

- age 10: 8456 bytes, 4683432 total

: 1249269K->5485K(2001856K), 0.0116790 secs] 1878501K->634726K(4099008K), 0.0119130 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]

Heap after GC invocations=654 (full 1):

par new generation total 2001856K, used 5485K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 0% used [0x00000006ed400000, 0x00000006ed400000, 0x00000007619e0000)

from space 95296K, 5% used [0x00000007619e0000, 0x0000000761f3b450, 0x00000007676f0000)

to space 95296K, 0% used [0x00000007676f0000, 0x00000007676f0000, 0x000000076d400000)

concurrent mark-sweep generation total 2097152K, used 629241K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143890K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

}

2018-04-16T14:23:46.363+0800: 356595.760: [Rescan (parallel) , 0.0037940 secs]2018-04-16T14:23:46.367+0800: 356595.764: [weak refs processing2018-04-16T14:23:46.367+0800: 356595.764: [SoftReference, 14978 refs, 0.0015960 secs]2018-04-16T14:23:46.368+0800: 356595.766: [WeakReference, 449 refs, 0.0000620 secs]2018-04-16T14:23:46.369+0800: 356595.766: [FinalReference, 1472 refs, 0.0051820 secs]2018-04-16T14:23:46.374+0800: 356595.771: [PhantomReference, 1 refs, 0.0000130 secs]2018-04-16T14:23:46.374+0800: 356595.771: [JNI Weak Reference, 0.0000100 secs], 0.0069140 secs]2018-04-16T14:23:46.374+0800: 356595.771: [class unloading, 0.0269340 secs]2018-04-16T14:23:46.401+0800: 356595.798: [scrub symbol table, 0.0164990 secs]2018-04-16T14:23:46.417+0800: 356595.815: [scrub string table, 0.0036960 secs] [1 CMS-remark: 629241K(2097152K)] 634726K(4099008K), 0.0799200 secs] [Times: user=0.12 sys=0.00, real=0.08 secs]

2018-04-16T14:23:46.431+0800: 356595.828: [CMS-concurrent-sweep-start]

2018-04-16T14:23:46.802+0800: 356596.199: [CMS-concurrent-sweep: 0.363/0.371 secs] [Times: user=2.89 sys=0.00, real=0.37 secs]

2018-04-16T14:23:46.802+0800: 356596.199: [CMS-concurrent-reset-start]

2018-04-16T14:23:46.835+0800: 356596.233: [CMS-concurrent-reset: 0.033/0.033 secs] [Times: user=0.27 sys=0.00, real=0.04 secs]

**fullgc-end**

通过fullgc后的一次yonggc分析发现：

{Heap before GC invocations=654 (full 1):

par new generation total 2001856K, used 1912541K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 100% used [0x00000006ed400000, 0x00000007619e0000, 0x00000007619e0000)

from space 95296K, 6% used [0x00000007619e0000, 0x0000000761fb7548, 0x00000007676f0000)

to space 95296K, 0% used [0x00000007676f0000, 0x00000007676f0000, 0x000000076d400000)

concurrent mark-sweep generation total 2097152K, used 259145K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143429K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

2018-04-16T14:23:47.037+0800: 356596.434: [GC2018-04-16T14:23:47.037+0800: 356596.434: [ParNew2018-04-16T14:23:47.049+0800: 356596.446: [SoftReference, 0 refs, 0.0000370 secs]2018-04-16T14:23:47.049+0800: 356596.446: [WeakReference, 26 refs, 0.0000130 secs]2018-04-16T14:23:47.049+0800: 356596.446: [FinalReference, 43 refs, 0.0000470 secs]2018-04-16T14:23:47.049+0800: 356596.446: [PhantomReference, 0 refs, 0.0000090 secs]2018-04-16T14:23:47.049+0800: 356596.446: [JNI Weak Reference, 0.0000100 secs]

Desired survivor size 48791552 bytes, new threshold 10 (max 10)

- age 1: 4083168 bytes, 4083168 total

- age 2: 1029504 bytes, 5112672 total

- age 3: 362720 bytes, 5475392 total

- age 4: 28200 bytes, 5503592 total

- age 5: 56616 bytes, 5560208 total

- age 6: 8384 bytes, 5568592 total

- age 7: 12944 bytes, 5581536 total

- age 8: 7328 bytes, 5588864 total

- age 9: 8472 bytes, 5597336 total

- age 10: 11560 bytes, 5608896 total

: 1912541K->8400K(2001856K), 0.0122020 secs] **2171686K->267554K**(4099008K), 0.0124480 secs] [Times: user=0.05 sys=0.00, real=0.01 secs]

Heap after GC invocations=655 (full 1):

par new generation total 2001856K, used 8400K [0x00000006ed400000, 0x000000076d400000, 0x000000076d400000)

eden space 1906560K, 0% used [0x00000006ed400000, 0x00000006ed400000, 0x00000007619e0000)

from space 95296K, 8% used [0x00000007676f0000, 0x0000000767f24158, 0x000000076d400000)

to space 95296K, 0% used [0x00000007619e0000, 0x00000007619e0000, 0x00000007676f0000)

concurrent mark-sweep generation total 2097152K, used 259153K [0x000000076d400000, 0x00000007ed400000, 0x00000007ed400000)

concurrent-mark-sweep perm gen total 307200K, used 143429K [0x00000007ed400000, 0x0000000800000000, 0x0000000800000000)

}

老年代确实降下来了：2171686K->267554K

但是新生代，为何频繁回收呢？

当时线程gclog-链接: https://pan.baidu.com/s/1jz5I... 密码: ddrz

暂时自己的解决办法是扩大新生代为3g

有没有遇到过这类问题的？

一张卷纸
关注
李泰山出品-java版CMS内容管理系统
洛阳泰山的博客
03-26 8689
泰山出品-java版CMS内容管理系统 介绍 泰山出品-java版CMS内容管理系统 软件架构 软件架构说明 名称 技术栈 前端模板 thyleaf 后端技术 springboot ORM 框架 mybatis-plus 缓存技术 redis 安全框架 Apache Shiro 日志组件 logback 数据库 mysql 或者h2（默认） 版本管理 git 构建工具 maven 功能导图 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上
JVM调优实战：解决CMS concurrent-abortable-preclean LongGC的问题
思码堂
03-20 1万+
1. 背景 1.1 多个业务线的应用出现LongGC告警 最近一段时间，经常收到CAT报出来的Long GC告警（配置为大于3秒的为Longgc）。 2. 分析前的一些JVM背景知识回顾 2.1 JVM堆内存划分 新生代（Young Generation） 新生代内被划分为三个区：Eden，from survivor，to survivor。大多数对象在新生代被创建。Minor GC针对的...
cpu打满问题分析思路
02-26
cpu打满分析思路，以及对jvm的分析。
sql server cpu使用率过高_cpu使用率过高和jvm old占用过高排查过程
weixin_33603111的博客
01-14 265
今天断断续续的收到管理平台的异常报警，cpu占用过高和jvm old占用过高，这个时候赶紧去排查原因，下面记录了我的排查过程，可能里面还有不正确的地方，欢迎各位大佬指正，也欢迎大家关于类似的案例一起交流，下面就看我关于这次排查的过程把报警cpu使用率过高报警，接近100%后续又来了jvm old过高报警排查过程首先打开监控平台看报警节点的cpu使用情况登录服务器找到占用 cpu过高线程堆栈信息①通...
苹果CMS cpu跑满占用高开启Redis高速缓存加快访问速度性能调优【转】
Hello World程序员的博客
01-30 1万+
由于采集的影片数据过多,如果不设置缓存,可能会造成网站访问缓慢,或者CPU消耗过高。随着用户访问量的上升，添加缓存设置是有这个必要的，众所周知，redis作为一款非常优秀的缓存工具，非常适合苹果cmsv10 redis的优点： redis支持简单的k/v类型的数据，还支持list，set，zset，hash等类型 redis支持主从模式应用 redis支持数据持久化，可以将内存中的数据保持...
如何理解CMS回收器降低gc停顿时间
sinat_14913533的博客
03-31 1161
不管采用什么回收算法，垃圾回收都会包含两个大的过程：标记、回收。 标记：标记的目的就是识别出哪些对象是垃圾了。这个阶段按道理一定是STW的，否则就标记不出所有的垃圾对象，因为如果有并发，一边标记、一边会有垃圾产生，这个理论上永远标记不完。 回收：就是将标记出的垃圾对象回收，腾出内存。这个阶段分回收算法。这个看算法，比如标记-清理算法，在清理阶段是不需要STW的，因为清理阶段只是标记内存可重用就好了。而标记-整理我理解是需要的，因为整理的时候会改变对象的内存地址，同理复制算法也是。 分代收集的理论基础：标
jvm问题排查案例-cpu飙高
u010933982的博客
11-21 733
jvm问题排查一直没有自己的思路体系，这次测试环境发现了一个cpu飙高的问题，刚好用来实践一次，纸上得来终觉浅，绝知此事要躬行。最后捋一下思路和过程，记录 定位java进程 linux, top 命令，发现 23071进程cpu，内存均占比很高 排查cpu问题，对于jvm如何排查cpu占用？当然是要找到具体的内部线程 查看进程内的线程资源占用 使用命令，top -Hp 23071， 发现这些线程cpu占用很高，想要知道这些线程的信息，则必须借助jstack命令，而jstack中的线程号是
java项目之JSP-JTBC-CMS(SQLITE)源码.zip
06-15
java项目之JSP_JTBC_CMS(SQLITE)源码java项目之JSP_JTBC_CMS(SQLITE)源码java项目之JSP_JTBC_CMS(SQLITE)源码java项目之JSP_JTBC_CMS(SQLITE)源码java项目之JSP_JTBC_CMS(SQLITE)源码java项目之JSP_JTBC_CMS(SQLITE)...
jvm性能调优-垃圾收集器parnew&CMS底层三色标记算-performance-gc-parnew-cms.zip
最新发布
01-29
4. 避免Full GC：监控`-XX:+PrintGCDetails`和`-XX:+PrintTenuringDistribution`日志，找出可能导致Full GC的原因。 5. 优化并行收集器：通过`-XX:+UseParallelGC`启用，调整`-XX:ParallelGCThreads`以适应系统资源...
java对象不被gc回收的情况,单例对象无法被回收的原因 - gc回收机制
weixin_33021323的博客
03-13 7998
单例对象无法被回收的真正原因要从java垃圾回收器开始说起JAVA垃圾对象判断准则Java中判断一个对象是否可以被回收是根据“可达性”来判定的。可达性：以一系列的称为 “GC Roots”的对象作为起始点，然后向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，即可视为垃圾。GC Roots点包含：虚拟机...
什么是否发生youngGC、CMS过程
huiyanshizhen21的博客
06-03 875
1.什么是否发生youngGC 1.堆内存分为年轻代和老年代，年轻代分为eden和Survivor。当eden满的是否发生young GC 2.配置jvm -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC，打印gc日志观察 19:14:04.175 [main] DEBUG org.springframework.boot.devtools.settings....
一次 Young GC 的优化实践
勇往直前的专栏
02-28 1万+
这个 GC 案例比较有意思，排查问题有点像侦探断案，先分析各种可能性，再按照获得的一个个证据，去排除各种可能性、然后定位原因，最终解决问题。 问题 某同学在微信上问我，有没有办法排查 YoungGC 效率低的问题？听到这话，我也是不知从何说起，就让他说下具体情况。 具体情况是： 有个服务在没有 RPC 调用时，YoungGC 时间大约在 4-5ms，但是有 RPC 调用时，YoungGC ...
一次CPU占用过高事件的胡乱解决
smtctc的专栏
06-28 8259
1.起因之前组里做了一个基于drools的业务逻辑校验程序，使用的是java语言。因为工作后一直就用C#，但是学校里教的都是java，用上了很久没用的java还是挺高兴的。做完，测试完，放到线上，回家。我们的服务设定是每天早上5点定时跑的，到了第二天早上，手机就接到Zabbix的报警短信，我们的那台跑检验程序的机器CPU占用率超过80%,虽然我们之前Drools规则系统已经加入了很多业务，但是CPU
如何定位和解决频繁Young GC问题
m0_37900506的博客
02-12 6095
如何来分析一个项目的gc情况： 首先通过命令： jstat -gc pid 1000 1000来执行 分析 然后具体需要看如下这些指标 1.新生代对象增长的速率: 看EU指标的变化情况（一般会大致成线性变化） 2.Young GC的触发频率: 通过eden区的总大小除以新生代对象增长的速率 3.Young GC的耗时：通过看YGCT指标 4.每次Young GC后的存活对象大小：通过看S1U指标再ygc前后的变化情况（即当EU突然由一个很大的值变成一个很小的值时，可以看对应变化前后S1U的值） 5.每
CMS GC耗时很高优化过程全记录
weixin_42073629的博客
03-28 1356
1. 背景 多个业务线的应用出现LongGC告警最近一段时间，经常收到CAT报出来的Long GC告警（配置为大于3秒的为Longgc）。 2. 知识回顾 2.1 JVM堆内存划分 新生代（Young Generation） 新生代内被划分为三个区：Eden，from survivor，to survivor。大多数对象在新生代被创建。Minor GC针对的是新生代的垃圾回收。 老年代（Old Generation） 在新生代中经历了几次Minor GC仍然存活的对象，就会
面试必会系列 - 1.6 Java 垃圾回收机制
热门推荐
寒泉
11-03 6万+
本文已收录至 github，完整图文：https://github.com/HanquanHq/MD-Notes 面试必会系列专栏：https://blog.csdn.net/sinat_42483341/category_10300357.html 垃圾回收机制 垃圾：没有引用指向的对象 JVM 堆分代模型 JVM 内存模型和具体的垃圾回收器有关，面试问的时候，你应该说明是哪一种回收器！ 新生代（堆空间） 分为 1 个 伊甸区，2 个 survivor 区 存活对象少，使用 拷贝算法 老年代（堆空.
JVM参数以及工具分析使用
weixin_40663800的博客
04-10 263
首先，我们对于jvm的一些知识已经都有了一些了解。从内存结构到内存分配的策略，再到类的加载机制，然后就是对于垃圾回收机制的理解，虽然还有很多细节的地方我们不是很了解，但是细节不是一天两天就能完全记住了，要靠我们后面再实践中不断的总结和发现问题。所以我们现在就开始了解下jvm的一些工具的使用，方便我们对jvm进行优化。 JVM参数 首先还是先来看看jvm提供的一些参数，我们有对堆、栈的一些命令有...
如何排查内存飙升的情况
小诚信驿站
08-08 1921
文章目录一、接收告警二、查看监控·定位进程三、查看线程占用资源情况3.1、查看线程占用堆栈信息四、查看堆内存对象分布五、MAT分析内存情况 一、接收告警 根据内存使用率监控，我们如果超过85（经验值）是需要报警的。 那么日常异常情况如何报警呢？比如环比一周内存使用率上涨量监控。 所以监控往往是我们排查问题的提高效率的非常有效手段。 二、查看监控·定位进程 公司往往都有监控平台，可以直接查看监控内存上涨趋势？那么如果你的公司比较小是初创公司，基础建设不是非常完备的情况，我们可以通过top命令来查看。 三、
YGC问题排查，又让我涨姿势了！
AI乔治
09-20 1047
在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，由于GC期间都存在Stop The World问题，因此很容易导致服务超时，引发性能问题。 我们团队负责的广告系统承接了比较大的C端流量，平峰期间的请求量基本达到了上千QPS，过去也遇到了很多次GC相关的线上问题。 这篇文章，我再分享一个更棘手的Young GC耗时过长的线上案例，同时会整理下YGC相关的知识点，希望让你有所收获。内容分成以下2个部分： 从一次YGC耗时..
java.lang.IllegalStateException: Service id not legal hostname (${idms.service-mapping.cms-stsc})这是什么原因导致的
06-06
这个错误消息表明，在使用某个服务时，其服务 ID（在这个例子中是 `${idms.service-mapping.cms-stsc}`）被解析为非法的主机名，导致服务无法正常工作。这可能是由于以下原因之一导致的： 1. 服务 ID 中包含了非法字符，如空格或特殊字符。 2. 服务 ID 中包含了一个错误的主机名或 IP 地址。 3. 服务 ID 中包含了一个未知的协议或端口号。 4. 在解析服务 ID 时出现了错误。 为了解决这个问题，你可以尝试以下步骤： 1. 检查服务 ID 是否正确，并确保它符合服务命名约定。 2. 检查主机名或 IP 地址是否正确，并确保服务可以在该主机上正常运行。 3. 检查协议和端口号是否正确，并确保它们与服务实际使用的协议和端口匹配。 4. 如果上述步骤均未解决问题，则可能需要详细检查服务配置和解析代码以查找问题所在。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值