openGauss监控场景处理

2021-01-28 王鑫佳

openGauss监控场景处理

死锁数量异常

判断方法:

select sum(deadlocks) as deadlocks from dbe_perf.GLOBAL_STAT_DATABASE

异常分析:

  1. 请求与保持条件:获取资源的进程可以同时申请新的资源。
  2. 非剥夺条件:已经分配的资源不能从该进程剥夺。
  3. 循环等待条件:多个进程构成环路,并且每个进程都在等待相邻进程正占用的资源。
  4. 互斥条件:资源只能被一个进程使用。

解决方案

  1. 检索出死锁进程的ID(select oid,relname from pg_class where relname=‘all_date’;),检索出来的字段中,waiting字段数据为t的那条就是死锁进程,找到对应的procpid列的值。
  2. 将进程杀掉,select pg_cancel_backend(‘死锁那条数据的procpid值’),运行之后再次更新这个表,sql顺利执行。
  3. 如果pg_stat_activity没有记录,则查询pg_locks是否有这个对象的锁,select pid_locks where relation=‘上面查询出来的oid’;然后杀掉进程。

运维建议

  1. 在所有事务中都以相同的次序使用资源。
  2. 使事务尽可能简单并在一个批处理中。
  3. 为死锁超时参数设置一个合理范围。
  4. 避免在事务内和用户进行交互,减少资源锁定时间。
  5. 使用较低的隔离级别。

主备复制状态异常

判断方法

gs_om -t status|grep cluster_state|grep Normal|wc -l

异常分析

  1. 可能存在批量处理大量数据导致主从节点宕机,主节点重启后从节点WAL同步信息不完整。
  2. 主库宕机或者失联3.备库宕机或者失联。

解决方案

  1. 通过查看主备状态判断是主节点还是备节点故障。
  2. 主节点故障可以尝试重启主节点,若不生效,可以再备节点使用gs_ctl failover -D “备节点的数据目录”,然后刷新机器(gs_om -t refreshconf),这时如果主机好了,直接启动出现两主,这时使用gs_ctl build -D “主节点的数据目录” -b incremental。
  3. -b参数为指定重建备机的模式,incremental为取主备差异的数据增量修复备机。

备机回放gap使用空间异常

判断方法

select read_ptr-last_replayed_read_ptr as replay_gap from dbe_perf.GLOBAL_REDO_STATUS

异常分析

  1. 开启了数据文件的checksum,因为回放时需要大量的CPU资源,在进行checksum时会消耗startup进程的资源。
  2. 主库频繁的离散IO操作,如大量的索引变更,大量的vacuum操作。
  3. 频繁和大量的系统调用。

解决方案

  1. 关闭checksum,除非要防御物理篡改。
  2. 删除没有必要的索引。
  3. 根据业务调整垃圾回收的调度。
  4. 检查点拉长,可以减少full page的量。
  5. 加大备库的shared buffer。
  6. 关闭IO时间的跟踪。
  7. 备库使用IOPS能力更强,IO延迟更低的机器。
  8. 调整内核参数,使用并行apply。
  9. 如果有多个备库,备库可以关闭fsync。
  10. 将冻结年龄加大,可以减少冻结产生的redo。
  11. 增加单个进程可打开的文件数。

长查询时间异常

判断方法

select EXTRACT (epoch from max(current_timestamp - query_start)) from dbe_perf.SESSION_STAT_SCTIVITY where query_start is not null and state=‘active’ and application_name not like ‘dn_%’;

异常分析

  1. SQL未经过优化,没有走合适的索引。
  2. 可能存在锁争用问题。
  3. 可能存在全表扫描问题。

解决方案

  1. 查看对应语句的执行计划并作出相应的优化。
  2. 创建合适的索引。
【免责声明】本文仅代表作者本人观点,与本网站无关。本网站对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考,由此产生的所有法律责任均由读者本人承担。