多个变量同时变化，很容易把“响应变慢”误判成网络故障：例如一边切换客户端网络，一边重启服务或清理日志，即使请求恢复，也无法判断是哪项操作起了作用。针对 Linux服务器磁盘空间不足处理，应先固定同一客户端、同一域名、同一请求和相近时间段，记录 DNS 解析、连接、首字节、总耗时，以及服务器负载和磁盘状态，再逐项验证。

排查按由外到内、由低风险到高风险进行：先检查客户端网络、DNS、路由和丢包，再查看服务器负载、磁盘空间与 inode，最后定位应用及其后端依赖。每轮只验证一个关键变量；修复后使用相同请求和指标复测。这样既能判断网络是否真的变慢，也能确认磁盘不足是否与应用响应变慢有关。

先建立可复现的基线

选择一个稳定、可重复的业务请求。若问题只出现在某个页面或接口，优先测试该页面或接口；如果业务数据会变化，尽量选择不会产生写入的查询请求。记录测试时间、客户端所在网络、目标域名、请求路径，以及请求是否经过 CDN 或负载均衡。每次复测尽量保持这些条件一致。

在 Linux 客户端使用 curl 分解请求耗时，将域名和路径替换为实际地址：

curl -sS -o /dev/null \
  -w 'http=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  'https://example.com/health'

这些指标用于定位耗时阶段，不会修复故障：

• dns 增大，优先核对域名解析过程和解析结果。
• connect 明显增大而 DNS 正常，继续检查客户端到目标地址的网络路径。
• ttfb 增大但连接阶段接近基线，可能是服务器排队、应用处理、磁盘写入、数据库或其他后端依赖变慢。
• total 增大但 ttfb 接近基线，可能是响应内容传输时间变长，应结合响应大小和网络情况判断。
• HTTP 状态码变化可能意味着请求进入了不同的应用处理分支，不能只比较耗时。

如果接口需要认证，不要将密码、令牌或含敏感信息的请求参数写入命令历史或公开的诊断记录。若请求结果会受缓存、登录状态或请求数据影响，应固定这些条件，避免把不同请求的耗时直接比较。

第一步：确认客户端网络是否异常

先检查客户端路由，再对默认网关做有限次数探测。以下命令适用于 Linux 客户端：

ip route
ping -c 10 <默认网关地址>

将 <默认网关地址> 替换为 ip route 输出中 default via 后面的地址。若系统没有 ping，不能据此判断网络正常；可使用系统已有的诊断工具，或在另一台可用客户端上重复测试。

如果默认网关探测持续丢包或时延波动，问题可能位于客户端网络或接入链路，应先核对客户端侧情况，暂时不要归因于服务器。若网关探测稳定，再继续检查目标域名。单次 ping 正常并不能证明业务请求经过的所有路径都正常，最终仍应以实际请求耗时和成功率为准。

为了控制变量，测试时不要同时切换网络、重启服务或修改域名配置。先记录当前结果，再只更换一个测试条件，例如改用另一台客户端；比较时同时记录测试时间和实际请求指标。

第二步：核对 DNS 解析

在客户端执行：

dig example.com

dig 通常由 DNS 工具包提供。未安装时，先使用系统已有的解析工具；如需安装诊断工具，应按当前发行版的软件管理流程操作。不要为了测试直接改写系统 DNS 配置。

核对返回地址是否符合业务预期，并与正常客户端或已确认的解析结果比较：

• 如果解析耗时高、没有返回记录，或不同客户端解析到不同地址，应先核对 DNS 配置、记录状态和缓存影响。
• 如果解析结果一致且耗时接近基线，DNS 不是当前证据所指向的主要环节，可继续检查网络路径。
• 如果域名可能解析到多个地址，应记录每次测试实际使用的解析结果，否则前后请求可能到达不同目标，比较结果会受到影响。

修改 DNS 记录或客户端解析配置会改变访问目标。操作前保存当前配置和原有记录，确认变更范围，并准备恢复原值的方法；若没有明确证据，不要通过修改 DNS 来“试试看”。

第三步：检查路由与丢包

可在 Linux 客户端查看到目标域名的网络路径：

tracepath example.com

若系统没有 tracepath，可核实是否已安装 traceroute，并使用其等效路径诊断功能。路径探测只用于观察，不要为了测试调整防火墙或路由规则。

路径中的某个中间节点不响应探测，不一定表示业务流量被丢弃：部分设备会限制或忽略诊断报文。应关注异常是否持续到目标端，并与实际业务请求的耗时、成功率相互印证。将结果与正常时段或其他客户端的结果比较；如果路径明显变化，记录目标地址、时间和完整输出，交由网络运维进一步核查。

也可对目标域名进行有限次数的探测：

ping -c 20 example.com

域名可能解析到多个地址，测试前后地址也可能变化，因此应同时记录解析结果。若客户端到目标地址的探测持续丢包，可能与网络路径有关；但如果目标端限制探测报文，丢包不一定意味着业务请求丢失。应使用同一个业务请求重复测试，并对照请求成功率和耗时，不能把探测报文的表现直接等同于应用流量。

第四步：查看服务器负载和磁盘状态

如果网络阶段没有发现明显异常，或者 ttfb 明显高于基线，应登录 Linux 服务器查看资源状态。以下命令适用于常见 Linux 发行版；部分工具可能未预装，可先用 command -v 核实。不要把工具缺失当成资源正常。

uptime
free -h
vmstat 1 5

uptime 显示系统负载和运行时间，但负载值需要结合 CPU 核数、进程状态和历史基线解释，不能单独凭一个数值判断过载。free -h 用于观察内存与交换空间；vmstat 中持续偏高的运行队列、明显的交换活动或等待状态变化，可能说明资源争用，应继续查看具体进程和请求是否在同一时段变慢。

查看进程情况可运行：

top

观察 CPU、内存和进程状态。如果应用进程持续占用资源，先记录进程名、PID 和测试时间，再结合应用日志或服务监控确认它是否与慢请求同时发生。不要仅凭进程占用高就直接结束进程，这可能中断服务或造成未完成请求。

判断是否真的发生磁盘空间或 inode 耗尽

检查各挂载点的容量和 inode：

df -hT
df -i

df -hT 查看文件系统类型和容量使用情况；df -i 查看 inode 使用情况。判断时先确认应用数据、日志、临时文件或数据库文件实际位于哪个文件系统：

• 若某个挂载点可用空间接近耗尽，继续确认该文件系统中的目录占用及增长来源。
• 若容量尚有余量但 inode 已耗尽，创建大量小文件的应用仍可能无法创建新文件。
• 若相关挂载点空间和 inode 都正常，磁盘容量不足的假设缺少支持，应继续检查 I/O、应用处理及后端依赖。

可用只读方式查看目录占用。将 /var 替换为问题文件系统中需要检查的目录：

sudo du -xhd1 /var 2>/dev/null | sort -h

该命令适用于支持这些参数的常见 Linux 环境；-x 用于避免跨到其他文件系统。遍历大量文件可能带来额外 I/O，宜避开业务繁忙时段，并从较小目录范围开始。若参数不受支持，先查看本机 du --help，不要照搬不兼容选项。

磁盘空间或 inode 耗尽时，应用可能无法写日志、创建临时文件、写入缓存或保存数据库相关文件，继而出现请求排队、错误增加或响应变慢。但磁盘使用率高本身不能证明它就是慢请求的原因。还需核对故障发生时间、受影响的挂载点，以及应用日志中是否出现写入失败等相关错误。

判断是否伴随磁盘 I/O 压力

若容量和 inode 检查没有解释响应变慢，可在系统已安装 iostat 时观察磁盘 I/O：

command -v iostat
iostat -xz 1 5

iostat 通常由系统性能工具包提供。命令不存在时，不要据此判断 I/O 正常；应按发行版核实工具来源和安装流程。若设备等待时间或利用情况在慢请求期间持续高于自身正常基线，可能存在 I/O 压力，但仍需结合相关进程、文件系统和业务请求确认。工具输出是指定时间段的观察结果，不能单独证明某个进程或磁盘操作就是根因。

第五步：确认磁盘增长来源，再安全处理

确认空间或 inode 不足后，先找出增长来源。不要直接执行通配符删除，也不要盲目清理数据库文件、运行中服务的日志或系统目录。清理可能造成数据丢失、审计记录缺失或服务异常；删除已打开文件后，空间也未必立即释放。

处理日志前，确认对应服务、日志路径、轮转策略和保留要求。需要保留的日志，应先归档到经批准的存储位置并验证归档可读。调整日志轮转或应用日志级别属于配置变更：先备份原配置，确认影响的服务和生效方式，并准备恢复配置的步骤。不要在尚未确认文件用途、保留要求和影响范围时执行删除操作。

如果目录中看不到占用空间的文件，可检查是否有进程仍持有已删除文件：

sudo lsof +L1

该命令用于识别已删除但仍被进程持有的文件，不要根据输出直接重启或结束进程。若确认这类文件占用了空间，应评估服务影响，并在维护窗口按服务自身的安全方式释放文件句柄；操作后验证服务健康状态。数据库文件和应用数据目录的清理必须遵循相应的数据维护流程，不能用通用删除命令代替。

处理后重新执行 df -hT 和 df -i，确认目标挂载点的可用空间或 inode 已恢复。如果数值没有变化，检查是否处理了错误的文件系统、文件是否仍被进程持有，或其他目录是否仍在增长。若空间恢复后很快再次减少，应继续查明新增文件的来源，不要反复清理来替代根因处理。

第六步：根据剩余耗时定位应用与后端

当客户端 DNS、路径探测和服务器资源都没有显示明显异常，而 ttfb 仍偏高时，应转向应用层。先确认慢请求的发生时间、路径、状态码和请求标识，再查看应用日志、服务日志及可用的请求耗时指标。

日志中出现写入失败、临时目录不可用、数据库超时或后端依赖等待，可为进一步排查提供方向。单条报错不一定就是根因，应核对它是否与慢请求同时出现、是否重复发生，以及影响的请求范围是否一致。

若服务由 systemd 管理，可先核实实际服务名，再查询状态和日志：

systemctl status <实际服务名>
journalctl -u <实际服务名> --since "30 minutes ago"

将占位符替换为已确认的服务名。日志保留时间和查询结果受系统配置影响；若服务并非由 systemd 管理，这些命令不一定能覆盖其日志。查询结果可能包含用户信息、请求参数或令牌，对外分享前应按安全要求脱敏。

如果应用自身处理耗时增加，应检查对应代码路径、进程状态和日志；如果请求在等待数据库或其他后端，应核对相应依赖的响应时间和错误记录；如果应用耗时正常但用户侧总耗时偏高，则重新对照连接、传输时间和响应大小。仅凭“重启后短暂恢复”不能认定根因已经解决，重启可能只是暂时释放资源或清除积压。

修复后按原条件复测

每次只完成一个修复动作，再使用相同客户端、域名、请求和工具采样，与基线逐项比较：

1. 再运行 curl，比较 DNS、连接、首字节和总耗时。
2. 若改动针对 DNS 或网络，核对解析结果、路径探测和实际请求成功率。
3. 若改动针对磁盘，重新执行 df -hT、df -i，并观察相关文件是否继续增长。
4. 若改动针对应用，对照应用日志、状态码和请求耗时，确认同类错误是否仍然出现。

如果磁盘空间恢复后，相关写入错误消失且 ttfb 同步回落，可以认为磁盘问题与响应变慢存在较强关联；如果空间恢复但响应仍慢，应回到耗时分段和应用指标继续定位。这个判断只适用于实际测试的请求、客户端、时间段和服务器状态。网络路径、负载和业务流量会变化，单次短时间复测不能证明问题已彻底消除；应在业务负载相近时重复观察，并确认没有新的空间增长、丢包或应用错误。