zoukankan      html  css  js  c++  java
  • 小记:本地服务耗时和上游调用显示耗时相差过大问题排查及优化

    问题

    在最近一次压测时发现了一个现象:监控显示服务端p995耗时只有15ms左右,调用方的耗时却高达2000ms,二者相差巨大。

    定位过程

    查看cpu

    查看了压测期间的cpu数据,发现cpu使用率只有20~30%,说明并不是cpu阻塞引起的调用方耗时高

    查看jvm

    查看了压测期间的jvm数据,发现压测期间并没有出现full gc和年老代垃圾回收,young gc的次数和耗时也并没有过多的上涨

    问题缩小

    排除了cpu和jvm后,猜测可能是处理网络链接的rpc框架的线程池出现了积压所致。
    因为服务启动时并没有显式的设置线程池数量,使用的默认配置。查询了rpc框架的文档,发现其默认线程池数量是30,队列深度是30000。
    根据这个数据推测是过少的线程池数量和过大的队列深度,导致了上游调用出现了积压,导致上游的耗时过长

    改进

    当前的容器是8核,一次请求平均耗时是15ms,那么一秒可以处理的线程数是 8*1000/15=533。考虑到cpu调度会占用一些时间,最终设置了450个线程数,900个队列深度。

    结果

    调整了线程池配置后,在同样的qps的情况下,上游调用方的耗时和本地服务端耗时相差就很小,当然cpu使用率也上升了。

    小结

    用餐厅来类比:厨师相当于cpu、餐桌数量相当于rpc框架线程池、 服务端耗时相当于客人到餐桌后吃饭所需时间、客人从来到离开时间是服务端调用时间。
    如果厨师不忙,客人到餐桌后吃饭所需时间不长,但客人从来到离开时间确很长,就说明是餐桌过少,增加餐桌就可以了。

  • 相关阅读:
    POJ 1611 : The Suspects (普通并查集)
    深入解析 Dubbo 3.0 服务端暴露全流程
    智能搜索推荐一体化营收增长解决方案
    云上应用系统数据存储架构演进
    EMR on ACK 全新发布,助力企业高效构建大数据平台
    介绍一下闭包和闭包常用场景?
    BFC
    高斯消元学习笔记
    云虚拟主机如何设置域名解析
    Centos7.3安装openJDK
  • 原文地址:https://www.cnblogs.com/sunzhenchao/p/14332750.html
Copyright © 2011-2022 走看看