SD卡越用越慢？从日志到真相的系统性排查指南

SD卡越用越慢？从日志到真相的系统性排查指南

很多人都遇到过：设备刚开始运行流畅，放在SD卡上的系统用了一段时间之后，卡顿、响应迟缓、偶发性“假死”开始出现。内存不高？CPU不强？硬件老化？其实，真正的元凶，往往藏在存储子系统的一个字母组合里：I/O。本文尝试用一篇读完能直接上手的文章，带你用日志和指标“验尸”，确认SD卡是否真的变慢、为什么变慢、以及能做些什么。

为什么是SD卡？

SD卡是廉价、便携、兼容性强的存储介质，被广泛用于路由器、边缘设备、树莓派、监控、数据采集终端等。但与SSD或eMMC相比，SD卡的控制器与缓存能力弱、耐久设计有限、固件算法简单，面对持续小块写入、频繁fsync、空间接近写满时，性能衰减会非常明显，甚至出现秒级停顿。这不是个别品牌的问题——是介质特性叠加使用方式带来的“宿命”。

典型症状包括：

• 系统运行一段时间后交互明显变慢，尤其在有日志写入、数据库刷新或定时任务触发时
• CPU负载高但大多在“等待I/O”
• 偶发性“卡死”几秒到几十秒，随后又恢复
• 内核日志出现超时、重试、复位、I/O错误

要确认“SD卡是凶手”，需要从系统日志、块层统计、文件系统状态、驱动层信息，以及应用行为多角度交叉验证。下面进入实操。

一、第一现场：先确认“卡顿是否与I/O相关”

当系统卡顿时，第一时间要捕捉整体态势，避免“盲人摸象”。

• 观察CPU与I/O等待
  • top/htop：关注%wa（I/O wait），它代表CPU在等待磁盘I/O完成的时间比例。如果卡顿时%wa飙高，是强烈信号。
  • vmstat 1：持续采样，wa列高企说明系统在磁盘层面被“阻塞”。
  • iostat -x 1（若可用）：看设备的%util、await、r_await/w_await、avgqu-sz。%util接近100%、await显著升高，是“卡”的直观证据。
• 内核日志（dmesg）
  • 筛关键字：mmc、sdio、I/O error、timeout、reset、ext4/xfs error、Buffer I/O error、journal aborted
  • 如果出现“Timeout waiting for hardware interrupt”“resetting controller/link”“频繁重试”等，基本指向存储设备层面问题。

这一步是“定性”：卡顿确实和磁盘I/O有关，而非CPU计算或网络拥塞。