available值高但系统卡顿，主因是内核高开销内存管理（如脏页刷盘、碎片整理、kswapd扫描），而非内存总量不足；swappiness=60会过早触发回收扫描，建议调至1，并检查pgmajfault、PageTables等隐性压力指标。
内存 available 值充足但系统仍频繁卡顿，大概率不是内存总量问题，而是内核在后台持续做高开销的内存管理动作——比如疯狂回收页缓存、反复换入换出、或被 OOM Killer 干扰。这种“假富余、真挣扎”的状态，比内存彻底耗尽更难察觉。
为什么 free -h 显示 available 很高，却 still 卡？
Linux 的 available 是估算值，它假设当前缓存可无代价释放。但现实是：某些缓存（如脏页、mmap 映射、tmpfs 文件）无法立即回收；当内核被迫在后台同步刷盘、压缩内存、或重试分配时，CPU 和 IO 就会被拖慢，用户感知就是“卡”，而非“爆内存”。
-
available高 ≠ 内核分配路径顺畅 —— 可能正卡在__alloc_pages_slowpath里反复尝试、睡眠、唤醒 - 看
vmstat 1中的pgmajfault（次缺页中断）：持续 >100/s 说明进程频繁触发页面加载，背后可能是文件映射抖动或内存碎片 - 查
dmesg | tail -20是否有page allocation failure或order N allocation failed—— 这表示物理内存虽够，但连续页不足（尤其大页场景）
swappiness=60 是罪魁祸首之一
默认 swappiness=60 会让内核在 available 还剩 40% 时就开始扫描并换出匿名页。哪怕没真正写入 swap（si/so=0），这个扫描行为本身就会占用 CPU、干扰 LRU 链表遍历，导致调度延迟上升。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 对数据库、实时服务等低延迟场景，应设为
vm.swappiness=1（仅当available接近 0 时才考虑 swap） - SSD 服务器上设为
1后，kswapd0进程 CPU 占用通常下降 50%+，卡顿明显缓解 - 临时生效：
echo 1 > /proc/sys/vm/swappiness；永久写入/etc/sysctl.conf
应用层隐式内存压力常被忽略
Java、PostgreSQL、Node.js 等服务若未显式限制内存，会向内核申请远超实际需要的地址空间。这些虚拟内存虽不立刻占物理页，但会挤压内核的 vmalloc 区域、增加 TLB miss，并在 fork 或 mmap 时引发反碎片化压力。
- Java 应用务必加
-XX:+UseCGroupMemoryLimitForHeap（容器）或-XX:MaxRAMPercentage=75.0（宿主机），避免堆外内存失控 - PostgreSQL 的
shared_buffers不宜超过物理内存 25%，否则会和内核 page cache 抢页框，反而降低文件读取效率 - 检查
/proc/<pid>/status</pid>中的VmRSS（实际物理占用）与VmSize（虚拟地址空间）比值，若长期
真正该盯的三个指标，不是 used/available
卡顿发生时，free -h 的 available 往往还在“安全区”，但以下三个指标已亮红灯：
-
pgmajfault持续 >50/s（vmstat 1输出）→ 表明进程频繁等待磁盘加载页面，IO 或文件系统异常 -
kswapd0CPU 使用率 >10%（top中查看）→ 内核在后台拼命回收内存，即使没 swap 也在消耗资源 -
/proc/meminfo中PageTables> 总内存 2% → 说明页表膨胀严重，TLB 压力大，上下文切换成本飙升
这些信号藏在底层，不看就永远以为“内存还够”。卡顿的真相，往往不在内存够不够，而在内核忙不忙得过来。
