hive如何算占比_ALM-16000 连接到HiveServer的session数占最大允许数的百分比超过阈值（2.x及以前版本）

当收到“ALM-16000 连接到HiveServer的session数占最大允许数的百分比超过阈值”告警时，最直接的应对是：立即降低HiveServer的并发连接数，或调大最大允许session数，并排查是否存在连接泄漏或负载过高。

这个告警在FusionInsight 2.x及以前版本中很常见，本质是HiveServer当前活跃会话数逼近了配置上限，如果不处理，新任务可能无法提交，甚至导致HiveServer假死，下面我按“先看懂告警，再定位原因，最后操作解决”的顺序,把这件事讲透。

这个告警到底在说什么

告警触发机制与“占最大允许数的百分比”计算

HiveServer会为每个客户端连接创建一个session，系统会统计当前session数，除以配置的最大允许session数，得到一个百分比，当这个百分比超过设定阈值（默认通常是80%），就会触发ALM-16000告警。

• 关键参数：hive.server2.max.sessions（不同版本可能叫法略有差异，2.x里常见于HiveServer的自定义配置）
• 阈值配置：在FusionInsight Manager的告警设置里，可以调整“百分比阈值”，比如改成90%再触发
• 告警级别：一般分为“紧急”和“重要”，取决于超过阈值的程度

为什么session数会涨这么高

多数情况下不是单一大查询导致的，而是连接管理问题,常见场景如下：

• 应用侧使用JDBC连接后没有显式关闭，连接池空闲连接长期占用
• 某个业务方并发提交大量任务，且每个任务都建立独立session
• HiveServer自身存在session回收延迟，比如查询卡在“编译”或“获取锁”阶段
• 其他组件（如Hive Metastore）响应慢，导致session堆积

如何用命令快速确认当前session数

在FusionInsight 2.x环境里，登录HiveServer所在节点,用以下命令查看实时连接状态：

# 查看HiveServer进程 ps -ef | grep HiveServer # 通过netstat统计ESTABLISHED连接数（近似session数） netstat -anp | grep 24000 | grep ESTABLISHED | wc -l

默认HiveServer JDBC端口是24000（或10000，取决于版本），如果这个数值接近hive.server2.max.sessions,就说明快满了。

更准确的方式是进入beeline,执行：

这个命令会列出当前所有session，包括用户、IP、启动时间，如果看到大量同IP的session,基本可以断定是某个应用连接泄漏。

临时降低告警影响：先止血再根治

直接调大最大允许session数

如果当前并发确实属于业务正常需求，且机器内存足够，可以临时调高上限,操作路径：

1. 登录FusionInsight Manager
2. 进入“服务” -> “Hive” -> “配置”
3. 搜索hive.server2.max.sessions
4. 将默认值（比如500）调大到1000
5. 保存并重启HiveServer实例

注意：调大session数会占用更多JVM堆内存，如果HiveServer的-Xmx设置不够大，OOM风险会上升，建议同步调大HIVE_SERVER2_JVM_OPTS中的堆内存参数。

杀掉异常占用session的客户端

如果发现某些连接长时间空闲，可以直接从HiveServer侧断开，在beeline中无法直接kill session,但可以在Linux层面杀掉对应TCP连接：

或者更简单粗暴，重启HiveServer实例，所有session会被清空，但重启期间服务不可用,需要评估业务容忍度。

从应用侧排查连接池配置

这是最治本的方法，常见的连接池（如HikariCP、Druid或C3P0）都有maxActive和maxIdle参数，如果应用配置的maxActive是200，但实际并发只需要50，那么这200个连接会一直占用HiveServer的session数,建议：

• 将maxActive调小到实际并发峰值的1.5倍
• 设置idleTimeout和connectionTimeout，让空闲连接及时回收
• 在应用代码中确保finally块里执行connection.close()

如何配置告警阈值，避免频繁误报

根据业务低谷和高峰调整

如果告警只出现在每天固定的跑批时段，且不影响任务执行，可以适当提高阈值百分比，在FusionInsight Manager中：

1. 进入“告警管理” -> “告警” -> “ALM-16000”
2. 点击“阈值设置”
3. 将“百分比阈值”从80%调整为90%
4. 将“紧急阈值”调整为95%

行业共识认为，告警阈值应该设置为“可能影响业务但尚未造成失败”的水平，如果业务高峰期session占用率长期在85%左右，设为90%会减少夜间误报。

设置周期性session清理

HiveServer本身没有自动回收空闲session的机制，但可以通过hive.server2.session.check.interval（有些版本支持）来控制检查频率,另一个办法是使用系统crontab定时执行连接清理脚本：

# 每小时清理空闲超过30分钟的session（需要根据实际环境调整） # 通过beeline执行SHOW SESSIONS，然后对空闲session执行KILL

长期预防：从应用和集群两个维度优化

应用端强制使用统一Session池

很多团队每个MapReduce任务都新建一个Hive连接，导致连接风暴，业内专家指出，HiveServer的最大session数不是用来扛并发任务的，而是用来管理连接资源的,正确做法是：

• 使用同一个Hive JDBC连接池，复用连接
• 对于流式提交的任务，使用HiveServer的HTTP模式（如果支持），减少TCP连接开销
• 避免在循环内部创建连接

集群端监控session增长趋势

建议在Grafana或FusionInsight监控面板中，自定义一个“HiveServer Session数”的曲线图，如果发现session数只升不降，说明存在连接泄漏，可以设置一个周维度的阈值，session数连续12小时高于最大允许数的60%”,触发告警分析。

与Yarn队列资源联动

有时候session数高，但实际查询并不重，因为HiveServer会为每个session分配一块内存用于编译和规划查询，大量空闲session也会消耗内存，如果Yarn队列资源紧张，可以同时检查“ALM-18002”类似告警（如果存在）,判断是资源不足还是连接过多。

常见问题排查与Q&A

Q1：ALM-16000告警出现后，HiveServer一定会挂吗？

不一定，如果只是短暂高峰，比如同时提交了100个任务，每个任务执行几秒，session数会很快下降，但如果是连接泄漏，session数会持续上涨，最终超过最大允许数，导致新的连接被拒绝，所以出现告警后，先观察session数变化趋势,再决定是否干预。

Q2：如何区分是业务并发高还是连接泄漏？

看session的分布，如果所有session来自同一个IP，且每个session都关联一个“Idle”状态，基本可以断定是连接泄漏，如果session来自多个IP，且都在执行查询，那就是业务并发确实高，也可以用SHOW SESSIONS查看每个session的“state”列，RUNNING和IDLE的比例一目了然。

Q3：调大max.sessions后，HiveServer需要重启吗？

在FusionInsight 2.x中，修改hive.server2.max.sessions后，需要重启HiveServer实例才能生效，但要注意，重启会中断当前所有session，所以尽量在业务低峰期操作，如果不想重启，可以尝试通过动态配置接口修改，但2.x版本对动态更新支持有限,不建议依赖。

回到开头那句话：告警不可怕，可怕的是不排查就盲目调参。 先看session来源，再判断是连接泄漏还是正常并发，最后决定调大上限、清理连接还是优化应用，多数情况下，应用侧连接池的合理配置就能避免这个告警反复出现，如果经过上述操作后告警仍然频繁，建议检查HiveServer的GC日志和堆内存使用情况,进一步定位是否存在内存泄漏。