悬镜安全扫描导致4核cpu负载使用率400%
【背景】
1、某KA项目通过压测执行结果qps24较低,曲线有毛刺,95ht延迟5秒左右较慢,同时看到后端服务4核cpu已打满400%,反馈给研发同学排查问题
接口:/pwp/rest/portalgxhaction/getAllAppData 12获取应用列表
吞吐量(req/s):24.34
报错率:0%
95%分位的平均响应时间(ms):5330
并发量:100
持续时间:300s
数据分析:qps24较低,曲线有毛刺,4核cpu已打满400%
测试时间:2021-11-24 21:20:18 到2021-11-24 21:25:45
【排障过程】
17:00 研发一开始以为是sql慢查询导致cpu资源占用打满,TDsql全局搜索慢qls也没监测到
17:09 陆斌 ,讨论用火焰图打印排查
17:14 陆斌 ,看下web服务器,cpu压测力也就20%左右
17:15 赵步旺,那个cpu20%左右是那个数组机的,不是我们这个pod的,所以那个没有关联,应该看下我们pod下面的cpu
17:17 徐攀棒,那个cpu为什么那么卡?cpu资源负载达到400%左右
17:18 仇洋菁内存消耗6G多,内存还没满
17:21 赵步旺把火焰图打印出
17:35 赵步旺同步业务类的存在应用服务里面
17:37 压测打印耗时
17:38 压测看打印结果
17:40 压测耗时正常,耗时都没有超过1s
17:41 陈虎兵,这个是框架的安全防护,拦截较多
17:42 当时这块没有做过性能压测分析
17:44 发现安全模块两个过滤器get filter,一个是下面的那个post filter,等于做了两次安全监测。占用cpu使用率70%左右
17:45 陈虎兵明确了现在的性能个瓶颈就是在我们的这个web节点的cpu上面,这个已经明确
17:46 单容器单里面的四核cpu已经全部用完
17:47 调日程,把日程的过滤器调整一下配置
17:49 查看两个过滤器代码
17:51 authorized方法代码更改重写一下这个方法,认证通过返回值为空就可以
18:28 厂商悬镜安全整改完成,需要项目组申请。申请时长6小时
【复测结果】
整改完成后的压测结果
接口:/pwp/rest/portalgxhaction/getAllAppData 获取应用列表
吞吐量(req/s):172
报错率:0%
95%分位的平均响应时间(ms):1690
并发量:150
持续时间:300s
数据分析:
测试时间:2021-11-24 23:47:18 到2021-11-24 23:52:45
相关文章
- 金融服务领域的大数据:即时分析
- 影响大数据、机器学习和人工智能未来发展的8个因素
- 从0开始构建一个属于你自己的PHP框架
- 如何将Hadoop集成到工作流程中?这6个优秀实践必看
- SEO公司使用大数据优化其模型的5种方法
- 关于Web Workers你需要了解的七件事
- 深入理解HTTPS原理、过程与实践
- 增强分析:数据和分析的未来
- PHP协程实现过程详解
- AI专家:大数据知识图谱——实战经验总结
- 关于PHP的错误机制总结
- 利用数据分析量化协同过滤算法的两大常见难题
- 怎么做大数据工作流调度系统?大厂架构师一语点破!
- 2019大数据处理必备的十大工具,从Linux到架构师必修
- OpenCV中的KMeans算法介绍与应用
- 教大家如果搭建一套phpstorm+wamp+xdebug调试PHP的环境
- CentOS下三种PHP拓展安装方法
- Go语言HTTP Server源码分析
- Go语言HTTP Server源码分析
- 2017年4月编程语言排行榜:Hack首次进入前五十