【问题背景】
压测执行：并发数600，脚本含有依赖包，执行持续时间300秒
压测结果：qps曲线出现严重下坠以及断层，
【排障过程】
10：50发了该问题及时升级，同时拉起排障会议解决
11：00拉相关人员上会：架构、运维、研发、涉及ISV团队协助进行性能排障会议
11:02联系运维或者有后台服务监控相关权限同学
11:05需要运维或者相关权限同学协助查看整个服务链路监控：DNS ->DDOS ->WAF ->公网CLD ->政务认证服务->数据库各个服务监控指标是否存在瓶颈
11:07 监控排查发现资源负载瓶颈不在链路上面，反馈给产研同学,主要 看带宽
11:09 王，带宽限制500兆掉200多兆，理论瓶颈出现在这里
11:10 带宽曲线图与QPS曲线图一致
11:14 切换数据库-3监控图,1/2数据库是没负载的,数据库压力都打在3号数据库
11:20 进入日志oppi接口,查看报错信息
11:24 m，数据库报错看不出来问题，组件有原因导致日报错，不影响
11:25 疑问掉坑是否导致数据库代码占满
11:26 m,数据库没看到其他详细日志，重压下，打印日志
11:27 加完日志，下午继续排障
11:30查看根据时间查询表数据是有索引
11:40 麒琳，tce的mgdb，产研这边的适配工作，tce平台没了，需要确认，目前没办法，要资源没资源，要啥没啥，等后面有资源有了在查，跟产品反馈下以后把mgdb移到tce上面去
11:42 我们这边资源有限 ,目前只能调优
11:45 确认外网 压测带宽有限制
11:50 许，升级服务，完成后再复压
14:22 产研同学给出建议做出重新打包发版再进行复测
14:30 临时突破口
复测结果与第一次压测结果季度相似，当时立马反馈给产研同学，是否存在配置host问题，因为该问题在8号解决过一次，由于配置hosts里面没有这三个域名解析
14:33 问题已定位
【起因回顾】
11月8日该接口排障已通过strace工具进行日志对账，排查发现pod没有pod没有写host
研发同学，通过strace命令跟了下服务，看了下他耗时的那段时间是在干什么，发现他在请求dns，然后比对了下异常和正常机器里面的dns，发现dns没有houst
在后面的交接中腾讯产研同学没有跟道一产研同学说明改host的问题，导致道一同学在部署的时候没注意到
【复测结果】
产研收到反馈后，重新对houst配置后重启，复测4次结果比较理想
