写点什么

生产环境全链路压测建设历程 12:通过生产压测发现的问题摘录

发布于: 2020 年 12 月 17 日

前面有提到,全链路压测的出现,是因为在活动开始的瞬间,从CDN、网关接入、前端、缓存、中间件、后端服务、数据库整个交易链路都会面临巨大的访问压力,这个时候系统服务除了受自生的影响,还依赖于其他关联系统的情况,并且影响会一直蔓延,只要有一个节点出现故障,那么故障在上下游系统经过层层累加后会造成的影响谁都说不清楚。



今天这一篇,要讲的就是在生产压测中,各个环节出现的问题摘录



1.应用部分



1.调用量:评价中心对用户中心的调用量每秒上升了1万多,远远超过预期。

2.购物车中心按5万的qps压,目前是压到了load 10,达到了预期容量,但由于无线是cm10的机器多,导致机房的压力不均。



整体交易核心几个应用本身几乎无压力, 购物车的压测符合预期,load压到了10。按创建支付中心单台VM最高达到800多算,大概是有1.3万的创建,但也暴露出几个问题,特别是下单路径依赖了非关键系统的问题。

2.中间件问题

部分应用目前运行的中间件版本参差不齐,有些低版本不支持双11中间件流控降级的功能。



3.数据库问题

1.交易超时业务 数据库的查询压力多于预期 

2.全链路压测的时候,DB压力过高,触发了MySQL的高可用自动切换阈值,引发了切换 

3.全链路压测的时候,DB单实例写入1TPS,产生大量的redo logbinlog SAS盘写入响应变慢,TPS有波动 。最后的预案例,把数据库的redo logbinlog从直接刷盘到刷内存。

4.交易消息分发中心MySQL 从一台物理机4Master,变成2M2S,提升了性能。

5.商品数据库,在全链路压测过程中,当MySQL 的活跃线程数(threads_running 瞬间达到120+,并持续超过20秒,MySQLhang死超过10分钟。 



6.某个索引字段未配置,通过压测监控,研发人员发现请求订单列表请求RT过高,经过排查发现单号索引在生产环境未配置,导致查询rt比较高。



4.硬件问题

三星SSD在长达1小时的压测过程中,会出现坏块的问题。

5.缓存问题



1.通用cacheredis持久化策略与规划不符,cache型不应开启RDB



2.测试环境有设置key过期,但生产环境的业务代码在判断是否设置key过期这块有bug,导致业务系统在请求key的时候,请求出一大堆未过期的数据,在高并发的情况下会请求大量数据,最终影响redis的带宽打满。



发布于: 2020 年 12 月 17 日阅读数: 14
用户头像

还未添加个人签名 2017.12.21 加入

还未添加个人简介

评论

发布
暂无评论
生产环境全链路压测建设历程12:通过生产压测发现的问题摘录