01先描述现象

把“服务器很慢”拆成具体问题：是 SSH 输入延迟、网页首字节慢，还是某一个接口偶尔超时？记下发生时间、影响范围和最近的变更。不同现象对应的排查入口并不相同。

先用 uptime 看负载趋势，用 free -h 看内存，再用 df -h 看磁盘空间。负载代表正在运行或等待运行的任务情况，不能直接当作 CPU 使用率；还需要结合核心数和后续观察判断。

02内存要看可用量

Linux 会把空闲内存用于缓存，因此 free 一栏很小不一定意味着内存不足。优先关注 available，再检查应用是否持续增长。如果系统没有交换空间，突发内存需求更容易触发进程被终止。

用 journalctl -k 检查内核日志里的 OOM 记录。发现内存不足后，先定位具体进程和触发场景，而不是直接清空缓存。缓存通常会在应用需要内存时回收。

03把服务、端口和日志对起来

systemctl status 服务名 可以确认进程状态，ss -lntp 可以确认 TCP 监听。服务显示 running，并不等于它在预期地址上提供服务：只监听 127.0.0.1 的端口无法直接从外部访问。

按时间窗口读取 journalctl -u 服务名 --since "30 minutes ago"，将错误与请求时间对齐。截取日志时删去令牌、会话信息和个人数据，只保留复现问题需要的上下文。

04一次只验证一个假设

如果怀疑磁盘写满，先找出增长目录及其用途；如果怀疑连接堆积，先观察连接数量变化。每次调整都记录调整前后的指标，避免同时改动多个参数后无法判断是哪一步起效。

最终留下四项记录：现象、证据、处理和验证。一次可靠的排查，不只恢复服务，还应让下一次同类问题更容易定位。