hivemetastore 连接过多导致sql查询慢
MetaStore (DB)修改对应的处理连接数maxConnectionsPerPartition建议设置成 100 (不能超过最大值300)，重启Hive服务。
建议值100是根据与工行规模相当集群的设置作参考，尽量大满足连接数请求的同时考虑connection占用资源(如果connection太多会占用太多的内存资源)的角度做出的一个综合评估值。
原因分析
metastore采用了线程池，若使用连接数达到上限，则会使新请求处于等待状态，待有空闲连接线程时才会进行连接。
metastore在当前版本未加入负载均衡机制，会默认连接配置文件中的第一个IP所在节点的metastore实例，在连接数到达一定数量后会导致metastore连接数负载过高。
当Hive分区数目>5000时，会导致Hive在获取元数据时过慢，无法快速完成任务执行释放连接。
解决办法
请确认是否有第三方程序直接连接metastore，例如使用vertica/kettle等第三方软件或应用侧编写的直连metastore的应用。
进行如下操作：
调整metastore的METASTORE_GC_OPTS参数值中-Xms -Xmx -Xmn为合适值。
推荐值如下（可根据以下三组推荐值进行调整）：
-Xms4G -Xmx8G -Xmn1G
-Xms8G -Xmx16G -Xmn2G
-Xms16G -Xmx32G -Xmn4G
在Hive服务参数中适当调整maxConnectionsPerPartition，默认为10，可适当调大，建议调整至25。不推荐调整至最大值。
在Hive服务参数中适当调整partitionCount的参数值，建议调整到3。
原则：partitionCount乘maxConnectionsPerPartition小于DBService最大连接数。
在DBService服务参数中调整dbservice.database.max.connections参数值，建议调整至800。
删除无用分区。
从业务侧降低metastore连接数至1000以下。