我们项目中用的消息中间件是RabbitMQ，这个消息中间件在使用起来停方便的，也比较健壮，但是使用不当，会对服务器造成很大的压力，会把CPU占用比占到70%左右，今天就来分析一下造成这个结果的原因。
要想具体查看rabbitmq里面各个服务的占用比，需要开启一个插件，就是rabbitmq_top，在服务器输入rabbitmq-plugins list可以查看安装的插件：
安装好这个插件，我们就可以查询rabbitmq内部各个服务的占用比了，登录rabbitmq提供的UI管理界面，可以查看详细：
从图中可以看出，有一个error_logger的程序占用比较高，这是rabbitmq记录日志的一个服务，那么咱们就进入日志记录文件中，查看一下日志：
发现很多异常关闭的日志，出现client unexpectedly closed TCP connection这样的报警日志，最后排查程序，发现有的系统操作rabbitmq，直接是使用时创建连接，生产消息后断开连接，这样的创建连接-断开连接虽然会消耗资源，但不至于报异常关闭，接着排查，才发现程序写的有些问题，有些连接根本就没有真正给关闭掉，当创建的连接数超过设置的最大连接数时，在设置的心跳检测时间范围内，连接数不够用时，rabbitmq就会强制关闭空闲的连接，这样就出现了异常关闭的警告，修复完这个bug后，日志当中就没有出现过异常关闭警告了
但是问题还是没有解决，error_logger的占用比还是比较高，似乎没有什么变化，继续排查其他日志，发现在一个错误日志记录中记录着这样的错误：
这才是关键信息所在，这样的错误信息由于经验所限，还不知道怎么去解决，所以就请教了Google上的大神们，结果找到了一条重要信息，说是rabbitmq是运行在erlang语言的环境上，如果erlang的版本和rabbitmq的版本不对应时，会出现这样的报错信息，并且会使CPU占用比提高。看到这样的信息，就像抓到了一根救命稻草，马上去查看erlang版本和rabbitmq的版本
知道了版本号，然后去rabbitmq的官网去查询不同版本号对应的erlang的支持
这里面没有服务器安装的rabbitmq对应的版本号，也就是我们安装的rabbitmq太old了，官方已经不再维护了，那就去Unsupported Series Compatibility Matrix.中去查找
果然，安装了一个低版本的erlang，那么出现CPU飙高的现象也就不足为怪了，高版本的rabbitmq配合低版本的erlang，会出现资源占用后不被正常释放的问题，小伙伴们赶紧检查一下你们的消息中间件吧，看有没有这种现象？
《本文》有 0 条评论