Canonical 技术案例 – 彻底解决 12 年老旧代码中的 Linux 性能漏洞

部分支持案例处理起来十分简单。另一些案例则要深入老旧遗留代码，一处逻辑缺陷就能悄无声息让常规指令引发严重性能故障。本系列将介绍 Canonical 技术支持与持续工程团队如何协作，排查、修复并向上游提交仅靠常规故障排查无法解决的疑难问题。在第二篇帖子中，libnss-db 中一处存在 12 年之久的漏洞导致 getent 枚举操作运行极其缓慢，同时也展现了当客户提供完整证据并精准提出问题时，专业技术支持所能达成的排查深度。

故障成因

Getent 是 Linux 标准命令，用于查询系统名称服务，以获取用户、用户组、主机及服务等信息。本案例中客户在 Ubuntu 系统使用该命令枚举用户组，选用 nssdb 后端时出现严重性能问题。nssdb 后端是 Linux 获取相关信息的一种方式，该方式从 Berkeley DB 文件读取账户与用户组数据，而非 LDAP、本地平面文件或其他身份数据源。 

在存储超过 24000 条用户及用户组条目的环境中，枚举操作速度极为缓慢，致使该后端基本无法使用。运行卡顿问题十分严重，导致客户业务负载无法正常使用该系统。客户已测试其他替代方案，但均无法达到其所需的性能标准。

从证据入手

新版本软件包的常见故障本就难以解决，而本次排查更是难上加难：该故障存在于一个超过 12 年无人维护迭代的老旧组件内。 

客户已将问题定位至 libnss-db，该组件为 nssdb 后端底层程序，是实现 nssdb 功能的遗留名称服务库。他们还指出了一段简短却关键的逻辑：stayopen。

复现卡顿问题

Canonical 技术支持工程师很快判定，stayopen 相关处理逻辑大概率是问题根源。Stayopen 是一个标志位，用于控制数据库连接是在多次查询期间保持打开状态，还是每次操作都重新建立连接。

技术支持工程师复现了该问题，并证实性能衰减真实存在且情况严重。然而，起初看似普通的查询卡顿问题，实则是枚举过程中数据库操作反复执行，海量目录条目下每一次操作的性能损耗不断叠加所致。数据量达到该规模后，系统无法在合理时长内完成对应操作。

想要彻底理清问题，下一步就需要深入查看软件源代码。该结果让排查工作从表层故障排查转入源码级分析。要解决该问题，必须深入分析 libnss-db 组件本身：这是一个独立软件包，其 C 语言源码十余年间基本未做改动。

深挖遗留 C 语言代码

至此，我们的技术支持团队开始开展深度源码剖析工作。工程师梳理了枚举过程中 libnss-db 访问 Berkeley DB 的处理逻辑，逐行追踪了部分已有约 12 年历史代码的执行流程。

工程师很快找到了所有问题的根源：该库在枚举时处理数据库连接存在逻辑缺陷。该问题无法通过简单更改设置或常规软件包更新解决。该库在整个枚举流程中反复打开、关闭数据库文件，并未保持连接持续开启。

关键代码行

大规模数据场景下，这种反复开关连接的操作会造成严重性能损耗。单次枚举操作就产生 48422 次重复磁盘读取，造成严重性能瓶颈，系统卡顿程度远超客户可接受范围。  该运行开销过高，彻底拖垮了整条查询路径。

客户此前对 stayopen 的怀疑最终得到证实，判断完全准确。工程师在代码中确认该异常逻辑后，编写补丁，强制枚举期间持续保持数据库连接开启。

如何恢复性能

该修复方案立刻优化了查询执行效率。在完整枚举流程中持续保持数据库打开状态，此举消除了重复磁盘读取操作，为客户恢复了系统性能。

在验证我方技术支持团队提交的补丁后，该案例升级至 Canonical 持续工程团队，以便对该问题进行正式跟踪，同时推动开发适用于所有环境的通用修复程序。随后在 Launchpad 提交漏洞工单，记录该问题并向上游提交修复方案，同时适配 Noble 等新版 Ubuntu 系统。

本案例的特殊之处

这个案例很好地诠释了一类技术支持场景：问题无法依靠软件包升级、修改配置或常规临时方案解决，需要深入底层排查。这类常规解决方式通常效率更高，无需改动软件本身即可解决问题。但本次问题根源存在于代码内部，因此必须开展深度排查。问题解决离不开完整复现故障、与具备专业技术能力的客户紧密协作，以及耐心研读老旧源代码，直至彻底理清底层运行逻辑。

这也充分体现了长期技术支持的实际价值。尽管该问题出在早已不受主流开发社区关注的老旧组件中，但凭借客户订阅的含技术支持服务的 Ubuntu Pro，我们仍可对问题开展排查、制作补丁并向上提报处理。长期安全维护与专业工程技术支持相结合，才得以解决这个原本可能无法处理的问题。

若您想了解 Canonical 技术支持的运作模式，或是了解其可为企业及系统带来的价值、稳定性与可靠性，欢迎访问技术支持页面。

如果您需要定制化项目相关协助，或想了解可选用的各类支持方案，欢迎随时联系我们。 

本系列更多内容

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