如何排查 PX 执行卡住

PX 由接收 SQL 请求的主线程和查询计划中涉及的 Tablet Location Server 的 1 个或者多个线程共同执行，PX SQL 卡住可能会伴随 DDL 执行卡住 Schema Cache 长期占用不释放，租户队列积压，统计信息收集无法完成等异常。可按如下步骤排查。

PX 执行卡住问题排查

1. 确定各物理算子是否还在执行

   通过查询 Real Time Sql Plan Monitor 确定算子实时吐行是否有变化，如果持续增长，表明该 SQL 仍在执行，可以根据结果显示的查询计划进一步分析性能差的原因。

   这个 SQL 每次查询结果获得的是当前时间点算子的吐行信息，可反复查询多次观察算子吐行是否有变化，如下图。

   

   TRACE_ID 值可以通过命令 show full processlist 或视图 GV$OB_PROCESSLIST 获取。

   关于 Sql Plan Monitor 的使用简单说明可参考 Real Time Sql Plan Monitor 使用简介 这一节。

2. 获取各 Server 卡住线程

   由于 PX 线程执行和 session 绑定，因此可以通过 session 监控查看当前执行的 PX 各个线程信息，获取执行时间 time，各 OBServer 上的线程号，如下图。

   

3. obstack/pstack 获取线程堆栈。

   获取到线程号后可以看每个线程的卡住点，主线程通常是在消息循环，需要着重看各分布式子任务的堆栈有无异常，如下图。

   

   该堆栈为主线程堆栈，可看到包含 ObWorkerProcessor::process_one 关键字，如下图。

   

   注意

   obstack 或者 pstack 在线上/业务环境均需慎重使用，使用时需和 DBA 沟通。线下推荐 obstack，性能更好，并且可以聚合堆栈。

4. 日志获取 DTL 消息异常日志。

   在前面的步骤中已经获取到 TRACE ID，并且获取到在哪些 Server 上执行，可以去这些 Server 上获取日志，为了排除 DTL 在某些关键控制消息传输上失败，需搜寻 DTL Flush 消息失败的日志，如下图。

   

5. 主线程获取异常重试日志。

   部分 SQL 一直处于反复重试的逻辑上，现象上表现为卡住，主线程为接收 SQL 请求的线程，SQL 级重试除 DAS 外均在主线程完成，利用重试关键字获取相关信息。

   grep Y4E6A0B7C055D-0005F6B4998E148A-0-0 observer.log | grep 'check if need retry'
   

   输出结果如下图所示：

   

6. 尝试获取其他异常日志。

   由于 PX 执行会在多个 Server上，通过 TRACE ID 我们可以知道主线程 svr ip，svr port。

   TRACE ID 转 svr_ip, svr_port

   可在主线程先行搜寻日志, 如果无异常, 可搜寻所有 Server 同 TRACE ID 日志, 重点观察时间点最早的报错日志，如下图。

   

   end ddl 报 -4023 导致 PX 执行卡住。

Real Time Sql Plan Monitor 使用简介

功能说明

此功能用于监控SQL执行算子实时执行情况。

监控场景

• 当 SQL 加上了 /+ monitor/ hint时, 将纳入实时监控。

• 当 SQL 是分布式执行且 parallel > 1 自动纳入实时监控。

• 普通 SQL 如果执行时间 > 5s，自动纳入实时监控。

查询方式

• 查询全量监控信息。

  select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor;
  

• 查询实时监控信息。

  select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor where request_id < 0;
  

• 查询归档监控信息。

  select plan_line_id, plan_operation from oceanbase.gv$sql_plan_monitor where request_id >= 0;
  

适用版本

OceanBase 数据库所有版本。