一，前言

最近发现公司的hive metastore晚上每天都出现超时，于是尝试解决一下；

二，背景

（1）目前hive metastore共11台，与namenode/datanode节点混布，这是之前发现超时后不断扩充的结果，其实不需要那么多；

（2）目前存储hive元数据的mysql一主一从，与namenode混布；

（3）所有服务器均为32C256G；

三，现象

四，问题排查

首先，谁出的问题，那么就应该首先去查它；既然是hive metastore出现超时问题，那么就去查hive metastore就可以了；

1，查hive metastore配置，看是否连接数设置的过低；发现设置的连接数为1000，而观察监控最大连接也就60个；设置的内存为20g，但是从来没有用完过，确定hive metastore问题不大；（这都是例行公事，hive metastore优化得很好，基本不会有性能问题）

2，查mysql问题，看mysql主库的情况怎么样，cpu/内存/磁盘，哪个有瓶颈就都记下来；然后开始检查是否开启了慢查询统计，没有的话就打开，不赘述；然后就可以查看慢查询情况了，使用以下命令，即可查看，扫描条数最多的10个慢查询：

mysqldumpslow -s c -t 10 /var/lib/mysql/c2-dsj-hadoop179-slow.log_bak_20210813

Reading mysql slow query log from /var/lib/mysql/c2-dsj-hadoop179-slow.log_bak_20210813Count: 92  Time=15.51s (1427s)  Lock=0.00s (0s)  Rows_sent=1.0 (90), Rows_examined=1045978.1 (96229981), hive[hive]@10hosts  select "S"."S" from "S"  inner join "S" on "S"."S" = "S"."S"     and "S"."S" = 'S'   inner join "S" on "S"."S" = "S"."S"      and "S"."S" = 'S' inner join "S" "S" on "S"."S" = "S"."S" and "S"."S" = N inner join "S" "S" on "S"."S" = "S"."S" and "S"."S" = N where ( (("S"."S" = 'S') and ("S"."S" = 'S')) )Count: 81  Time=20.20s (1636s)  Lock=0.00s (0s)  Rows_sent=348107.9 (28196742), Rows_examined=696215.9 (56393484), hive[hive]@10hosts  SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0` LEFT OUTER JOIN `TBLS` `B0` ON `A0`.`TBL_ID` = `B0`.`TBL_ID` LEFT OUTER JOIN `DBS` `C0` ON `B0`.`DB_ID` = `C0`.`DB_ID` WHERE `C0`.`NAME` = 'S' AND `B0`.`TBL_NAME` = 'S' ORDER BY `NUCORDER0`Count: 14  Time=20.51s (287s)  Lock=0.00s (0s)  Rows_sent=1203952.1 (16855330), Rows_examined=10535169.1 (147492367), hive[hive]@14hosts  select `PART_ID`,`CREATE_TIME`,`LAST_ACCESS_TIME`,`PART_NAME`,`SD_ID`,`TBL_ID` from `PARTITIONS` st where ( PART_ID % N >= N ) AND ( PART_ID % N < N )

我这里就列举了几个，那看到这些sql，上面有显示是哪些用户发来的请求，如果你们公司每个服务都使用的不同的用户，那么从这就能知道是哪些应用发出的慢sql了，按设计来讲，应该只有hive metastore能够连接这个mysql主库，其他的应用想要操作hive元数据，应该通过hive metastore来操作，例如hiveserver2。比如上面所示的第二条sql，这个就是hive metastore发出的sql，这个之所以慢，是因为我们这有个表有100w的分区数，所以每次扫描分区的时候，都要从mysql查询100w的分区数据，因此导致的慢查询，这种就需要hive表进行优化；而其他的应用是不应该连接此mysql主库的，如果有，需要全部找出来然后打出去。

如果所有的应用都和hive metastore一样的用户，那么也没关系，这个时候你还是不知道这都是干什么的sql，没关系，那就继续找，既然这些sql是慢sql，那再去找有哪些服务连接了这个mysql不就可以了么？使用以下命令即可查看有哪些进程连接了此mysql

lsof -p mysqlPid

比如，我我找到一个：

TCP c2-dsj-hadoop178.bj:mysql->ali-a-dsj-hadoop05.bj:30098 (ESTABLISHED)

可以知道是ali-a-dsj-hadoop05.bj上的30098端口连接了我的mysql，那么登此服务器去查，这个端口是被谁占用的，lsof -i:30098，找到进程后查看具体服务即可；

最后，我找到了两类应用连接此mysql主库，一类是用来提供元数据查询的服务，一类是sqoop同步数据到hdfs的任务；至此，问题排查完毕；

五，总结

1，hive 元数据存储容易出现瓶颈问题，而hive metastore优化的一版都比较好；

2，哪里有问题，那就从哪里出发找问题，查配置，查进程状态，查日志；然后一层层往上追溯，总能找到问题点；