OpenAI vs DeepSeek：数据库诊断能力

原文地址：https://coroot.com/blog/engineering/using-ai-for-troubleshooting-openai-vs-deepseek

AI 已成为从写作到编码等一切环节的首选工具。LLM 非常强大，辅以正确的提示和一些调整，就可以利用它们轻松完成任务。

我们一直在试验 AI 的可观测性。故障排除的最后阶段，已经确定是哪个服务（如 Postgres）导致了问题，但由于可能的情况很多，找到确切的根本原因仍然棘手；我们的目标就是，在这种时候让 AI 发挥作用。

最近，我正在写一篇关于监控由 CloudNativePG 管理的 Postgres 集群的文章（https://coroot.com/blog/engineering/chaos-testing-a-postgres-cluster-managed-by-cloudnativepg）。我喜欢使用混沌工程来测试我们的产品，因此我建立了一个真实的 Postgres 集群，部署了一个客户端应用程序来产生负载，并（在一个 20GB 的表上）运行了一个有问题的查询：

ALTER TABLE ... SET body NOT NULL

这个查询影响了性能，因为它在检查空值时锁定了表。Coroot 很快检测到了这个问题，甚至在图表中突出显示了这个有问题的查询。

目前的效果很好，但 Coroot 需要太多脑力和理解复杂系统中因果关系的能力。最终目标应该是像你所做的那样，让 Coroot 提供具体的叙述性解释。

我完全同意。我们的许多用户并不是数据库、网络性能或特定运行时等领域的专家。我们需要提供清晰的解释，最好还能提供解决问题的指导。

因此，我决定在这个具体案例上再次测试 AI。懒惰往往会推动进步：我没有将遥测数据转换成提示，而是直接上传了一张截图作为 LLM 的输入。

结果让我大吃一惊。

OpenAI GPT-4o
这是我的提示，没有提供其他背景信息：

答案是：

从所提供的 PostgreSQL 监控仪表板来看，似乎是 ALTER TABLE 语句造成了性能问题，导致

1. 查询延迟增加
   1. Postgres 平均查询延迟激增，尤其是 pg-cluster-2。
2. ALTER TABLE 带来的I/O 负载
   1. ALTER TABLE语句（alter table articles alter column body set not null）消耗了大量 I/O，如I/O 时间查询图所示。
3. 锁定连接和查询

   1. Postgres 连接图显示锁定连接急剧增加。

   2. 锁定查询图证实，由于 ALTER TABLE 操作，查询被阻塞。

   3. 阻塞查询图显示 ALTER TABLE 查询持有锁并阻塞了多个其他查询。
4. 复制滞后
   1. 复制滞后显示了一个峰值，可能是由于 ALTER TABLE 操作造成了写入积压。

为什么？

1. ALTER TABLE ... SET NOT NULL 是一种全表操作，需要进行全表扫描，以确认没有现有记录违反新约束。
2. 它会锁定整个表，在操作完成前阻止写入/读取。
3. 这在频繁读/写的高负载环境中尤其容易出现问题。

如何修复？即时解决方案：
1.终止ALTER TABLE语句（如果可能）：如果系统处于生产状态，且锁定导致停机，请考虑取消查询：

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE query LIKE '%ALTER TABLE articles alter column body set not null%';2.

重新启动受阻查询：取消 ALTER 表后，系统应恢复正常运行。不过，有些查询可能仍在等待，因此请检查是否有任何残留锁：

SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL;

长期解决方案：ALTER TABLE 的成本较高，因此考虑以下方式：

1.转换为在线友好方法

与其使用 ALTER TABLE ... SET NOT NULL，不如使用更安全的方法：

步骤 1：添加检查约束（非阻塞）

ALTER TABLE articles ADD CONSTRAINT articles_body_not_null CHECK (body IS NOT NULL) NOT VALID;

步骤 2：回填缺失值（如果有）

步骤 3：验证约束条件（仍为非阻塞）‍

ALTER TABLE articles VALIDATE CONSTRAINT articles_body_not_null;

步骤 4：如果不存在违规行为，则更改该列

ALTER TABLE articles ALTER COLUMN body SET NOT NULL;

2.使用pg_repack实现零停机迁移pg_repack 允许在没有全锁的情况下重组表

pg_repack -t articles --dbname=mydatabase

3.在低流量时段执行 schema 变更

生产环境中，在维护窗口期间执行 schema 变更以减少影响。

4.对大型表进行分区

对于频繁更改的大型表，可考虑分区，以便在较小的分段上隔离操作。

结论

ALTER TABLE 操作锁定了文章表，导致严重的查询延迟和复制滞后。最好的办法是：

1. 如果造成停机，取消操作‍

2. 使用在线安全替代方法（检查约束 + 验证）‍

3. 谨慎安排 schema 变更‍

使用 pg_repack 等工具，将影响降至最低。这给人留下了深刻印象，准确度也令人惊讶。最让我震惊的是，该模型能够将截图解释为输入。

我们正在把 AI 集成到 Coroot 中，但不会使用截图，因为用程序解释复杂的系统参数要简单得多。

LLM 能够「理解」我们的领域，并生成具有可操作性见解的深度总结，这令人兴奋。然而，依赖单一供应商似乎并不是一个稳健的解决方案。

幸运的是，DeepSeek 已经成为 OpenAI 模型的有力替代品，尤其是最近发布的 R1 模型。DeepSeek 的开源特性也让我们在需要时可以选择自托管，不过这暂时不在我们的计划之内。

现在，让我们使用 DeepSeek-R1 重复实验：

DeepSeek-R1

答案是：

数据显示 pg-cluster-2 中存在严重的性能问题，主要原因是文章表上的 ALTER TABLE 命令长时间运行。该操作导致表锁定，阻塞其他关键查询（如SELECT和INSERT），从而导致

- 高查询延迟（10-15 秒）

- 活动/锁定连接激增‍‍

- 查询吞吐量下降‍‍

- 其他集群的复制滞后（轻微）

根本原因

ALTER TABLE 语句（alter table articles alter column body set not ?）

1. 对文章表持有独占锁‍‍

2. 阻塞后续查询（如 SELECT、INSERT）‍‍

3. 创建一连串等待查询，增加了延迟和连接使用

解决方案立即修复1. 终止 ALTER TABLE 命令（如果安全）：

-- Find the PID of the ALTER TABLE query SELECT pid, query FROM pg_stat_activity WHERE query LIKE '%alter column body%'; -- Terminate it SELECT pg_terminate_backend();

注意：确保不会损坏数据（例如，如果ALTER是迁移的一部分）。

2. 重新安排 DDL 操作：

在低流量时段运行 schema 变更，或使用在线 DDL 工具，如

- pg_repack（在没有锁的情况下重建表）

- CREATE INDEX CONCURRENTLY（针对与索引相关的更改）

3. 优化 ALTER 表：

要将列设置为NOT NULL，确保它已不包含NULL值。预运行：

UPDATE articles SET body = '' WHERE body IS NULL; -- Example cleanup

长期改进‍‍1. 使用锁定超时： 添加锁定超时，防止无限期阻塞：

SET LOCAL lock_timeout = '5s'; ALTER TABLE ...;

2. 监控和调整查询：‍‍‍

- 优化 'SELECT id FROM articles WHERE created < ? ...' 查询，并为created创建索引。

- 批处理INSERT操作以减少争用。
3. 连接池：
使用连接池器（如 PgBouncer）管理活动连接并防止连接耗尽。

4. 复制检查： 调查 'pg-cluster-1' 和 'pg-cluster-3' 中的复制滞后情况，确保故障切换准备就绪。

总结

阻塞ALTER TABLE是关键问题。首先通过终止或重新安排操作来解决这个问题，然后实施保障措施来避免类似事件。优化查询，并使用无锁定 DDL 工具进行未来的 schema 变更。

DeepSeek-R1 提供的答案与 OpenAI 的相当接近。我认为它的准确度足以替代 OpenAI 的模型。此外，我还在实验室测试了其他开源模型，但只能运行多达 700 亿个参数的 LLM。在这个范围内，我没有发现任何模型能够接近 OpenAI 或更大的 DeepSeek 模型，以满足我们的需求。

这是否代表 AIOps 终于来临？

是的，但前提是有足够的数据来描述系统行为。

正如上面所述，答案已经存在，我们只需要解释图表并得出结论。这种情况下，AI 的魔力在于它能够理解全局，综合运用知识，并提出解决问题的建议。仅凭 CPU、内存和磁盘使用率是无法做到这一点的。