linux下看内存真实占用应以memavailable为准，而非free的available列；应用真实占用=used−buffers−cache；需结合slabtop、/proc/meminfo和vmstat定位缓存、slab或泄漏问题。
Linux下怎么看内存真实占用，别被free的“可用”骗了
Linux的free命令默认显示的available值看似是“能用的内存”，但它包含大量可回收的缓存（PageCache、Slab等），不代表进程实际能立刻申请到的内存。真正影响服务响应的是MemAvailable（内核3.14+）或available列，但更关键的是看used - buffers - cache这个“应用真实占用”——也就是free -h里Mem:行的used减去buff/cache后的值。
常见误判现象：free -h显示“available: 2G”，但java进程频繁OOM；或者top里%MEM加起来不到50%，系统却开始杀进程。
-
free -h优先看available列（非free列），它已预估可回收缓存 - 确认真实压力：运行
cat /proc/meminfo | grep -E "MemAvailable|MemFree|Buffers|Cached|SReclaimable"，用MemAvailable为准 -
top或htop中按M排序，关注RES（常驻内存）而非VIRT，VIRT含映射但未分配的部分 - 若
MemAvailable持续低于512MB（小内存机器）或总内存10%，说明内存紧张，需查源头或释放
手动释放PageCache、dentries和inodes缓存的正确姿势
释放缓存不是“清空一切”，而是触发内核回收那些可重建的页面。不推荐无差别清缓存，除非确认是缓存堆积导致MemAvailable过低且无其他内存泄漏。
执行前务必确认：没有正在做大量文件读写的业务（如数据库备份、日志归档），否则会显著拖慢IO。
- 只清PageCache：
echo 1 > /proc/sys/vm/drop_caches - 清PageCache + dentries/inodes：
echo 2 > /proc/sys/vm/drop_caches - 清全部（含slab，慎用）：
echo 3 > /proc/sys/vm/drop_caches - 该操作需
root权限，且仅对当前节点生效，不会影响其他用户或容器 - 释放后
MemAvailable会立刻上升，但cached值下降不代表性能提升——后续读文件可能变慢，因为缓存没了
Swap空间占满怎么办：先查谁在用，再决定是否关闭
Swap被大量使用不等于必须禁用，关键是看是否因内存不足被动换出（si/so持续非零）还是仅为预留（swapon -s显示已分配但/proc/swaps中Priority高且Used为0）。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
检查方法：swapon -s看各swap设备使用量；cat /proc/swaps确认优先级；vmstat 1观察si（swap in）、so（swap out）是否持续>0。
- 若
so持续>0：说明物理内存严重不足，进程页被频繁换出，应优先扩容内存或优化应用内存使用 - 临时禁用某swap分区：
swapoff /dev/sdb1（替换为你的swap设备路径），注意该操作会把对应swap里的页换回内存，若内存不足会触发OOM - 永久禁用：注释或删除
/etc/fstab中对应swap行，再swapoff -a - 调整swappiness（默认60）可降低倾向：
sysctl vm.swappiness=10，写入/etc/sysctl.conf持久化
释放Swap后内存仍不涨？重点查Slab和内核内存泄漏
释放缓存和swap后MemAvailable没明显回升，大概率是Slab（尤其是kmalloc-*、dentry、inode_cache）或内核模块占用了大量不可回收内存。这类内存不计入free的cached，但压在MemAvailable计算里。
典型表现：free中buff/cache不高，但MemAvailable极低；slabtop显示某cache项KB数异常高（如>500MB）。
- 查看Slab详情：
slabtop -o（按c按大小排序），重点关注#OBJS和OBJSIZE乘积大的项 - 清理dentry/inode缓存（比
drop_caches=2更精准）：echo 2 > /proc/sys/vm/drop_caches - 某些驱动或内核bug会导致
ext4_inode_cache或UDPv6相关slab无法释放，需升级内核或排查对应服务（如长期运行的网络代理、NFS客户端） - 用
cat /proc/meminfo | grep -i slab快速确认Slab和SReclaimable差值，差值大说明有大量不可回收slab
最常被忽略的一点：drop_caches和swapoff都是临时手段，不能替代内存泄漏定位。如果每天都要手动释放，应该用pmap -x <pid></pid>、cat /proc/<pid>/smaps_rollup</pid>查具体进程的Rss和Anonymous增长，或用bpftrace跟踪kmalloc调用栈。
