我们都知道，在开发和维护后台服务时，监控函数的执行时间是至关重要的。通过监控，我们可以及时发现性能瓶颈，优化代码，确保服务的稳定性和响应速度。然而，传统的方法通常涉及在代码中添加统计信息并上报，这种方法虽然有效，但往往只针对那些被认为是关键路径的函数。

假设在某个时刻，我们突然需要监控一个并非重点关注的函数的执行时间。在这种情况下，修改代码并重新部署服务可能是一项繁琐且耗时的任务。这时，eBPF（扩展的伯克利数据包过滤器）和 BCC（BPF 编译器集合）就派上了用场。通过使用 eBPF，我们可以在不修改代码和不重新部署服务的情况下，动态地插入探针来监控函数的执行时间。这不仅大大简化了监控过程，还减少了对服务性能的影响。

在接下来的文章中，将详细介绍如何利用 eBPF BCC 来无侵入地分析服务函数耗时，并通过实际示例来展示其强大的功能。

本文是 ChatGPT Prompt 最佳指南系列的第四篇，全部系列文章：

1. ChatGPT Prompt 最佳指南一：写清晰的说明；
2. ChatGPT Prompt 最佳指南二：提供参考文本；
3. ChatGPT Prompt 最佳指南三：复杂任务拆分；
4. ChatGPT Prompt 最佳指南四：给模型思考时间；
5. ChatGPT Prompt 最佳指南五：借助外部工具；
6. ChatGPT Prompt 最佳指南六：系统基准评测；

在我们的生活中，当面临复杂问题时，通常需要花费一些时间来深思熟虑。正如一位作家在撰写一篇文章时需要时间来组织思路和打磨措辞，或者一位棋手在对弈时需要时间来分析局势和制定策略一样，深思熟虑是一种必要的过程。人工智能也有类似的需求，确切地说，GPT 也需要一些时间来为我们提供更深入、更精确的答案。

您可能会疑惑：“机器怎么会需要时间来思考？”这是一个很好的问题。事实上，给GPT-4模型“思考”的时间，并不是字面意义上的让它思考，而是给它更多的机会来搜索、分析和优化它的回答。这与给一位作家时间来组织思路和打磨措辞，或者给一位棋手时间来分析局势和制定策略是类似的。在这些情况下，时间成为了提升结果质量的关键因素。

接下来通过示例，我们一起来看下如何通过提示词，让 GPT-4 模型有更多的“思考时间”。

在 Redis Issue 分析：流数据读写导致的“死锁”问题(1) 中，我们成功复现了 Issue 中提到的 bug，观察到 Redis Server CPU 飙慢，无法建立新的连接，现有的连接也不能执行任何读写操作。借助强大的 ebpf profile 工具，我们观察到了 CPU 时间主要消耗在哪里，接下来我们一起来看下这个 BUG 的调试过程和修复方法。

调试 bug

考虑到 Redis server 进程还在，我们可以用 GDB attach 到进程上，打断点看下具体的执行过程。在火焰图上看到的比较耗时的 handleClientsBlockedOnKey 函数里面有 while 循环语句。而 CPU 飙满的话一般都是死循环，为了验证是不是有死循环在这个 while 里，可以在 whil 前面的 565 行和里面的 569 行打上断点，然后 continue 多次进行观察。

1
2
3
4
5

while((ln = listNext(&li))) {
    client *receiver = listNodeValue(ln);
    robj *o = lookupKeyReadWithFlags(rl->db, rl->key, LOOKUP_NOEFFECTS);
    ...
}