监控群里昨天又炸了一次。“XX 服务内存告警free 只剩 200MB”运维同学半夜爬起来登上去敲了free -h看了一眼回群里丢了句“没事正常别慌。”新来的同学不理解200MB 也叫正常这就是 Linux 内存管理最容易被误读的地方。而且更要命的是——很多公司监控面板上的内存使用率公式本身就是错的。free 的输出只有一列值得看total used free shared buff/cache available Mem: 62Gi 18Gi 200Mi 1.2Gi 44Gi 41Gi大部分人盯着free那一列看然后开始慌。但真正决定这台机器还能不能再接活的是最后一列available。关系是这样的available ≈ free 可回收的 buff/cacheLinux 的设计哲学是空闲内存是浪费。只要还有空内存内核就拿它去缓存磁盘数据page cache因为磁盘比内存慢好几个数量级。这些缓存不是被占用了是被借用了——一旦应用要内存内核可以立刻回收还给应用。所以free只有 200MB 完全可能毫无压力available有 41Gi 才是真相。这也顺带解释了为什么内存用了 70%的服务器跑得好好的那 70% 里绝大部分是 page cache。你的监控公式可能是错的这条是我见过最普遍的问题。很多老的监控脚本、自研的采集插件内存使用率是这么算的# 错误写法used_percent(total -free)/ total *100在free200MB / total62GB的机器上这个公式会告诉你使用率99.7%然后疯狂告警。而实际上这台机器一点事没有。正确写法只有一种# 正确available 才是应用真正能拿到的内存used_percent(total - available)/ total *100或者直接读/proc/meminfogrep-E(MemTotal|MemAvailable|Buffers|Cached|Dirty|Slab)/proc/meminfo看一眼你的告警规则。如果表达式里出现的是node_memory_MemFree_bytes那你的告警大概率一直在误报正确的是node_memory_MemAvailable_bytes-alert:HighMemoryPressureexpr:(node_memory_MemTotal_bytes-node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes0.85for:5mdrop_caches千万别在生产上敲搜Linux 清理内存第一条永远是echo3/proc/sys/vm/drop_caches看着很爽free立刻给你回一大截。但这个动作的实质是把磁盘缓存全丢掉逼系统接下来重新从磁盘读一遍。后果是接下来一段时间磁盘 I/O 飙升、所有服务响应变慢。你在生产上敲这一行等于主动给自己制造一次性能事故。内核自己会回收不需要你手动掺和。这条命令的正确使用场景只有一个跑基准测试时想要可复现的冷启动环境。那什么时候才是真的危险不是free少而是回收开始跟不上分配。判断信号看这几个一、vmstat里的si/so持续不为 0。vmstat2# si: 每秒从 swap 换入的 KB so: 每秒换出的 KBsi/so一直是 0说明没有换页压力。一旦持续有值就是在拿磁盘当内存用了,应用响应会明显劣化。二、Direct Reclaim。内核有个后台线程kswapd负责提前回收内存。当分配速度超过它回收的速度分配内存的进程自己被迫停下来同步回收——这就是 Direct Reclaim表现是莫名其妙的卡顿长尾。用 eBPF 抓vmscan相关事件能直接看到。三、OOM Killer 日志。这是最后的兜底dmesg|grep-ikilled process看到Out of memory: Killed process 12345 (java)才是真正的内存不足——和free数字大小没关系。保护关键进程oom_score_adjOOM Killer 挑人下手是按oom_score打分的分越高越先被杀。而打分的一个主要权重就是进程占了多少内存——这意味着吃内存最多的数据库往往是最先被杀的。# 看某个进程的分数cat/proc/$(pidof mysqld)/oom_score# 保护它分数范围 -1000永不被杀到 1000echo-500/proc/$(pidof mysqld)/oom_score_adjsystemd 服务可以直接写进单元文件[Service] MemoryMax4G MemoryHigh3G OOMScoreAdjust-500注意MemoryMax和MemoryHigh是 cgroup v2 的MemoryHigh是软限制超过就开始回收但还能用MemoryMax是硬限制超过就直接杀。用MemoryHigh做缓冲比直接撞MemoryMax温和得多。一个反常识的参数THP 该关透明大页Transparent Huge Pages默认是开的cat/sys/kernel/mm/transparent_hugepage/enabled# [always] madvise never它的好处是减少 TLB 缺失对通用负载Web 服务、文件服务确实有收益。但对延迟敏感的数据库建议关掉或改成madviseechomadvise/sys/kernel/mm/transparent_hugepage/enabled原因在后台守护进程khugepaged——它会频繁扫描并合并小页导致不可预测的 CPU 峰值和内存锁竞争在 MySQL、PostgreSQL、Redis、Elasticsearch 这类场景下表现为查询延迟的微秒到毫秒级抖动。内存碎片严重时THP 还可能触发激进的 Direct Compaction直接造成服务超时。常用参数速查参数作用建议vm.swappiness倾向回收匿名页还是文件页数据库/缓存 010通用 60默认vm.dirty_ratio进程自己开始回写脏页的阈值写敏感调低如 510减少 I/O 抖动vm.dirty_background_ratio后台回写启动阈值通常 5vm.vfs_cache_pressure回收 dentry/inode 的积极程度读多写少降到 50内存紧张提到 200vm.overcommit_memory内存超额分配策略Redis 要设 1避免 fork 失败再补一条冷知识跑 Redis 一定要设vm.overcommit_memory1。不设的话主从同步时的 fork 可能直接失败日志里只有一句含糊的报错查半天查不出来。最后把这篇压缩成三句话看available不看free。你的告警公式最好现在就去改。drop_caches不是运维命令是压测工具。生产上敲它等于自残。内存不足的证据是 Direct Reclaim 和 OOM 日志不是free的小数字。Linux 的内存管理设计得相当聪明——它在努力让你的磁盘访问变快而不是在偷偷占你的内存。先理解它在帮你再决定要不要打断它。