↓ 跳过正文
Greatfinish Blog

dmtop：一个面向达梦数据库的实时性能诊断 TUI

·592 字·3 分钟
达梦数据库 开源工具 达梦 DM8 Dmtop 性能诊断 性能优化 实时监控 TUI Go Linux SQL优化 锁等待 DBA 开源工具
Greatfinish
作者
Greatfinish
记录 Oracle、PostgreSQL、达梦、Linux、存储与生产环境故障处理经验。
目录
dmtop logo

Dameng Database Real-Time Performance TUI

项目地址：https://github.com/greatfinish/dmtop

当前版本：v0.2.1 · Lower Overhead Sampling

开源协议：MIT License

为什么要做 dmtop
#

当有人反馈“数据库突然变慢了”，DBA 通常不会一上来就知道问题在哪里。传统排查链路往往是先登录数据库主机，依次执行：

top -H -p $(pgrep -o dmserver)
vmstat 1
iostat -x 1
sar -n DEV 1

先判断 CPU、内存、Swap、磁盘和网络是否异常；然后再进入数据库查询：

SELECT * FROM V$SESSIONS;
SELECT * FROM V$TRX;
SELECT * FROM V$TRXWAIT;
SELECT * FROM V$SYSSTAT;

接下来还要手工完成几件事：

  • 将 Linux 高 CPU 线程 TID 映射到数据库会话；
  • 从会话继续找到当前 SQL、存储过程内部 SQL和执行计划；
  • 判断是 CPU 计算、磁盘延迟、提交同步、解析压力还是锁阻塞；
  • 出现行锁时，找出根阻塞会话以及完整的阻塞关系；
  • 在处理会话前反复核对 SID、用户、客户端和 SQL，避免误操作。

这些命令和动态视图都很有价值，但它们分散在不同终端、不同采样时刻和不同统计口径中。现场越着急，越容易在命令切换、字段关联和口径判断上消耗时间，短暂出现的性能窗口也可能随之消失。

DEM、性能快照和 AWR 类报告适合更完整的平台化监控、历史分析与趋势回溯，但在“我已经登录故障主机，希望马上看清当前发生了什么”的场景中，部署、采集和报告分析链路相对更长。

这就是我开发 dmtop 的初衷：

不建设另一套监控平台，只做一个轻量、直接、能够快速收拢现场证据的达梦性能诊断工具。

dmtop 是什么
#

dmtop 是一个使用 Go 编写的 DM8 本机实时性能诊断 TUI。它直接读取 Linux /proc 和达梦动态视图，把原本分散在操作系统命令与数据库数据字典中的证据放进同一个终端界面。

dmtopmain.png

它希望快速回答五个问题：

  1. 当前压力来自 CPU、内存、磁盘还是网络？
  2. 哪个数据库会话和 Linux 线程正在消耗 CPU？
  3. 哪条 SQL 正在执行，存储过程内部真正执行的 SQL 是什么？
  4. 哪个会话阻塞了哪个会话，根阻塞者是谁？
  5. 解析、计划缓存、提交同步和锁等待是否出现异常？

整体定位可以概括为：

Linux /proc                         DM8 dynamic views
CPU / memory / disk / network       V$SESSIONS / V$SYSSTAT / V$TRXWAIT / ...
           \                              /
            +-------------+--------------+
                          |
                        dmtop
                          |
              +-----------+-----------+
              |           |           |
              v           v           v
             OS          DB        PROCESS
                                      |
                              +-------+-------+
                              |               |
                              v               v
                         SQL Detail       LOCK CHAIN

一个界面，串起完整诊断链
#

1. DATABASE：先确认正在诊断谁
#

第一行展示数据库模式、状态、数据库名、实例名、数据库运行时间、实例数量和归档状态。

这一步看似简单，却能避免在多实例、多环境或主备架构中看错目标。性能诊断的第一条原则，永远是先确认当前证据属于哪个实例。

2. OPERATING SYSTEM PERFORMANCE：先判断主机瓶颈
#

OS 区域集中展示：

  • CPU user、system、idle、iowait；
  • 1/5/15 分钟负载与运行、阻塞进程数；
  • 内存 used/free/cached 与 Swap；
  • 最热磁盘的 util、await、RIO/WIO、RMB/WMB；
  • 网络 RX/TX。

这些指标直接来自本机 /proc。不用在 top、vmstat、iostat 和 sar 之间来回切换，先在一屏内判断问题更像 CPU、内存、I/O 还是网络方向。

3. DATABASE PERFORMANCE：再判断数据库负载类型
#

DB 区域展示数据库当前采样区间的核心证据：

  • sessions、active、idle、transaction、trx waits（等待事务关系数）、AAS 近似快照；
  • QPS、TPS、用户提交、逻辑读、物理读写、Redo；
  • 缓冲命中率、内存池和排序内存；
  • Parse、Hard Parse、Hard%、Parser Error、Plan Hit；
  • Redo Sync、Lock Wait 和 Deadlock 增量。

这里尤其强调“采样口径”。速率类指标使用相邻采样差值，首帧不会把未知值伪装成精确的 0；累计指标与当前区间指标也不会混在一起误导判断。

4. PROCESS：从会话直接下钻到 Linux 线程和 SQL
#

PROCESS 区域按当前采样区间 %CPU 从高到低排列，最多显示 20 个用户会话，主要字段包括：

SID  TID  %CPU  RUN_T  STATE  USERNAME  SQL_TEXT_ID
CLNT_IP  CLNT_HOST  APPNAME  SQL_TEXT

其中 TID 来自 V$SESSIONS.THRD_ID，可以直接与下面的 Linux 命令对齐：

top -H -p $(pgrep -o dmserver)

这意味着发现 dm_sql_thd 高 CPU 后，不再需要手工猜测它属于哪个数据库会话。dmtop 已经把 OS TID、数据库 SID、用户、客户端和 SQL 放到同一行。

选中会话按 Enter，可以继续查看三层 SQL 证据：

  • V$SESSIONS.SQL_TEXT：客户端提交的 SQL 或 CALL；
  • CUR_SQLSTR：当前真正执行的内部 SQL；
  • SF_GET_SESSION_SQL(SID)：当前会话的完整 SQL。

这对存储过程高 CPU 场景尤其有用。主界面看到的可能是：

CALL RIS.P_CPU_BURN(600, 10000);

进入详情后，则可以继续看到过程内部真正消耗 CPU 的 SELECT。

按 x 输入 SQL_TEXT_ID，还可以查看完整 SQL 和执行计划。

阻塞关系不只报数字，而是直接画出链路
#

发现数据库存在事务等待时，仅仅显示“1 条等待关系”还不够。DBA 真正需要的是：谁堵住了谁，根阻塞者是谁，锁住了什么对象。

dmtop 基于 V$TRXWAIT.WAIT_FOR_ID 展示真实阻塞关系：

ROOT BLOCKER  ──[LOCK OBJECT]──>  WAITER

多级阻塞会沿 ROOT BLOCKER -> WAITER 方向展开，同时关联双方 SID、TID、用户、锁对象和等待时长。没有阻塞时，LOCK CHAIN 区域不会占用主界面空间。

确认确实需要关闭异常会话时，可以按 k 输入数据库 SID。工具会重新展示目标会话证据，并要求二次确认后调用：

SP_CLOSE_SESSION(SID);

这里输入的是数据库 SID，不是 Linux TID。dmtop 会拒绝关闭自身连接和内部会话；也不建议直接对达梦线程执行 kill -9。

几条典型的定位路径
#

CPU 突然升高
#

OS CPU/load
    -> PROCESS %CPU/TID
    -> Enter 查看 CLIENT_SQL/CURRENT_SQL/FULL_SQL
    -> x 查看完整 SQL 和执行计划

行锁或事务阻塞
#

DB trx waits/LOCK
    -> LOCK CHAIN
    -> ROOT BLOCKER -> WAITER
    -> 核对 SID/TID/用户/客户端/SQL
    -> 必要时按 k 安全关闭会话

磁盘延迟或提交变慢
#

OS disk util/await/RIO/WIO
    -> DB PRD/PWR/REDO/SYNC
    -> 判断是本地磁盘、数据库写入还是同步提交方向

解析压力
#

PARSE/s + HARD/s + HARD% + PERR/s + PLANHIT
    -> SQL RT / SQL CUM
    -> 定位当前或累计重 SQL

为什么坚持本机运行，不引入 Agent
#

dmtop 的目标不是跨主机集中监控，而是现场快速诊断。

如果连接远程数据库，数据库指标来自远程实例，但 /proc 反映的却是运行 dmtop 的本机，OS 与 DB 证据会错配。为保证同一屏中的证据属于同一台机器，dmtop 推荐直接放在达梦数据库服务器本地运行。

因此它有意保持简单：

  • 一个 Linux 静态二进制；
  • 不部署 Agent；
  • 不依赖 disql；
  • 不启动常驻服务；
  • 不要求 Go 工具链；
  • 不长期保存监控数据。

登录故障主机、运行程序、输入密码，即可开始观察。

为不同 DM8 版本做兼容降级
#

不同 DM8 补丁版本的动态视图字段可能存在差异。如果一条采集 SQL 强依赖某个新字段，就可能出现“仅缺一个字段，整个 PROCESS 区域都没有数据”的情况。

dmtop 启动时会查询：

V$DYNAMIC_TABLES
V$DYNAMIC_TABLE_COLUMNS

先确认目标版本具备哪些视图和字段，再选择兼容 SQL。单项能力不可用时只降级为 N/A 或 -，不会因为一个可选字段缺失而清空整个 PROCESS。

此外，监控 SQL 会使用会话 ID 和 /*dmtop*/ 标记双重排除自身，尽量避免把诊断工具自己的查询显示成业务负载。

快速安装
#

在 v0.2.1 Release 下载对应架构的发布包。

Linux amd64：

curl -LO https://github.com/greatfinish/dmtop/releases/download/v0.2.1/dmtop-v0.2.1-linux-amd64.tar.gz
tar -xzf dmtop-v0.2.1-linux-amd64.tar.gz
cd dmtop-v0.2.1-linux-amd64
chmod +x dmtop
sudo install -m 0755 dmtop /usr/local/bin/dmtop

Linux arm64：

curl -LO https://github.com/greatfinish/dmtop/releases/download/v0.2.1/dmtop-v0.2.1-linux-arm64.tar.gz
tar -xzf dmtop-v0.2.1-linux-arm64.tar.gz
cd dmtop-v0.2.1-linux-arm64
chmod +x dmtop
sudo install -m 0755 dmtop /usr/local/bin/dmtop

如果没有 sudo 权限，也可以直接在解压目录运行 ./dmtop。

默认连接本机 5236 端口：

dmtop SYSDBA

指定主机和非默认端口：

dmtop SYSDBA -host 127.0.0.1 -port 5237

程序会在终端中隐藏密码输入，不需要把密码写进命令行或 shell history。

常用交互键
#

按键作用
m返回 PROCESS
s / S打开 SQL RT / SQL CUM
Tab / ← / →在 PROCESS、SQL RT、SQL CUM 之间切换
Enter查看选中会话或 SQL 的详细证据
x输入 SQL_TEXT_ID，查看完整 SQL 与执行计划
k输入数据库 SID，核实并关闭会话
e打开 ENV 按需信息
f冻结或恢复刷新
h查看完整帮助
q返回或退出

dmtop 不是什么
#

产品边界越清晰，工具越容易保持小巧和可靠。

dmtop 不是：

  • 数据库巡检工具；
  • 7×24 小时监控平台；
  • 告警系统；
  • 跨主机集中管理平台；
  • DEM、Exporter/Prometheus 或 AWR 类历史分析的替代品。

它关注的是“现在发生了什么，以及下一步应该沿哪条证据链继续查”。长期趋势、历史回放、告警和巡检报表，仍应该交给专业的持续监控体系。

开源与反馈
#

dmtop 目前处于持续迭代阶段。不同 DM8 版本、补丁和业务负载都可能带来新的兼容场景，非常欢迎达梦 DBA 试用并提供真实反馈。

如果这个工具对你的故障定位有帮助，欢迎 Star、提交 Issue，或者提供不同达梦版本下的字段差异和诊断案例。

我的目标不是把所有功能都塞进一个终端，而是让 DBA 面对突发性能问题时，少切换几个窗口、少拼接几段 SQL，更快地从“数据库慢”走到“具体是哪台主机、哪个线程、哪个会话、哪条 SQL 或哪条阻塞链”。

这就是 dmtop 想解决的问题。