Linux基础 · 已发布教程
Linux VPS 资源只读排查：内存、负载、磁盘与观察范围
从观察范围出发，核对 Linux 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 输出当作完整磁盘诊断。
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 文件布局。
把资源现象对应到业务，并保留恢复入口
先核对观察环境与业务时间，再把内存余量、交换变化、负载、间隔采样以及目标文件系统的块空间和 inode 放在同一份记录中。不同范围的数值不能直接拼接，单次输出也不足以确定根因；没有覆盖故障窗口时，应明确记录观察窗口的限制。
内存相关现象先分清系统余量与 cgroup 限制；负载相关现象继续区分可运行任务、等待和 CPU 时间；写入失败先对准真实业务路径及挂载点。结合应用错误继续缩小范围，而不是根据一个数值立即重启服务或购买更高配置。
清缓存、关闭交换空间、删除文件、重新挂载和压力测试都不是本教程的查询步骤。Linux 文档说明，丢弃缓存后重新建立缓存可能增加 I/O 与 CPU 开销；不要用清缓存来制造更好看的 free 输出，也不要以删除业务文件验证磁盘是否恢复。
确需变更时，先保存必要的脱敏记录、确认维护窗口和可用的管理恢复入口，再按相应配置或存储流程操作。相关阅读中的 SSH 只读核对教程用于确认管理服务及恢复前提，便于后续维护前检查管理访问是否具备恢复条件。