Ambari Metrics System之后台报错client.AsyncProcess: #1, waiting for 4763 actions to finish

众所周知，目前AMS系统后台的指标数据存储采用的是HBase，不过只是一个拥有单个regionserver的简易版HBase，由于只有一台实际RegionServer，所以所有的读写请求都会指向这一台Regionerver。

此阉割版的HBase并未真正发挥出HBase的分布式特性，也背离了HBase使用的初衷。本质上讲，和单节点的普通数据库没有太大差别。

因此其负载非常巨大，经常会在ambari-metrics-collector.log日志中看到诸如client.AsyncProcess: #1, waiting for 4763 actions to finish这样的日志。

查看这段日志真正产生的原因：
AMS后台是通过使用phoenix连接HBASE，将其指标数据存入到HBASE中，也是通过phoenix进行查询的。由于各服务组件众多，再加上各组季采集的指标数据也在通过AMS接口持续向其推送相关指标，因此其提交频率以及每次提交的数据也是非常庞大的，插入表大的时候，速度就会变慢。日志中就会出现那样的日志了。

查看hbase的源码，从报错 日志client.AsyncProcess找到源码位置，在hbase-client里面，注意版本，新版本这个日志不是出现在AsyncProcess中。

从HTABLE里面的PUT（list-rows）方法开始看，发现程序的逻辑：

插入多条数据->数据大于缓冲大小时进行提交（缓存大小可以设置）->读取该表的meta表，将数据按server分组->每个server启一个线程进行提交->等待提交的返回结果

也就是说，出现这个问题是由于数据插入在服务端没有执行完成，客户端正在等待服务端插入完成。其实问题的本质在于服务端，可能插入太快，该表在spit 或者flush 或者gc stw 等问题引起，需要优化该表在服务端的存储，具体的表优化就看大家自己实际的业务情况了。