我每天真的会敲的那几条 Linux 命令

速读#

这篇不是 Linux 命令大全，只收我管服务器时真的高频会敲的几组。登上机器先问三件事：喘不喘、谁占了、日志说什么；htop、ss、journalctl 这些命令只是服务这三个问题。

登服务器先问三句#

命令会忘，问题不会。先有问题再有命令，顺序反过来就成了背大全。

喘不喘#

htop          # 交互式看 CPU/内存/进程（需 apt install htop）
uptime        # 负载三个数：1 / 5 / 15 分钟平均
df -hT        # 文件系统容量、类型与挂载点
free -h       # 内存
du -xhd1 . | sort -h   # 当前文件系统内逐层找大目录

htop 用得最多：比自带 top 直观，F6 排序、F9 发送信号。它不是所有系统都预装，所以 apt install htop 往往是我接手 Debian 或 Ubuntu 机器后的第一批命令之一；临时机器没必要安装时，用自带的 top 也足够判断大方向。

负载数字要对着逻辑 CPU 数量读，但它不是 CPU 使用率。Linux load average 统计的是正在运行、等待 CPU，以及处于不可中断睡眠（常见于 I/O 等待）的任务：1 核机器长期 load 1.0 表示平均约有一个任务处于这些状态，可能是 CPU 忙，也可能是磁盘或网络存储拖住了进程。三个数从左到右是 1、5、15 分钟平均——左低右高通常说明压力正在回落，左高右低则说明压力正在上升；接着还要用 htop、vmstat 1 或 iostat -xz 1 区分 CPU、内存和 I/O，不能只凭一个数字下结论。

df -hT 告诉我哪个文件系统满了，du -xhd1 再在同一文件系统内逐层找大目录；用 .[!.]* 补隐藏项很容易写错，直接从 . 统计更稳。Docker 数据、没轮转的日志、忘删的备份都很常见。如果 df 显示已满而 du 加总明显偏小，我会继续查 lsof +L1：文件可能已经被删除，但仍被进程打开，空间要等文件描述符关闭后才真正释放。

日志本身也是磁盘大户。journal 占多少、怎么收，它自己就能管：

journalctl --disk-usage           # 日志占了多少
journalctl --vacuum-size=200M     # 收缩到上限内

--vacuum-size 只清理归档日志，当前正在写入的 journal 仍可能让总量略高于目标；长期上限应写进 journald.conf 的 SystemMaxUse=，然后再观察实际增长。

谁占了#

ss -tulnp              # 所有监听端口及进程
ss -ltnp 'sport = :80' # 精确看 TCP 80 端口
kill <PID>             # 先优雅退出（SIGTERM）
kill -9 <PID>          # 强制（SIGKILL，最后手段）

ss 是 netstat 的现代替代。参数可以拆开记：t TCP、u UDP、l 只看监听、n 显示数字端口不反解、p 带进程。查看别的用户或系统服务时通常需要 sudo 才能看到完整进程信息。不要用 grep 80 判断 80 端口，它也会匹配 8080、进程号和地址；sport = :80 才是在按套接字字段过滤。

kill 的顺序是纪律：先发默认的 SIGTERM，给进程一个体面收尾的机会（写完缓冲、释放锁、断开连接），确认它不理会再上 -9——SIGKILL 由内核直接回收，进程连遗言都没有。上来就 -9，等于剥夺进程善后的机会。

日志说什么#

journalctl -u myapp -f              # 实时跟 systemd 服务日志
journalctl -u myapp --since today   # 只看今天
tail -f /var/log/nginx/error.log    # 文件日志

-f 是 follow。部署后我会先看启动日志，再从另一终端发一次真实请求并检查状态码；只有日志正常、端口在监听、请求也成功，才能说明服务真的可用。单纯看到日志滚动，只能证明进程还在输出。

为什么优先 journalctl#

自己部署的东西多用 systemd 守护，日志归 journalctl 统一收；Nginx 这类自己写文件的才用 tail -f。

统一收日志，是 systemd 给可观测面的红利——不用每个服务自己管重定向、切割和落盘位置，-u 服务名 一个入口全找到。

高频小抄#

留下的不是命令清单，是三问框架：喘不喘、谁占了、日志说什么——登任何服务器先问这三句。