CentOS 垃圾回收策略总览
在 CentOS 环境中，“垃圾回收”通常包含两类：一是面向应用运行时的内存垃圾回收（如 Java GC），二是面向操作系统层面的资源回收（如内存页、缓存、日志与临时文件、包管理器缓存等）。下面按这两类给出可落地的策略与操作要点。
一、应用层垃圾回收策略（以 Java 为例）
- 明确回收目标：吞吐优先、低延迟或低停顿，结合 SLA 与 RT 要求选择 GC 算法与参数。
- 常用参数范式（示例为 JDK 8 及更早的 CMS 组合，仅作思路示例，生产请结合版本与负载压测）：
- 堆大小固定且充足：-Xms6g -Xmx6g
- 年轻代与 Survivor 区比例：-XX:NewRatio=4 -XX:SurvivorRatio=8
- 并行年轻代 GC：-XX:+UseParNewGC
- CMS 并发标记清除：-XX:+UseConcMarkSweepGC
- 并发回收触发阈值：-XX:CMSInitiatingOccupancyFraction=72
- 并发线程数：-XX:ParallelCMSThreads=4
- 版本与算法选择建议：
- JDK 8：优先考虑 G1 GC（如 -XX:+UseG1GC），在可控停顿与吞吐间更易平衡。
- JDK 11+：优先 ZGC 或 Shenandoah（低停顿），需评估内核与 JDK 版本支持。
- 实践要点：
- 避免频繁 Full GC：合理设置堆与新生代，减少对象过早晋升。
- 结合 JVM 监控（如 jstat -gc、VisualVM、Async Profiler）与业务指标做闭环调优。
- 容器/虚拟化环境需显式设置堆上限，避免被 cgroup 限制“看不见”。
二、操作系统层资源回收策略
- 内存页与缓存回收
- 内核会自动回收页面缓存、目录项与 inode 缓存；不建议常态手动清理。若确需释放，可在维护窗口执行：
- 同步数据并清理缓存：sync && echo 3 > /proc/sys/vm/drop_caches
- 仅在必要时清理，避免影响前台业务 I/O 性能。
- 调整回收倾向（需谨慎、结合压测）：
- 降低换页倾向：vm.swappiness（如设置为 10，默认通常为 60）
- 调整 VFS 缓存压力：vm.vfs_cache_pressure（如 50）
- 使配置永久生效：写入 /etc/sysctl.conf 后执行 sysctl -p
- 日志与临时文件
- 使用 logrotate 做日志轮转、压缩与保留策略，避免 /var/log 无限增长。
- 定期清理临时目录：/tmp、/var/tmp
- 谨慎清理日志：优先使用 logrotate 或按时间截断，避免直接删除正在写入的日志文件。
- 包管理器缓存与旧内核
- 清理 YUM 缓存：yum clean all
- 删除无用依赖：yum autoremove
- 清理旧内核（保留最近 1–2 个）：package-cleanup --oldkernels --count=1
- 大文件与空间分析
- 快速定位占用：df -h、du -sh /、按条件查找大文件（如 find / -type f -size +100M）
- 交互式分析：ncdu 定位“空间大户”，再定向清理。
- 回收站与用户目录
- 清空用户回收站：rm -rf ~/.local/share/Trash/*（多用户环境逐用户处理）
- Swap 管理
- 仅在维护窗口执行：swapoff -a && swapon -a（会触发大量换入换出，可能导致短时性能下降）
- 桌面与工具
- 可选清理工具：BleachBit（图形/命令行）清理临时文件、缓存与浏览器垃圾（谨慎选择项目）。
三、日常维护与监控建议
- 例行巡检
- 空间：df -h、ncdu
- 内存与负载：top、vmstat、sar
- 内核与 I/O：dmesg、iostat
- 自动化与预防
- 启用并校准 logrotate（按业务保留天数/大小）
- 规范临时文件生命周期（应用侧使用 /tmp 或专用工作目录，定期清理）
- 控制软件安装范围，减少无用依赖与历史内核积累
- 对数据库/中间件设置合理内存上限与连接数，避免 OOM 与频繁回收
- 变更风险控制
- 参数调整、缓存清理、内核参数变更、旧内核删除等，务必在维护窗口进行并保留回退方案
- 变更前后采集指标（吞吐、RT、P95/P99、错误率），验证效果
四、常见误区与风险
- 将 drop_caches 作为日常操作：会破坏内核页面回收的自然节奏，增加 I/O 抖动，仅在特殊维护窗口使用。
- 盲目降低 vm.swappiness 到 0：可能导致内存紧张时无法换出，增加 OOM 风险；应根据负载与延迟目标调优。
- 直接删除 /var/log 下正在写入的日志：可能导致服务异常或审计缺失，优先用 logrotate 或按时间截断。
- 随意关闭 swap：在内存紧张时可能引发进程被 OOM Killer 终止，建议结合工作负载与性能目标综合决策。
- 旧内核清理过度：至少保留 1–2 个可回退版本，避免升级失败无法回滚。
以上策略可按“应用层 GC 优化 + 系统层资源回收 + 持续监控预防”的闭环执行，既保证稳定性，又能在需要时快速回收资源。