LibreNMS IPv6邻居发现导致MySQL高负载问题分析与解决方案

问题背景

在LibreNMS网络管理系统中，用户报告了一个关于IPv6邻居发现功能导致MySQL数据库服务器CPU使用率飙升的问题。该问题主要出现在监控约7000台思科CPE路由器的较大规模部署环境中，自25.3.0版本升级后开始出现。

问题现象

当系统执行自动发现(discovery)过程时，MariaDB数据库服务会消耗掉服务器所有CPU核心资源（最初8核，扩展到16核后仍被完全占用）。通过性能监控工具观察到，在发现过程中MySQL的"read rnd next"操作达到惊人的4000万次，而正常情况下应低于10万次。

根本原因分析

经过深入调查，发现问题的核心在于IPv6邻居发现功能的设计实现存在以下关键问题：

1. 索引缺失：IPv6邻居发现相关的数据库表缺少必要的索引，导致大量全表扫描操作
2. 数据量差异：IPv6邻居表条目数量通常比IPv4 ARP表高出几个数量级
3. 执行频率：发现过程每4小时执行一次，在工作时间尤为明显

临时解决方案

用户通过以下方法暂时缓解了问题：

1. 在全局设置中禁用"ARP表"发现模块(discovery_modules.arp-table)
2. 使用NetFlow替代IPv6邻居发现功能来追踪MAC与IPv6地址的绑定关系

永久解决方案

开发团队已确认并修复了主要问题：

1. 为IPv6邻居发现相关表添加了必要的索引
2. 考虑将IPv4 ARP发现和IPv6邻居发现功能分离，允许独立配置

最佳实践建议

对于大规模部署LibreNMS的用户，建议：

1. 性能监控：定期检查数据库性能指标，特别是发现过程期间的CPU使用率
2. 模块选择：根据实际需求选择性启用发现模块
3. 版本升级：及时升级到包含修复补丁的版本
4. 硬件规划：为数据库服务器预留足够的CPU资源，特别是在高峰发现时段

总结

IPv6邻居发现功能在大型网络环境中可能带来显著的数据库负载问题。通过理解问题本质并采取适当的配置调整，可以有效平衡功能完整性和系统性能。LibreNMS团队持续优化系统性能，建议用户关注后续版本更新以获取更好的使用体验。