新接口cpu飙升,求解

W 发表于: 2022-09-26   最后更新时间: 2022-09-26 10:30:21   159 游览

情况是这样的:

A 服务要去访问 B 服务的某个接口。之前是循环访问,但是最近并发压力大了,响应变慢,就想优化成批量处理。

优化了一版本之后,上线,发现B服务机器CPU资源直接干到90+,负载直接干到10+。就赶紧回滚了,后仔细查看代码(单条处理和多条处理是一套代码,不过就加了下循环)未发现可能存在的死锁,死循环,内存泄露等问题。

后又查看了gc情况,发现ygc很频繁,6-7次/s。后优化了jvm参数,增大了新生代的大小,ygc 1-2次/s。 又进行了简单的压测。发现cpu 负载压力都可以,就上线了。上线之后没问题,但是3小时之后又出现了负载升高,cpu升高的情况。想问下还有没有排查思路哇?

现在怀疑是跟A服务建立的http连接池有关,您看哪里需要贴代码,跟我说下,谢谢大佬啦

发表于 2022-09-26
W
添加评论

首先你要确认B服务端的最大能力。

比如默认B服务端最大可以开100个线程,当同时并发达到50个线程的时候,cpu已经达到了80%,那么你知道这个已经是极限了。

所以,如果你希望保证健壮,就会把最大线程数控制在50以内,你要做到的是让cpu永远达不到80%。

最后,cpu升高,那么同一时刻,到底有多少线程在working,如果正比上升,那就是很合理。

ps:业务bug导致的cpu飙升另说

情况主要是:
之前:
A服务是循环请求B服务(Get),eg:A一次处理请求B服务18次。
优化(cpu出现问题):
A服务把循环请求的数据融合了起来成了一次(Post)去请求B服务。
按照上述,线程数应该只会减少,不会上升,http链接的数量应该也只会减少不会上升。
至于业务bug,用的同一个函数,不过只是在外层加了循环,应该不会产生bug。

半兽人 -> W 2月前

那么假设:因为原来是一次一次的,中途消耗在了路上很久,A也要等发完继续发,B服务的压力没那么大。
而优化后,中途没了消耗,A也可以没阻碍的一个批次一个批次的发了,一下全在B服务了,B服务就YY了。

W -> 半兽人 2月前

准备回复的时候,有点事情,后来就给搞忘了。sorry,大佬
也有想过大佬说的这个情况,但是之前一次一次的时候,阻塞应该不是严重。
而且我理解的线程数就那么多,post请求减少了生成的线程数量嘛,不应该出现阻塞的情况才对。
话说,大佬,这种情况有办法排查出来嘛?或者,如果真是这种情况的话有什么好的办法解决下嘛?

半兽人 -> W 2月前

你把同时处理的线程打出来,或者做jvm的监控,都可以。
你需要把你的程序变得更透明,才能找到问题。

你的答案

查看java相关的其他问题或提一个您自己的问题
提问