大家对运维系统的定位是能用，好用，对于高可用和性能的关注会比较少。一般来说，我们都会感觉差不多就行了，直到今天临时停了下服务，发现对已有的业务使用产生了一些影响，所以系统的稳定性和性能问题成为我们要格外关注的一个方面，简单来说，现状需要改变。

如果把近期的几个问题汇总起来，你会发现有些问题开始变得严重起来。

1）有一天晚上9:00左右的时候，运维系统的服务突然无响应，页面打开很卡顿，查看系统进程都是正常的，日志中也没有额外的信息显示，最后重启服务了事。

2）最近完成了初版的任务系统部署，要逐步把一部分的数据库批量任务迁移到任务系统中，结果在元旦前，自己在任务系统接入任务的时候，任务系统的默认并发是20，而平常数据库运维系统是5，导致数据库运维系统直接无响应，说起来真是尴尬。

报错信息如下，感觉是超时自动终止了。

3）使用postman调用单独的API任务时，超时60秒会直接无响应。

1. 测试环境的应用配置和线上配置是基本一致的，除了服务器和数据库IP不同之外，其他的配置都是统一的。
2. 线上环境临时切换成manage.py方式，重新调用API，唯一的差别是产生60秒超时的时候，mange.py的方式会一直等待任务正确执行完毕，而Uwsgi的方式会报无响应的错误。

1. 通过ansible的方式调用sql得到表的元数据信息
2. 解析得到的元数据信息
3. 在持久化之前，会从已有的数据表把最新的一条记录更新，这样持久化之后的记录中的表只有一个是最新的。
4. 完成持久化操作，即insert的操作

1）有一天晚上9:00左右的时候，运维系统的服务突然无响应，页面打开很卡顿，查看系统进程都是正常的，日志中也没有额外的信息显示，最后重启服务了事。 其实明白了原因，再加上一个背景，问题就很明显了，晚上9:00的时候会跑一批任务，会把几百个MySQL实例的元数据都采集一遍，结果触发的时候，并发导致系统无响应。

2）最近完成了初版的任务系统部署，要逐步把一部分的数据库批量任务迁移到任务系统中，结果在元旦前，自己在任务系统接入任务的时候，任务系统的默认并发是20，而平常数据库运维系统是5，导致数据库运维系统直接无响应，说起来真是尴尬。

这个解决了API的效率问题，超时的概率就很低了。所以也不会存在并发20导致系统崩溃了。

3）使用postman调用单独的API任务时，超时60秒会直接无响应。 这个问题迎刃而解。

而改进之后，只需要50多秒。

通过这样一个问题也可以折射出我们对于性能优化的必要性和问题的分析思路对于我们解决大多数问题是相通的。