最新

这是我一直在使用的一个工具，用于eBPF程序的性能分析和优化，刚刚发布，因为它让我的“性能极客生活”变得更轻松。 这个工具用于分析eBPF程序本身、探针与内核活动、与共享哈希表的交互等。 由于eBPF程序是驻留在（内核）地址空间中的机器代码片段，你可以像分析其他内核函数一样，使用标准的perf工具对它们进行分析。然而，单靠perf无法显示其他有用的指标，比如执行次数和平均eBPF程序运行时间，这些是<i>bpftop</i>能够提供的。此外，我希望能够轻松地将CPU样本映射到原始源代码行，尽可能做到这一点。 我想要将这两种方法<i>统一</i>，显示bpftop风格的调用计数和探针延迟，并能够深入分析eBPF程序花费大部分时间的地方。

我在一家初创公司工作，开发武术健身房管理软件（MAAT）。我们负责学生的会员管理，这样健身房老板就不必操心，使用支付系统和数据库。随着我们接入的健身房越来越多，支持任务也随之增加：订阅问题、会员更新、数据导出等。 我们目前的解决方案是一个“llms.txt树”。一个llms.txt通常引用网站或文档上可用的信息——我们在内部使用相同的思路来组织代理所需的信息。代理从一个文件夹开始，向下导航： ``` ├── llms.txt # 引用该层级的每个文件夹 ├── stripe/ # info.md: 我们的Stripe账户结构 ├── firestore/ # info.md: 架构的样子 └── support/ ├── info.md # 如何解决支持任务 ├── runbooks/ # 每个任务一个文件，包含自己的llms.txt │ ├── cancel-subscription.md │ ├── export-gym-data.md │ └── fix-membership-mismatch.md └── logs/ # 每天一个文件，记录代理解决的每个任务 ``` 通过这种方式，我们可以更好地引导代理，并在每次出现新的支持任务时创建新的运行手册。 您可以在每个集成中添加代理应该处理和不应该处理的内容。gcontext提示确保任何保护措施都被严格遵循。