Linux基础
VPS 内存、负载和磁盘怎么查看：free、top 与 df
查看 Linux VPS 的可用内存、系统负载、vmstat 采样与磁盘容量，区分系统统计和容器配额，定位应用资源不足。
VPS 变慢时，从故障环境开始查看
VPS 变慢、应用提示内存不足或文件写入失败时，先在故障发生的环境里查看资源。记录问题时间，并确认终端位于虚拟机、容器还是宿主系统。本文以 Linux v6.12、procps-ng v4.0.5 和 GNU coreutils v9.5 的资料解释字段，下面的命令读取实际内核与工具版本。
原生 Linux 的 meminfo 和 loadavg 来自当前内核的系统级统计，不会自动变成某个业务 cgroup 的资源预算。KVM 虚拟机内看到的是来宾内核，不能一概称为物理宿主机数据；若容器环境提供了改写的 /proc 视图，还要按该环境的定义解释结果。
cat /proc/self/cgroup 读取的是执行这次查询的进程所属 cgroup，不代表业务进程。它用于记录观察位置；后面仍需把实际业务 PID、所在命名空间与 cgroup 对应起来，不能只凭当前终端所在位置判断应用限额。
命令找不到时查发行版软件包，权限不足时检查当前账号和容器权限，读取失败则查看报错。前后比较应使用同一环境与时间范围，不需要为查看统计提升容器权限。
uname -r
free --version
df --version
cat /proc/self/cgroup用 available 理解内存余量，分开看交换空间
free 从 /proc/meminfo 获取信息。free 列主要表示尚未使用的内存；available 则估计在不发生交换的前提下，还能供新应用使用的内存。Linux 的 MemAvailable 会考虑可回收缓存、slab 和内存水位，并不把所有缓存都视为随时可以释放。
procps-ng v4.0.5 的 used 按 total 减 available 计算，不应套用其他版本的旧公式。读取时同时看 total、available、buff/cache 与单位，避免把 free 较小或缓存较多直接解释成内存不足；available 也是估计值，不是某个新进程一定能成功分配的保证。
Swap 行描述交换空间的总量与当前占用，不等于此刻正在频繁换入换出。把交换占用与后面的 vmstat 间隔数据、应用错误和发生时间联合观察；容器业务还要另看实际 cgroup 的使用量和限制。
free -h把系统负载与 CPU 使用率分开理解
uptime 显示运行时长及 1、5、15 分钟负载。Linux 负载是可运行任务与不可中断等待任务数量的衰减平均，不是 CPU 使用百分比；不可中断等待可能与 I/O 有关，因此负载升高不能直接归因于 CPU 算力不足。
负载数值没有按 CPU 数量归一化，也不能用负载除以核心数就断言 CPU 忙碌百分比。应把同一时间窗口的负载趋势，与 vmstat 的任务状态及 CPU 时间字段对照，再回到实际业务现象。
在容器中，内核系统级负载与业务可用的 CPU 配额可能处在不同范围。不要用主机或来宾系统的负载，直接给某个容器判定健康阈值，更不能据此推导主机商性能排名。
uptime区分 vmstat 首次报告与后续间隔采样
vmstat 1 5 以一秒间隔输出五次报告并结束。第一次报告中的速率与 CPU 时间统计反映自启动以来的平均情况，后续报告反映相应采样间隔；进程和内存字段在首次及后续报告中都属于即时状态，不能把整条首行都说成开机平均。
r 表示可运行任务，b 表示等待 I/O 完成而阻塞的任务；swpd 是已使用的交换空间，而 si、so 表示每秒换入、换出量。把占用量与变化速率分开，避免因交换空间已有使用量就认定当前正在发生交换压力。
CPU 区域中的 us、sy、id、wa、st 等字段表示不同类别的 CPU 时间。wa 的核算有局限，st 表示虚拟机被取走的运行时间；单独一个值不能证明磁盘损坏、应用故障或主机商超售。短时采样只覆盖这段观察窗口，需要与业务错误及重复出现的现象对应。
vmstat 1 5查看数据所在文件系统的空间与 inode
先确认根路径 / 属于已挂载的本地文件系统，再使用下面的根文件系统示例。df 接收路径时报告的是包含该路径的文件系统，不是该目录自身占用的空间；根文件系统有余量，也不代表另一个数据盘、日志挂载或容器卷有余量。
df -hT 显示便于阅读的容量单位和文件系统类型，df -i 改为显示 inode 使用情况。块空间与 inode 是两个维度，应分别记录可用量和挂载点；不能因其中一项有余量就保证业务写入成功，还要核对实际应用错误与访问权限。
查看应用数据或日志时，将两条命令中的 / 替换为实际路径，并确认挂载关系。路径查询可能产生 I/O，自动挂载目录还可能触发挂载；-l 仅限制 df 列出本地文件系统，不保证查询过程完全不访问网络。
本页先定位文件系统和故障路径，不使用递归扫描、--sync 或删除文件来验证问题。需要定位大目录时，再按实际数据范围继续排查。
df -hT /
df -i /把业务进程对应到真实 cgroup 与祖先限制
先通过实际服务或容器管理信息确定业务 PID，再核对该进程的 cgroup 和当前可见的 cgroup 挂载。首节 /proc/self/cgroup 只描述查询进程；在 cgroup v2 中，0::/ 这样的路径相对于 cgroup 命名空间根，并不能证明进程位于宿主机的层级根或没有资源限制。
不要把 /proc 中读到的路径盲目拼接到宿主机 /sys/fs/cgroup。确认真实业务 cgroup 后，再在获准范围内查看对应的 memory.current、memory.max、cpu.max 和 cpu.stat；文件不可见或不存在时，应先区分控制器是否启用、是否位于根 cgroup，以及是否使用 v1 或混合层级。
在 cgroup v2 中，memory.current 统计该 cgroup 及其后代的内存使用量；memory.max 是该层的内存硬限制。cpu.max 描述该层 CPU 带宽配额与周期，而 cpu.stat 提供使用和限流相关统计。memory.max 或 cpu.max 出现 max 只说明本级没有对应上限，不会解除祖先 cgroup 的约束。
把同一业务 cgroup 的使用量、限制和统计变化放在一起观察，再与应用故障时间对应。不要把系统 MemAvailable 当作容器还可分配的内存，也不要因单个层级未设置配额就认定业务不受限制；本文只解释 v2 字段，不把它们套到 v1 文件布局。
从资源统计继续定位应用问题
把内存余量、交换变化、负载、vmstat 采样和目标文件系统的空间、inode 与故障时间对照。采样没有覆盖故障时段时，继续记录问题复现过程。
内存相关现象先分清系统余量与 cgroup 限制；负载相关现象继续区分可运行任务、等待和 CPU 时间；写入失败先对准真实业务路径及挂载点。结合应用错误继续缩小范围，而不是根据一个数值立即重启服务或购买更高配置。
清缓存、关闭交换空间、删除文件、重新挂载和压力测试都不是本教程的查询步骤。Linux 文档说明，丢弃缓存后重新建立缓存可能增加 I/O 与 CPU 开销；不要用清缓存来制造更好看的 free 输出，也不要以删除业务文件验证磁盘是否恢复。
后续要修改配置或存储时，保存原设置与必要记录，并确认 SSH 或控制台仍可访问。相关阅读中的 SSH 教程可用于检查管理入口。