接上文http://boylook.blog.51cto.com/7934327/1298637说下遇到的另外一个CASE：在排查一个线上问题的过程中发现callqueue这几天出现了spike：

122535564.png


继续查看发现最近的waiting_maps数和spike非常match

122557341.png


进而通过grace定位到了一个具体业务的Hive清洗Job：

122613238.png


发现这个Hive表A有大量的小文件（最大的才16MB），这个表A是通过对一个外部表B以insert select方式生成的，而hive.merge.smallfiles.avgsize是默认值（16MB），所以在生成后map也只是最大merge到了16MB左右；将hive.merge.smallfiles.avgsize修改为dfs.block.size，同时将当前这个查询表A的Job 加上了set mapred.min.split.size=dfs.block.size*2; setmapred.min.split.size.per.node= dfs.block.size*2；set mapred.min.split.size.per.rack= dfs.block.size*2 重跑，果然在不降低运行时间的基础上把MAP数大大降低了；