GaussDB--Ops巡检-等待会话数量异常如何解决?

75 阅读3分钟

告警解释

=======

DBS运维管理平台提供指标监控能力,监测到等锁状态的会话数量异常,产生此告警。

对系统的影响

此指标上涨,说明数据库内处于锁等待状态的会话数量多,如果语句长时间等锁,会导致等锁超时,严重时影响业务性能,SQL执行时延增加。

可能原因

并发场景产生锁等待。

处理步骤

  1. 收到告警后,通过查看监控指标查看指标“等待会话数量”,确认指标情况以及确认触发告警的组件。

  2. 通过查看监控指标查看业务关键指标,确认业务影响,涉及“Data Manipulation Language/s”、“95% SQL的响应时间”、“80% SQL的响应时间”和“线程池使用率”等指标。

    • 如果对业务有影响,执行3
    • 如果指标已回落,业务无影响,执行6
  3. 登录到告警的CN或者DN上,参考登录实例节点,通过如下语句查看当前执行的语句:

    select a.pid, a.sessionid, a.datname, a.usename, a.application_name, a.client_addr, a.xact_start, a.query_start, a.waiting,(now() - a.query_start)::text as query_runtime, a.unique_sql_id, w.wait_status, w.wait_event, w.locktag, w.lockmode, w.block_sessionid, a.query from pg_stat_activity a join pg_thread_wait_status w on a.sessionid = w.sessionid where a.pid <> pg_backend_pid() and a.usename not like 'rds%' order by query_runtime desc limit 50;
    

    state是active,waiting是t的语句即为等待中的会话,等待的会话是的block_sessionid对应的会话。

    如下图所示,第一个会话执行的语句拿锁,第二个会话执行的语句在等第一个会话执行的语句释放锁。

    确定了等待的会话,即示例中的第一条会话,执行4

  4. 执行语句。查看等待的会话的堆栈,保存定位信息。

    select gs_stack(pid);  
    

    pid:等待的会话对应的pid。

  5. 执行语句,查杀等待的会话,释放锁。

    select pg_terminate_session(pid, sessionid); 
    

    pid和sessionid为该会话对应的pid和sessionid。

    通过查看监控指标查看指标“等待会话数量”,确认指标波动是否下降。

    • 如果已下降,问题解决,需要定位原因,执行6
    • 如果没有回落,重复执行3~5
  6. 确认是否发生死锁。

    查看告警节点的日志:$GAUSSLOG/pg_log,通过死锁关键字“deadlock detected”确认告警时间点周围是否有发生过死锁。

    如果存在关键字“deadlock detected”日志,说明发生过死锁,死锁日志周围会有发生死锁的语句,联系客户从语句和事务逻辑分析,是否有不合理的并发。

  7. 确认是否有等锁超时。

    查看告警节点的日志:$GAUSSLOG/pg_log,通过等锁超时关键字“Lock wait timeout”确认告警时间点周围是否发生过等锁超时。

    • 如果存在关键字“Lock wait timeout”日志,说明发生过等锁超时,等锁超时日志包含持锁语句和等锁超时的语句。通过日志确定持锁的语句和超时的语句,联系客户分析并发是否合理,语句执行时长是否合理。

      语句分析和优化见ALM-5101180 Ops巡检-80% SQL的响应时间异常

    等锁超时日志解析:

告警清除

此告警修复后,系统会自动清除此告警,无需手工清除。

参考信息

不涉及。

更多详情请参考GaussDB 文档中心:doc.hcs.huawei.com/db/zh-cn/ga…