性能压测诡异的Requests/second 响应刺尖问题

  • 时间:
  • 浏览:2

废话很多说了,直接进入主题。

5.排查

其实全版都是大促前的性能压测要求,否则 为了安全起见,还都能不能 摸个底心里有个数。

亲们分析下,receive、send不配对因为着分析哪此,亲们有400并发,延迟1秒启动,基本上跑上个十几分钟,你能离米 想象出400并发的请求空间路线图么。其实它会呈现出每秒钟全版都是请求进来,这是压力机的请求,每秒也会有请求出去,去访问它所依赖的服务否则 上端件。否则 ,亲们设想从压力机为现在现在开始点,把请求和响应想象成一一另另一个圆,那在圆的任何一一另另一个角度上全版都是请求和响应。

JAVA GC:

等我尝试注释掉发送消息的逻辑刚刚发现现象找不到現了,有希望了。现在现在开始进去看代码,没啥逻辑,走的是spring 的RabbitTemplate.convertAndSend 法律方式。(这是个同步法律方式,没办法 任何声明说他是async的。)

现象一如既往的出現了(我否则 能接受了~_~,它假如找不到現我才想死尼,否则 来回折腾以后 了。)很好,rabbtimq dashboard也出現刺尖了。

亲们注意看下,DB的网络流量图,它假如比较正常的,没办法 请求没办法 发送。而应用服务器有点痛 说不通,没办法 进来的没办法 出去的,这段时间内到底在干嘛,否则 分布很平均。

其实类式刚刚有一一另另一个结论,假如服务器其实没办法 瓶颈,不管是应用服务器还是DB、cache。那现象应该是在线程方面。(性能分析由上至下、由下至上集合分析《java性能优化权威指南》)。

现在现在开始排查线程现象,是否是有block线程,通过jstack 打印出线程,基本上全版都是XNIO的condition wait,也没办法 啥不正常。否则 下单服务的某些接口都挺正常的,线程现象应该不大。下单成功刚刚有意个hold的场景,假如hold虚拟币、卡券码等等类式的逻辑,这上端使用了fiexd线程(八个,设置了饱和策略及日志输出。),现象假如大。

创建订单逻辑稍微冗杂点,对互近的系统及上端件依赖也比较多,好多好多 还都能不能 重点关注,离米 心中要有数,哪怕下游的哪个服务的性能有现象,在下次大促的刚刚可还都能不能能 优化掉。

结果很遗憾,没啥线索,性能很好。

压测下来一切正常,cpuwait为0(心情无比的顺畅)。

我刚刚全版都是400分钟,我尝试用空exchange压了一小时(已是周五晚24:00点左右,洗澡睡觉,明早上看结果)。

也假如说发送消息全版都是发送给exchange就现在现在开始了,亲们配置的是topic模式,类式消息类型上端有一另另一个queue,并肩这有几条queue全版都是消费者在获归还费消息。否则 否则 获归还息的法律方式是pull模式,假如会居于多大的并发获归还息的状态。否则 哪此queue上端的消息都非常多,当我不压的刚刚CPU假如高,pull消息的开销对服务器来说network多点,CPU我很多 很多。

现在现在开始排查日志,restful-slow.log,jdbc-slow.log、错误日志等等,一顿cat… grep…wc –l,啥也没办法 异常。(shit现在现在开始冒汗了。。。)

重点是关注下JAVAGC 容量:(java线程的内存分配由“内存分配器+GC完成”《java性能优化权威指南》)

network:

/**发送消息*/

template.convertAndSend(messageConfig.getExchangeName(), routingKey, message, amqpMessage -> {

早上起来看没出現那个现象。为哪此我用不持久的queue还有现象,否则 类式queue是没办法 任何consumer的,这否则 涉及到rabbtimq的底层原理了。rabbtimq用的是erlang语言写的,看源码一时半会估计路都找没办法 。还是想某些法律方式。

类式点可还都能不能能 通过rabbtimq queue的dashboard 中的publish in 和 publish out才查看,publish out 是publish in * queue的数量。

并发用户数没变化,平均响应时间没变化,否则 request/second奇怪了。我相信大多数开发的直觉假如fullgc了,我也一样。

memory:

注意看下图中的In memory,shit假如落盘了,哪怕你设置不持久化为了内存利用率,它会将消息落盘,注意看Persistent没办法 任何消息。消息总量1.1G,内存中没办法 119MB。

同样现象的出現CPU不正常,否则 wait 率比较高。是全版都是可还都能不能能 假如推理,wait率高了,因为着一定量线程(子线程)挂起,好多好多 看起来CPU利用率占的就高,也说的通。(先没办法 假设,来验证它就知道了)

提交横向第二轮压测。

提交横向压测前亲们还都能不能 某些人先过一遍,假如还都能不能加快压测的速率,否则 时间比较紧再去掉 客观的环境现象,我将服务蕴含几条没办法 压测环境的依赖去掉 。(有关压测的某些实践我将在下篇文章好好总结下,这里就不展开了。)压测了几轮(时间差很多400分钟左右。),消除了某些环境、代码、依赖的障碍,提交横向走压测流程,接着就去忙某些的事情了。(诡异的现象比较多~_~,mybatis pagehelperplugin好像全版都是点痛 并发现象,还没定位到,告诉我是用的不对还是哪此状态,继续排查,有结论了我在总结分享下。)

看后下DB状态,也没啥异样,全版都是在相同的时间点,一下子负载没办法 了,时间都能对上。网络、磁盘、CPU都没办法 活动。

2.查看服务器监控状态:

没办法 上大招了,现在现在开始尝试注代码,否则 压测,逐个尝试,先注释DB、否则 线程hold逻辑、否则 发送消息。(无赖之举。。。)

cpu:

(资源没隔离是是否是则 某些客观因为着,有刚刚压测环境是临时搭建的。用到qa环境的上端件还有codis,否则 codis基本是二级缓存,好多好多 现象不大,先过。(回头没辙再来找它。)

内存咋一看好像有点痛 现象,否则 了解linux 内存计算法律方式和使用原理都知道这其实现象不大。(下篇文章中会具体讲解关于压测的刚刚各个指标怎么才能 才能 查看和计算,在压测刚刚重点关注top中的swap区。)

这是压测的下单服务机器资源状态。

刺尖的有几条点CPU idle 基本全版都是400%,us也是0%,非常奇怪。再看下某些的资源。

等我在开会的刚刚,压测兄弟找我,哥哥那个现象又出現了。

上端图蕴含一幅图有点痛 现象,告诉我亲们看出来了没办法 。假如我下单服务的应用服务器的网络流量有现象,receive、send对不上。

顺便看后下配置文件,发送消息走的是qa环境,类式我知道,否则 当时压测环境的rabbitmq一时还没好,否则 亲们走的是先定义再使用queue的流程,好多好多 否则 要用我还都能不能 先上去配置好还都能不能使用。当时图省事就先用了,某些人压测下来也没啥现象,毕竟MQ的设计吞吐量都很高的,TPS足够亲们用的,再去掉 我刚刚也压过qa的MQ没啥现象。

否则 这次压测主要重点是关注正向的一另另一个核心订单服务,下单服务、查单服务。查单服务初步压测下来现象不大,主假如db的索引和cache的现象。

也是比较奇怪的,receive到是挺正常的,send基本为0了,感觉像是某个调用否则 发送停止了,能接受请求,否则 对下游的调用貌似停止了。

立马去看下服务器的GC监控,并肩看下线程的GCer配置是CMS。(CMS主要外理低延迟现象《深入理解JAVA虚拟机》)

7.打脸

遇到现象一定要搞清楚根源,就算找没办法 根源也知道把它限定在某个范围内,比如限制到DB、操作系统等等。

压测下来一切正常,没办法 出現刺尖状态(真爽~_~),cpuwait 正常0。基本上定位到现象了。是是否是则 rabbtimq有五种的负载不足英文了,性能跟不上好多好多 因为着类式现象,这也算加深了rabbtimq的每项原理。

4.分析

8.总结

毕竟这次转java的服务全版都是集团核心公共服务(主假如订单域服务)。(等亲们顺利上线了,我再来好好总结下其中的坎坷和壮举。)

现在现在开始怀疑商品、促销,否则 我刚刚分别对类式另另一个服务进行过压测,类式另另一个服务基本上全版都是命中cache,QPS基本上接近140000。现在也只好对类式另另一个服务再进行一轮全版的压测。

现在基本上是rabbtimq服务器的性能现象了,否则 我想要其实现象找到了。否则 我还是无解,为哪此出現类式现象,为哪此时间没办法 规律,肯定有蹊跷,继续排查,到底是rabbtimq服务器的CPU现象还是disk现象,还是network现象。这次重点看下top。

在基于类式推理,我用了一一另另一个不持久化的queue来接受消息,也假如说类式消息是我很多 持久化的,cpuwait应该是0。

有某些我想要 肯定,根据rabbtimq推送消息原理,一一另另一个消息还都能不能 发送给所有监听的queue,哪此queue还都能不能 落盘才算这次publish成功,才会返回。(可还都能不能能 参考《Rabbitmq in Action》)

1.压测报告:

3.查看DB状态:

基于类式推理,我考虑用一一另另一个空exchange来接受消息,根据原理指导,exchange收到消息刚刚否则 发现没办法 任何queue可还都能不能能 投递就直接丢弃了。

下单服务有一另另一个核心接口,预订单查询、创建订单。预订单查询主假如订单的前置状态的结算页汇总计算(不仅是结算页),不落具体订单,如,各种促销、卡券码、虚拟币的规则计算等等。

最近一段时间全版都是忙着转java项目最后的冲刺,前期的coding翻代码、debug、fixbug都逐渐收尾,进入上线前的性能压测。

现在现在开始尝试排查依赖服务,下单服务主要依赖商品、促销。cache全版都是现象,否则 本地有一级缓存,否则 缓存的过期时间对不上,压测环境的redis和MySQL在一台机器上。好多好多 DB没办法 现象,基本上redis应该也没啥现象。(这台机器很强悍)还有每项的依赖业务方的接口我否则 注释掉了,我很多 有依赖。

6.浮出水面

(我一时蒙蔽,我擦哪此状态。)调整了下,仔细看后下那个刺尖的出現的时间比刚刚长了。假如离米 十五分钟,现在要半小时。否则 qa环境机器没办法 安装压测监控工具,告诉我那段时间里居于了哪此。(压测执行时间1小时)

搞来了qa环境的rabbitmq服务器账号,并肩打开rabbtimq管理界面中的dashboard。现在现在开始重点关注这台服务器。(top命名打开,P\M看下rabbitmq各项指标。)

上图中的cpu wait率有点痛 不正常是是否是则 exchange同步写一另另一个queue且落盘,好多好多 有类式现象。

(并全版都是说所有性能现象都还都能不能 及时优化,假怎么才能 证能撑得起业务量的一定范围就好,否则 性能优化无止境,还都能不能 把握好节奏。)

翻了下资料,没啥特殊的使用要求。

没发现fullgc,再看下有几条某些的系统资源是否是有异样。

我线程上端基本上没办法 用到哪此一定量的磁盘操作,基本上就一一另另一个日志输出,别的没办法 了。(linux cache区不管是读还是写全版都是被cache住,会在cache里维护一一另另一个逻辑地址空间。我将在下篇文章中演示出来,每当我删除磁盘的日志文件,cache区全版都是瞬间释放。https://www.ibm.com/developerworks/cn/linux/l-cache/index.html)

为哪此会有没办法 大的disk write。否则 一定量的磁盘写入,因为着publish消息的刚刚block了。具体为哪此会假如就要去研究rabbtimq源码了。哪此在rabbtimq的配置中应该有策略的,否则 全版都是蒸不烂 悉rabbtimq,好多好多 这里就只好先告一段落了。

能隔离环境的尽量隔离,排查环境现象最头疼,否则 有刚刚又无法外理。(下篇压测文章分享下,环境现象的排查法律方式和工具)

又尝试用持久化queue来压测一把,看下到刚刚啥状态,仔细盯着rabbtimq dashboard,你以为又出現了。(计算机现象永远不居于巧合,不选者。)