浙二事故报告总结

事故现象

6月14-15，医院反馈在体检高峰时，系统明显感到卡顿，并在15日9:40左右系统几乎无法使用，滨江和解放路两个院区同时受影响，并在10：40以后系统逐渐恢复。

初步猜想

早上客流量少时，系统无明显卡顿，在客户量提升时逐渐卡顿，考虑可能是用户量增大，并发操作提升时的影响，并且两个院区互相影响，在服务部署上可能存在问题。

事故排查

系统锁的使用

在并发提升时明显感觉耗时增加，并且关联业务接口耗时可明显观察到递增曲线。首先考虑可能是锁的问题，在排查代码时发现使用了Lock锁。在去除了Lock锁调整业务代码后，接口并发耗时明显下降。

Json过大

部分接口如队列查询接口，在人数提升后，返回的json数组明显增大。考虑可能时json过大时iis处理输出较慢，将IIS替换为Kestrel。返回json较大的接口耗时减少。

服务部署问题

在数据量提升后，解放路的负载未起到性能提升的作用，并且两个院区互相影响，考虑可能是服务部署的问题。经查明，医院提供了三台服务器，.5配置3核24G，.7配置2核16G,.8配置3核12G。.5搭载了三个院区的数据库服务以及应用，.7搭载了解放路服务的应用集群，.8未使用。调整为将解放路院区数据库迁移至.8服务器，.5,.7做解放路的集群。其他不动。调整后并发性能明显增加，且院区之间互不影响。

优化索引

模拟业务环境，生成数据库优化报告，根据报告对部分表新增或修改索引。调整后，性能明显只能加。

sqlserver导致cpu占用过高

在压测或业务峰值时，发现服务器cpu资源占用超过95%，其中sqlserve占用超过85%。考虑可能是部分语句影响。查询出占用cpu过高的语句。追溯语句，发现在高频操作上推送屏幕数据做了大量子查询和连接查询。针对这块做sql优化。

界面UI卡顿

对一些页面的数据刷新操作，做异步或延迟处理，在操作体验上提升。