原文地址：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 语句造成了性能问题，导致
- 查询延迟增加
- Postgres 平均查询延迟激增，尤其是 pg-cluster-2。
- ALTER TABLE 带来的I/O 负载
- ALTER TABLE语句（alter table articles alter column body set not null）消耗了大量 I/O，如I/O 时间查询图所示。
- 锁定连接和查询
Postgres 连接图显示锁定连接急剧增加。
锁定查询图证实，由于 ALTER TABLE 操作，查询被阻塞。
- 阻塞查询图显示 ALTER TABLE 查询持有锁并阻塞了多个其他查询。
- 复制滞后
- 复制滞后显示了一个峰值，可能是由于 ALTER TABLE 操作造成了写入积压。
为什么？
- ALTER TABLE ... SET NOT NULL 是一种全表操作，需要进行全表扫描，以确认没有现有记录违反新约束。
- 它会锁定整个表，在操作完成前阻止写入/读取。
- 这在频繁读/写的高负载环境中尤其容易出现问题。
如何修复？即时解决方案：
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 操作锁定了文章表，导致严重的查询延迟和复制滞后。最好的办法是：
如果造成停机，取消操作
使用在线安全替代方法（检查约束 + 验证）
- 谨慎安排 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 ?）
对文章表持有独占锁
阻塞后续查询（如 SELECT、INSERT）
- 创建一连串等待查询，增加了延迟和连接使用
解决方案立即修复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、内存和磁盘使用率是无法做到这一点的。
热门跟贴