memavailable高于200mb无需清理缓存，因buff/cache是可自动回收的活内存；真正需干预仅当memavailable持续低于200mb、服务变慢、oomkiller触发或日志出现“memory pressure”。

别急着写定时脚本——先看 free -h 输出里的 MemAvailable。如果它还有几百 MB 以上，缓存压根不用动。Linux 的 buff/cache 是“活内存”，不是泄漏，系统缺内存时会自动回收。

什么时候真该清理？

真正需要干预的情况很明确：MemAvailable 持续低于 200MB、服务响应变慢、OOMKiller 被触发，或日志里频繁出现 “memory pressure” 提示。单纯看到 buff/cache 占满 80% 并不构成清理理由。

• 检查命令：free -h 和 cat /proc/meminfo | grep -E "^(MemAvailable|Cached|SReclaimable)"
• 排除干扰：确认没有进程锁住内存（grep -r mlock /proc/[0-9]*/status 2>/dev/null | head）
• 观察趋势：用 watch -n 30 free -h 看半小时内 MemAvailable 是否稳定回升

安全清理三步必须做全

直接 echo 3 > /proc/sys/vm/drop_caches 很危险——它会丢弃还没写进磁盘的脏页。数据库事务、日志追加、文件写入都可能中断。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 第一步：强制刷盘 —— 执行 sync（建议连写三次，确保所有缓冲区落盘）
• 第二步：提权写入 —— 不能用 sudo echo 3 > ...，正确写法是：sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' 或 echo 3 | sudo tee /proc/sys/vm/drop_caches
• 第三步：选对数值 —— echo 1 只清文件内容缓存（最常用、最安全）；echo 3 清全部，但影响更大

用 systemd timer 替代 cron

crond 在系统时间跳变、高负载时容易漏执行；systemd timer 支持延迟补偿、开机后补执行、电源状态判断，更适合生产环境。

• 创建 service 文件 /etc/systemd/system/clear-cache.service，内容含 Type=oneshot 和 ExecStart=/bin/sh -c 'sync && echo 1 > /proc/sys/vm/drop_caches'
• 创建 timer 文件，设 OnUnitActiveSec=3600（每小时触发一次），比 OnCalendar=hourly 更可靠
• 加一句 ConditionACPower=true，避免笔记本电池模式下误触发
• 启用：sudo systemctl daemon-reload && sudo systemctl enable --now clear-cache.timer

清理后没效果？查这几个地方

脚本跑完，free -h 显示 buff/cache 下降了，但 MemAvailable 没涨？常见原因：

• 刚释放的内存立刻被监控 agent、日志轮转、定时备份等进程占满
• 内核 slab 中仍有大量 SReclaimable（如 dentry/inode 对象），drop_caches 不动这部分；可临时调高 vm.vfs_cache_pressure=200 加速回收
• 有进程调用 mlock() 锁住内存，这部分不会被清理触及
• swap 正在使用中，MemAvailable 已扣减 swap 可用空间，清 cache 不改变该值计算逻辑