一场源于老代码的性能危机

在日常技术支持中，有些问题简单直接，而另一些则深藏于陈旧的代码库中——一个看似微不足道的逻辑错误，就能让常规命令的执行效率跌入谷底。本文是系列第二篇，聚焦一起典型案例：一个隐藏在 libnss-db 中长达12年的 bug，导致 getent 命令的枚举操作变得异常缓慢。它充分展示了当客户提供精准证据与关键问题时，专业支持团队能够走多远。

问题根源：当枚举遇到“反复开关”

getent 是标准Linux命令，用于查询系统的名称服务（如用户、组、主机和服务信息）。本次事故中，客户在Ubuntu系统上使用 nssdb 后端枚举组信息时遭遇严重性能瓶颈。nssdb 后端通过 Berkeley DB 文件读取账户和组数据，而非依赖LDAP或本地文本文件。

客户环境包含超过24,000条用户与组条目，枚举速度已缓慢到后端几乎无法使用。此前客户曾尝试其他方案，但均未能达到所需的性能表现。

证据与初步方向

解决新版本包的常见问题已是不易，但这次调查更为棘手：问题藏在一个超过12年无人深入修改的旧组件中。客户已提前将范围缩小到 libnss-db（实现 nssdb 后端的遗留名称服务库），并重点指出一个关键逻辑参数：stayopen。

复现与验证

Canonical 支持工程师迅速确认 stayopen 的处理方式很可能是源头。该标志决定数据库连接在多次查询中是保持打开状态，还是每次操作都重新建立。工程师重现了问题，证实性能下降真实且严重。

不过，最初看起来像通用查询缓慢的问题，实际是枚举过程中反复进行数据库操作所致——每次操作的开销在大型目录下层层叠加，最终导致系统无法在合理时间内完成任务。

为了透彻理解，下一步需要深入软件源代码。调查从表面故障排查转向了源码级分析。这意味着要审视 libnss-db 本身：一个C语言编写的独立包，其核心代码已超过十年未变更。

深挖C代码：找到那行决定性的代码

支持团队由此开始代码级深度排查。工程师追踪 libnss-db 在枚举时处理 Berkeley DB 访问的流程，并跟随控制流走遍约12年前的旧代码。

很快，工程师发现了所有问题的根源：库在枚举期间处理数据库连接时存在逻辑错误。这不是靠修改设置或常规更新就能解决的。库会反复打开和关闭数据库文件，而不是在枚举序列全程保持连接。

性能瓶颈数据

• 单次枚举中，重复打开-关闭操作触发了48,422次磁盘读取。
• 这一行为形成了严重的性能瓶颈，使系统远超客户可接受的限值。

客户对 stayopen 的怀疑完全正确。确认该行为后，工程师立刻制作了补丁，强制在枚举期间保持数据库连接打开。

性能恢复：一次补丁扭转全局

修复效果立竿见影。通过在完整枚举序列中保持数据库打开，重复磁盘读取被消除，客户系统的性能得到恢复。

验证补丁后，案例被升级到 Canonical Sustaining Engineering团队，以便正式跟踪问题并推动更广泛的修复。随后在Launchpad上创建了缺陷记录，并将修改提议提交上游，涵盖包括Noble在内的较新Ubuntu版本。

案例启示：专业支持的价值

此案例是技术支持的典型范例：答案远超过一次包升级、配置变更或标准变通方案。通常情况下，那些方法更快捷，因为无需改动软件本身。但这里的问题藏在代码深处，必须通过细致复现、与具备技术知识的客户紧密协作，以及耐心阅读老旧源代码，才能彻底理解底层行为。

它也凸显了长期支持的实用价值。尽管问题出现在一个早已脱离主流社区关注的老组件中，但客户使用 Ubuntu Pro 与支持订阅，仍能完成调查、修补和升级。正是长期安全维护与直接工程专业知识的结合，使得一个原本可能无解的问题得到了解决。

如果您想了解 Canonical 支持如何运作，或探索它能为您的组织和系统带来的稳定与可靠性，欢迎访问我们的专用支持页面。若您有定制项目需要协助，或想了解可用的支持选项，请随时联系我们。

系列其他文章

上游变更如何导致智能卡FIPS认证失效，以及我们如何修复

---

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://ubuntu.com//blog/support-solves-bugs-in-12-year-old-code

---

请支持IMCN发展！

谁在捐赠

微信捐赠	支付宝捐赠

扫码关注公众号：智享开源