1. 故障表现
四台Cachecloud同时报警、CacheCloud页面无法访问、应用接口(通过appId拉取节点)和上报接口无法访问。
2. 相关日志
报警时,出现了大量如下:
|
|
所以初步怀疑是客户端上报造成的,所以暴力解决了下把上报的代码全部注释掉重新上线,结果之后还是继续报警,出现了大量如下日志。
|
|
3. 相关疑点
- 每天中午12点有一个大的删除基准表:
|
|
从上面的表现以及之前的故障判断是这个表有问题,但是无论从数据量以及历史看都是没问题的。
4. 确定原因
leader直接抓MySQL process list定位到很多慢查询,都和standard_statistics有关,查询如下
|
|
竟然都卡在上面这个语句,竟然还没有索引,这个应该不可能啊(已经运行n年了,之前表数据量更大),
看了下表结构,索引变了,擦!!!,对比下sql schema的记录,原来是dba搞的,这也太草率了。。
本质:即使各种统计做了线程池隔离(粗暴那种,不是hystrix的熔断),但是数据库连接池是有限的,而主线程的的接口仍然需要数据库,所以依然hang住了主线程池,所以对外表现是无法提供服务。
5.思考
不要有固势思维:过去没问题,不代表现在没问题,何况还有不靠谱的人。
不要被日志迷惑:日志很多时候不能看出问题的本质,这个很多时候已经证明。
遇到问题不能只评经验:想一想问题根本在哪里。