NAND Flash 写入过量告警问题分析与处理

问题概述

在 BMC Web 界面中上报一条轻微告警（Minor），具体信息如下：

• 事件码：0x1A000043
• 事件描述：The data written to the NAND flash in last 15 days exceeds 12G
• 告警级别：轻微（Minor）
• 产生时间：2025-05-31 18:40:33（依据知识图谱数据）

该告警表示：在过去 15 天内，写入到 NAND Flash 的数据总量已超过 12GB 的阈值。该行为可能影响 NAND Flash 的使用寿命，需引起关注。

核心信息确认

根据用户上传的 nandflash_info.txt 日志内容：

Total Written Amount          : 12.028GB
Total data written in 15 days : 12.026GB
Data written per day in 15 days : 8.993GB 2.792GB 0.241GB ...

结论：该告警为真实告警，并非误报。实际 15 天内写入量达到 12.026GB，接近阈值。

告警原理与背景

相关实体解析

触发机制

• BMC 实时监控 NAND Flash 的写入量。
• 当过去 15 天累计写入量 > 12GB 时，自动触发告警 0x1A000043。
• 告警归类为 Minor（轻微），不中断业务，但提示潜在风险。

注：NAND Flash 寿命与 P/E 次数（Program/Erase Cycle）相关，频繁写入将加速老化。

可能原因分析

尽管用户尝试确认日志和固件包体积远小于 12GB，但仍出现大量写入，结合知识库信息，可能存在以下 隐蔽性高写入来源：

1. 高频传感器数据采集

• 若启用了定期执行 ipmcget -t sensor -d list 等命令进行传感器轮询，且频率过高（如秒级），会产生持续的小写操作。
• 此类操作会累积成大量 I/O 写入 NAND。

2. 数据库频繁写入 + 写入放大

• 使用 SQLite 等本地数据库的组件（如 power_strategy）可能采用“先清空再逐条插入”的方式更新数据。
• 每次插入/删除都涉及 B+ 树结构调整，导致 实际闪存写入量 >> 数据本身大小（即“写入放大”）。
• 典型案例：300KB 数据导致 20MB 闪存写入。

参考文档：【persistence】问题定位方法&FAQ #5.4

3. 未使用事务批量提交

• 若数据库操作未使用 db:tx() 批量事务机制，而是逐条调用 save()，每条记录都会触发一次磁盘写入。
• 当操作 ≥5 条时，应使用事务合并写入以减少 I/O。

4. 日志刷盘频率过高

• 系统日志、调试日志或组件 trace 日志若设置为高频率强制刷盘（flush），也会造成写入暴增。
• 特别是 Lua 脚本中异常捕获后频繁输出 debug 日志。

5. 配置或状态频繁变更

• 某些管理功能（如 Redfish 接口频繁修改配置）可能导致系统状态频繁持久化。
• 如 LED 控制、电源策略切换、风扇调速等若由外部脚本高频调用，会触发大量写操作。

处理建议与优化措施

1. 重启 openBMC（初步恢复）

reboot

• 可临时缓解当前告警状态。
• 注意：若根本原因未解决，告警将在后续周期重现。

2. 分析 nandflash_info.txt 中每日写入分布

当前片段仅显示前三天写入：
8.993GB → 2.792GB → 0.241GB
推测存在某次突发性大量写入事件（如日志风暴或配置重置）。

建议：

• 获取完整 Data written per day in 15 days 数据。
• 定位写入高峰发生在哪一天，结合该时间段的操作日志进行关联分析。

3. 检查 mdb_info.log 中数据库写入统计

路径：AppDump/<component>/mdb_info.log
查找 local persistence write statistics 字段，重点关注：

• 是否有组件在短时间内执行了数百次数据库写入？
• 是否存在“先清空再重插”的模式？

示例排查命令（设备上执行）：

iostat -k -d 1 1

在触发疑似写入动作前后运行，观察 NAND 所在分区的 kB_wrtn/s 是否显著上升。

4. 优化数据库写入逻辑

对于本地持久化组件，必须遵循：

db:tx(function()
    for _, item in ipairs(data_list) do
        table.insert(db_item, item)
    end
end)

避免：

for _, item in ipairs(data_list) do
    item:save()  -- ❌ 每次 save 都是一次写入！
end

5. 控制日志级别与输出频率

• 关闭不必要的 DEBUG 级别日志。
• 避免在循环中输出日志。
• 使用条件判断限制日志输出频次。

6. 审查定时任务与自动化脚本

检查是否有外部监控系统或内部 cron 任务频繁调用：

• IPMI 命令查询
• Redfish 接口更新配置
• Sensor 信息轮询

建议降低采集频率（如从每秒改为每10秒以上）。

参考资料与延伸

官方讨论链接（建议阅读）

https://discuss.openubmc.cn/t/topic/1693

该论坛链接已被系统推荐，可能包含类似案例分析及最佳实践。

关键日志路径

总结与建议

最终建议：联系设备厂商技术支持，提供完整一键日志包，重点分析 mdb_info.log 与 nandflash_info.txt，识别最大写入源并进行代码或配置优化。

提示：建议将 NAND 写入监控纳入日常运维巡检项，防患于未然。