8月8号早上9点钟，业务反映页面加载不出来。
查看数据服务器内存、cpu都正常
查看应用服务器内存、cpu正常
慢sql排查也未发现问题
排查代码发现数据库连接池配置有点小
再看了访问情况，发现当天的访问量多了不少。所以确定了问题就是这个配置问题，决定晚上发布来把配置改大。
下午13点50再次业务反馈页面加载问题。
下午想了想，如果是连接池配置问题的话，生产数据库查询慢，也不会导致uat也有这个问题，所以根本问题是不是还有其他原因。（uat和生产用的是一个数据源，不同的库）
跟同事沟通之后，觉得还是应该加一个接口的访问时间的日志，看一下到底是那一步慢了，还是网络问题导致的。
配置修改和接口时间日志都在晚上发布了。（发完之后还发现连接池配置未生效，又是一番排查修改。只是小插曲，但是也是说明不论改了什么也都要测试一下）
8月9号，风平浪静，但是还是不放心，也查询了访问量，只是发现访问量不大。
8月10号一早，还没睡醒，pm打电话说系统进不去了。
赶紧爬起来查了一下日志发现login接口好像卡住了，再往上翻，发现报错
赶紧联系运维查看数据库服务器情况。
自己同时想着删除一点数据，delete发现也是报错。
运维过了一会说看一下，就发现系统可以正常访问了。
最后运维反馈是磁盘满了。
所以排查数据的时候，查看磁盘占用情况很重要。
标签：发现,一次,配置,接口,问题,排查,生产,连接池 From： https://www.cnblogs.com/so-easy/p/17619845.html