问题描述
环境：
- 开发调度平台：数栖平台4.18（16000+任务，7000+工作流）
- 大数据平台：CDH 5.12.0，大数据组件默认版本
- BI工具：FineBI
- 实时数仓：Dolphinscheduler + StarRocks
问题
离线跑批任务，偶尔会有个别工作流出现java.net.SocketTimeoutException: Read timed out错误。手动重跑工作流就可以了。通过分析日志，怀疑是HiveServer2端连接压力过大，做了两个操作：
-
调整了HiveServer2的超时时间。
-
在数栖平台调整了任务的调度时间，让分布更加均衡。
之后基本上就较少出现类似问题了。
某天下午16点左右，同事反馈所有任务提交，马上报java.net.SocketTimeoutException: Read timed out错误。Yarn上一个Hive任务都拉不起来。所有任务都提交不到Yarn上。
查看HiveServer的连接情况：
排查
- 询问是否有同事调整过CDH集群参数，回答无。
- 是否有同事调整过数栖平台的参数及服务运行环境，回答无。
基础环境没有人调整过，按理说就不应该有问题。
- 询问是谁发现的？
- 执行什么操作发现的？
回答，执行了一个脚本，该脚本还卡住没有出来。
怀疑是脚本问题，强制Kill掉脚本。
问题依旧，存在。
于是重启，hive、hdfs服务。
集群短暂可以提交任务到Yarn，一会儿又出问题了。所有Hive任务无法提交Yarn，报同样的java.net.SocketTimeoutException: Read timed out。
参考文章：https://blog.csdn.net/xin_jmail/article/details/85004967自检，发现和我们的症状不完全相同。
监控CDH Hive的指标，发现开发平台无法提交Hive任务到Yarn时，连接数暴涨。
查看HiveServer的连接数配置，是100.于是修改为200.发现能提交任务，一段时间，又不能使用了。
初步断定是提交Hive任务的客户端与Hive server之间的连接数不够了。但是为啥不够呢？
回顾下图：
怀疑是Hive Client端异常了。我们的环境只有数栖平台的Hive Client端提交Hive任务。
于是想到，前面几天数栖平台的Hive Client端修改配置参数。扩大了Java内存和并发量。怀疑是重试机制及并发数太大导致。
于是，暴力重启数栖平台的Hive Client端的提交Hive任务的代理服务。
观察：正常。
结论
HiveServer2-java.net.SocketTimeoutException: Read timed out问题，主要还是和连接数密切相关，有的可能是BUG导致的连接数不释放，例如https://blog.csdn.net/xin_jmail/article/details/85004967提高。有的可能是客户端和服务端，通信异常，导致大量的异常连接占用连接数，而不释放。还有的可能就是性能不足。