发布于

OushuDB排查集群与资源管理器

资源管理器(rm)的主要职责是监控集群状态与资源使用情况。其中 master-rm 进程负责分配资源,segment-rm 负责监控节点。当怀疑资源管理器发生问题时我们可以通过日志、系统表和 lldb 来排查问题。

资源管理器重启

通常资源管理器只会在两种情况下发生重启:

  1. 资源管理器自身发生致命错误导致重启。
  2. 其他 OushuDB 进程发生致命错误导致 OushuDB 重启,从而引起资源管理器重启。

排查方法:

  1. 通过 select * from gp_configuration_history; 获取每个 segment-rm 的详细历史信息。gp_configuration_history 原则上只有当节点状态发生改变时记录一条信息。通常我们有以下几种状态改变情况:
    1.1. segment-rm 启动: up
    1.2. segment-rm 检测出节点问题: up->down
    1.3. master-rm 无法探测到 segment-rm: up->down
    1.4. segment-rm 从错误状态中(1.2.,1.3.)恢复: down->up
    1.5. segment-rm 在正常情况下发生致命错误: up->up
    1.6. master-rm 发生致命错误:全部活跃 semgnet-rm 会重新记录信息
    由此我们可以知道,当 gp_configuration_history 中某 segment-rm 连续出现两次 up 且明确知道较新的信息不是手动启动产生的,则 segment-rm 发生了致命错误。若发现某一时刻所有 semgnet-rm 信息全部重新记录了,且未手动重启 master-rm,则 master-rm 发生了致命错误。
  2. 在日志中搜索 RM process works now 我们可以明确的知道 master/segment-rm 的启动和重启时间。设此日志出现在第 L 行,则第 L 行前的日志会明确的记录资源管理器重启的原因,通常两者距离不会太远,且大部分情况下会出现 terminate 关键字。
    另外每一条 RM process works now 会有对应的 pid,若 pid 不一致,则可以通过 pid 快速搜索每一次 rm 的运行情况。

节点处于断线:

如果已经明确知道节点状况良好(包括不限于:segment-rm 进程正常执行,临时目录正常,节点间通信正常),但是在 gp_configuration_history 依然显示断线,则由两种情况:

  1. 未将节点分配给虚拟机群(pg_vcluster)
  2. 域名解析不一致,pg_vcluster 中使用的域名并不能解析成正确的节点 ip,当有多张网卡时此问题会变的尤为复杂。

获取资源管理器内部信息:

当无法通过日志和系统表推断出问题时,获取资源管理器内部信息是至关重要的,这涉及三个 SQL:
1.select dump_resource_manager_status(1);
2.select dump_resource_manager_status(2);
3.select dump_resource_manager_status(3);

资源使用情况排查

资源使用情况只由 master-rm 维护,通常我们通过以下几个系统表来获取:

  1. select * from pg_vcluster;
  2. select * from pg_resqueue;
  3. select * from pg_resqueue_status;

通常资源管理器暂停服务有以下几种可能:

  1. inusemem >= segsize
  2. rsqholders == activestats
  3. paused != F

若前面两个情况没有发生但是第三种情况发生则只能通过获取资源管理器内部信息仔细排查。

如果能够明确知道造成瓶颈的 SQL,则可以通过执行计划以及日志中的分配请求来判断是否有资源指标存在异常,例如申请的内存极大,需求的 vseg 数极大,需求 slice 数极大等。

资源管理器无响应

通常界定资源管理器是否无响应是一个困难的事情,然而我们可以首先获取资源管理器内部信息来初步界定问题:

  1. 若能成功获取信息则意味着资源管理器依旧在工作。我们需要界定是 SQL 执行缓慢还是资源管理器无法做出分配。
    1.1. 获取资源使用情况判断是否使用资源已达上限
  2. 若未能获取信息则大概率是通信问题,小概率是 master-rm 出现了真正意义上的 hung

接下来唯一能够获得有效信息的办法是 lldb attach -p pid 获取 backtrace 并尝试单步执行和在分配逻辑中设置断点。这并没有统一的操作方法,只能由开发人员配合代码逐步推敲。

资源管理器发生致命错误

首先需要界定是资源管理器发生了致命错误,还是其他进程发生致命错误引发连锁反应导致资源管理器重启。此时现场已经不复存在,能够提供信息的有 coredump 文件和当时的日志信息。

评论(5)
  • zhenchuan1
    zhenchuan1 回复

    RM 并发配置问题定位常用的计算公式

    1. 集群资源总量 = seg 数(集群 segment 数)* hawq_rm_memory_limit_perseg * memorylimit * overcommit

    2. 最大可分配 vseg 数 = 集群资源总量 / vsegresourcequota

    3. activestats:最大并发 SQL 数

    4. vseg 数计算
      有序列表 有序列表查询 HASH 表 1 个 slice 的 vseg 数 = hash_table_bucket_number / seg 数
      查询随机表 1 个 slice 的 vseg 数 = min(max_nvseg_perquery_perseg,max_nvseg_perquey / seg 数)
      插入随机表 INSERT INTO SELECT = select 的表 1 个 slice 的 vseg 数
      插入 HASH 表 INSERT INTO SELECT = hash_table_bucket_number / seg 数
      udf qe 数固定,vseg 数固定
      magma 表 = magma_hash_table_nvseg_perseg
      (判断 magma 表是否走 rm 可以看下 AllocateResource, calculate_planner_segment_num 函数)
      ANALYZE

      1. 有序列表非 partition 表 = hawq_rm_nvseg_for_analyze_nopart_perquery_perseg_limit
      2. 有序列表 partition 表 = hawq_rm_nvseg_for_analyze_part_perquery_perseg_limit
    5. 单节点最大 slice 数限制 hawq_rm_nslice_perseg_lim = slice 数 * 并发 SQL 数

    6. 单节点 seg 数
      seg_max_connections (看下 postgres.conf 中的 max_connections 是否注释掉)
      udf 的 qe 数是固定的

test