ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

现网问题排查小记

2021-07-08 18:33:55  阅读:161  来源: 互联网

标签:现网 String 读取 吞吐 排查 线程 cpu 小记


现网问题排查小记

排查过程

在测试环境,有一个服务的消费速度非常慢。

图片

希望提高消费者的线程数,来消费提高性能,但发现没有起到作用,本地测试了一下,发现有一哥方法占用cpu时间非常高

图片(1)

涉及的具体的代码如下:

图片(2)

这边首先怀疑是不是replaceAll() 正则替换引起的,测试机的cpu在70%左右经过测试,将该方法的逻辑删除,返回改成固定的静态值,消费速度确实大幅提高。

经过高人指点,决定使用火焰图进行性能分析,查看比较慢的方法:

图片(3)

YoungGC频繁 10次/s

image-20210708181548033

找到了对应的方法 readXML(),做了响应优化(左边是优化前的)

主要原因还是读取的XML文件比较大,在读取的过程,产生了大量String对象,引起了频繁的Young GC, 从而影响了吞吐。

图片(4)

优化后吞吐明显提升:

图片(6)

图片(7)

YongGC 下降明显

image-20210708181734411

加线程无法提高效率的原因也找到了,String每次会创建多个对象,每个线程在消费的时候,都会去读取文件,这样如果增加消费线程,那么创建的String对象也多了,young gc 的频率也提升了(要花更多的cpu时间来做gc),所以导致加线程也无法提高吞吐。

总结

在操作大文本时,一定要使用StringBuffer

提问

下图中,用红色方框圈起来的方法表示什么含义

图片(8)

标签:现网,String,读取,吞吐,排查,线程,cpu,小记
来源: https://blog.csdn.net/u014134750/article/details/118579600

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有