好久没更,记录一次线上系统异常与恢复。
临近明天向客户展示系统,结果快下班测试同事的一组聚合图表的查询,10余台es节点cpu全部飙红,load居高不下。等待10余分钟,丝毫未有下降的趋势,老大有点躁了,系统重启下。简单粗暴的办法,因为快下班了,想赶快解决问题。我们认为这是一次由于聚合字段查询过多导致的cpu使用率较高,正常情况下,用户是不会有如此批量的查询动作。
就在重启了2台es之后,我突然惊奇的发现,我们的Load Blance节点无法ssh了!!!ping的通,但是无论如何连不上。这个比较麻烦,Load Blance 不仅是各个组件的沟通桥梁。上面还安装了kafka,zookeeper。还有日志处理模块。
简直麻烦了,必须保证各个节点通讯,所以必须重新搭建一个新的Load Blance。今晚的加班不可避免了。吭哧吭哧搭好新环境,更改各个配置。基本稳定了,数据吐过来了。剩下一点活,老大说明天在搞吧,然后说了下再连load blance看一下。结果真的又活了,我们都很惊讶,“linux 就是牛逼”。
节点ssh后又再次配置回来,来回折腾了,不过最终恢复了系统正常运行。保存了load blance的日志待进一步分析。该节点es已经挂了,但是进程任然存在,所以supervisor也无法起作用拉起来的新的也无效。因为9200还是被那个不服务的es占用着。
总的来说这是一次,因为并发查询导致的,es中tasks较多,cpu使用飙升,但是为何会引发ssh无法登录还需要进一步考证。
下楼的时候我问,你怎么想到最后在连接一下的。“我们什么操作都没做,却无法连上ssh,cpu肯定忙的没有机会处理连接了,虽然这种几率很小。但是我们折腾一圈后,应该有所缓解,所以在连接一下”