先解释一个细节标题里的“unbuntu”其实是 Ubuntu 的常见手滑拼法。命令行里敲错一个字母命令直接找不到所以我先帮你把这个坑填了。在 Ubuntu 的日常使用和服务器排障里我遇到最多的根本不是高深的应用故障而是硬盘、内存这一层的“基础病”分区满了、内存被吃光、新盘不识别、文件删了空间不释放。这些问题的排查思路其实非常固定Ubuntu 自带的一批命令就能覆盖九成场景。这篇文章我就把硬盘和内存相关的命令整理成一条完整的排查链路先认盘、再看容量、然后定位进程、最后实战处理磁盘 100% 和内存 OOM。每条命令为什么用、输出怎么读、有哪些容易踩的坑我都会写清楚。无论你是刚接触 Ubuntu 的新手还是已经维护过几台服务器的同学这篇文章都能直接拿来当排障手册用。1. 硬盘排查先搞清楚机器上到底有什么盘1.1 第一步永远是 lsblk别急着上 fdisk硬盘问题最难的地方是“不知道系统到底认了哪些盘”。我见过不少同学上来就敲fdisk -l结果要么提示权限不够要么被一堆回环设备和 IDE 设备刷屏反而看不清真实盘符。更稳的第一步是lsblk它默认只读、不需要 sudo输出还是一棵清晰的树状结构。$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 238.5G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 237.1G 0 part / sda3 8:3 0 2G 0 part [SWAP] sdb 8:16 0 931.5G 0 disk └─sdb1 8:17 0 931.5G 0 part /data看到这个结构盘的情况一下就有数了sda 是系统盘包含 EFI 引导分区、根分区、交换分区sdb 是第二块数据盘挂载在 /data。TYPE 列标注 disk 还是 partMOUNTPOINT 列则直接告诉你哪个分区在用、哪个分区还没挂。如果一个分区没有挂载点要么没挂载要么没格式化这就是这台机器还没有被用起来的空间。后面做扩容排查这些信息就是第一手依据。想看得更细用lsblk -f。这条命令会把文件系统类型FSTYPE、UUID、卷标都打印出来。文件系统类型很关键EFI 分区一般是 vfat根分区大多数是 ext4云主机可能是 xfs。之后要写自动挂载配置UUID 才是唯一识别设备的方式别直接写 /dev/sda 这种盘符重启后盘符有变化的可能用 UUID 才稳定。提示lsblk 只负责“看”不会改任何东西。即使整块盘是裸盘、一个分区都没有它也能显示一条 disk 记录。第一轮排查它就是最安全的命令没有之一。1.2 df 和 du容量、用量、目录占比分开看lsblk 帮你认了盘再往下就要回答两个问题空间还剩多少、空间被谁占了。这里需要 df 和 du 配合缺一个都不行。df -hT从文件系统层面统计挂载点的容量-T 可以顺便列出文件系统类型。du -sh *统计当前目录下每个子目录的总大小判断“大户”是谁。du -h --max-depth1 /var只看 /var 下一层目录的大小避免一层一层 cd 进去太慢。典型输出$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/sda2 ext4 237G 187G 38G 84% / /dev/sdb1 ext4 916G 87G 783G 10% /data tmpfs tmpfs 7.8G 2.1M 7.8G 1% /run读 df 时重点看 Use% 和 Avail。根分区 84%说明还有约 38G暂时没到告警线一旦超过 90%就得立刻跑 du 找大目录。tmpfs 是内存临时文件系统不占磁盘空间看到它“占用”再高也不用慌这只是内存的一部分。df 和 du 经常“对不上”这是新手最容易懵的地方。一句话解释df 看的是文件系统层面只要一个文件被进程打开着就算你在目录里删掉了它文件系统的空间依然被统计为“已占用”而 du 是从目录树一个个文件遍历出来的结果已经删除但被进程占用的文件du 根本看不见。所以当你遇到 df 显示满了、du 却半天找不到大文件大概率就是“文件已删、句柄未释放”排查方法放在后面实战章节核心命令是lsof | grep deleted。找大目录我自己的习惯写法是sudo du -h --max-depth1 / 2/dev/null | sort -rh | head -102/dev/null是过滤权限不足的目录噪音sort -rh按人类可读大小倒序排head -10只看前十个最大项。这样一分钟就能锁定占用空间最明显的目录比手动一层层 cd 进去敲 df 快得多。1.3 blkid、fdisk、mkfs新盘怎么认、怎么分区、怎么挂如果你的场景是“加了一块新盘系统没自动挂载”或者“要重新调整分区”上面两条命令只能“看”不能“改”。动手改盘之前有三条命令必须掌握blkid、fdisk、mkfs。blkid打印块设备的 UUID 和文件系统类型$ sudo blkid /dev/sda1: UUIDABCD-1234 TYPEvfat PARTUUID... /dev/sda2: UUIDabcdef01-.... TYPEext4 PARTUUID... /dev/sdb1: UUID12345678-.... TYPEext4 PARTUUID...如果某个设备 TYPE 为空说明它还没有文件系统不能直接挂载。新盘要从裸盘变成可用目录走三步sudo fdisk /dev/sdb进入交互式分区工具按 n 新建分区w 写盘退出。sudo mkfs.ext4 /dev/sdb1把新分区格式化成 ext4。sudo mkdir -p /data sudo mount /dev/sdb1 /data挂载到目标目录。fdisk 交互界面没鼠标但快捷键并不难记p 打印分区表d 删除分区n 新建分区w 保存退出q 不保存退出。这里必须重点强调一个坑在跑着业务的生产机器上操作分区一定要先 p 看清当前分区表再决定 d 删哪个分区写完之前先按下 q 还可以反悔按了 w 就真的写盘了。我自己就踩过一次本想删 sdb 上的旧分区结果误删了系统盘的分区好在没按 w保住了盘但那十几秒冷汗是真让人长记性。自动挂载要写进/etc/fstab一行类似UUID12345678-.... /data ext4 defaults 0 2写完先执行sudo mount -a验证语法再考虑重启。fstab 写错会直接导致系统进不去尤其是挂载路径和文件系统类型写错的时候这是 Ubuntu 运维里最容易翻车的一步。注意fdisk 和 mkfs 都是会改写磁盘的命令。执行前一定用 lsblk 和 blkid 核对容量、型号、UUID 三项全部对上才动手。格式化操作不可逆数据没了就是没了。2. 内存到底该看哪些指标2.1 free 命令逐行拆解别把 available 和 free 搞混内存问题比硬盘更容易误判根因是大家习惯只盯着 free 那一列看。先把典型输出摆出来$ free -h total used free shared buff/cache available Mem: 15Gi 11Gi 456Mi 110Mi 4.0Gi 3.4Gi Swap: 2.0Gi 1.8Gi 210Mi五列逐个说total 是物理内存总量used 是已经分配给进程的内存不含缓存free 是完全没有被使用的内存buff/cache 是内核把磁盘读写的数据临时放进了内存available 是内核估算出的“还能分配给新进程的内存”。最容易误判的就是看到 free 只剩 456M立刻断定内存不够。Linux 的内存策略恰恰相反——它会尽量用空闲内存去做文件缓存当新进程需要内存时再释放缓存所以 available 才是真正要盯的“剩余空间”。这里 available 是 3.4Gi够不够要看业务量。如果 available 长期低于总内存的 10%或者反复逼近 0那内存是真的吃紧。buff/cache 高不代表内存泄漏这是 Linux 的正常行为越是频繁读写磁盘的机器buff/cache 往往越高。真正要担心的是 Swap 持续占用高它说明物理内存出现过严重不足内核把一部分内存换到了磁盘上。想持续观察 free 的变化可以用free -h -s 5每 5 秒刷新一次适合一边观察一边排查的场景。不过 free 是瞬时值单次低 available 可能是瞬时尖峰最好配合 top 或 vmstat 看一段时间趋势。2.2 top/htop/vmstat实时看谁在吃内存可用内存告急下一步必须定位到具体进程。最主流的工具是top进入交互界面后按 M 让进程按内存排序按 P 按 CPU 排序按 q 退出。顶部几行信息同样关键top - 10:31:52 up 120 days, 3:12, 2 users, load average: 1.12, 0.77, 0.65 Tasks: 180 total, ... %Cpu(s): 12.5 us, 3.1 sy, 0.0 ni, 84.4 id, 0.0 wa, ... MiB Mem : 15890.0 total, 456.5 free, 11236.1 used, 4197.3 buff/cache MiB Swap: 2048.0 total, 1868.5 used, 179.5 freeload average 三个数字分别代表 1 分钟、5 分钟、15 分钟平均负载内存持续不足时这个数也会走高。CPU 一行重点看 wa这是 I/O 等待占比如果 wa 持续很高往往意味着磁盘太慢、内存缓存不足跟内存问题是联动关系。进程列表里主要看 %MEM 和 RES 两列RES 是常驻物理内存比 VIRT虚拟内存更真实。看到一个进程 VIRT 几个 G 不用担心很多程序只是申请了虚拟地址空间并没有真正占用物理内存RES 才是它实际吃掉的量。htop 是更友好的 top没有的话先sudo apt install htop。它支持鼠标操作按 F6 选排序字段可以直接在界面里找到内存占用最高的进程。我更喜欢 htop 一点顶部能直接看到 CPU 和内存的彩色进度条一眼就知健康程度。不过生产环境要谨慎在 htop 里直接按 F9 kill 进程先确认 PID 和进程名再动手。vmstat 则适合连续观察系统整体动态每秒输出一行$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 1 1864320 46520 108700 4109000 1023 583 2041 9260 123 458 20 8 70 2 0主要看四组r 是等待运行的进程数持续大于 CPU 核数说明 CPU 过载si/so 是 swap 换入换出量持续非零说明物理内存不够bi/bo 是块设备读写情况配合 wa 判断 I/O 瓶颈us/sy/id 是用户态、内核态、空闲 CPU 占比。si 和 so 是我判断内存瓶颈的“金标准”只要有持续的换页内存基本就是真不够了调 swappiness 只能缓解关键还得扩内存或优化进程。2.3 ps 和 /proc/meminfo找到具体的吃内存大户实时刷新工具适合处理正在发生的故障如果要排查历史问题或者给整台机器做一次“体检”快照类命令更合适。ps aux --sort-%mem直接把所有进程按内存占用从高到低排好一条命令不带交互界面特别适合写进脚本或者接管道看前几行$ ps aux --sort-%mem | head -8 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND mysql 1023 5.6 14.3 2124600 2254572 ? Ssl Mar01 12:12 /usr/sbin/mysqld ...RSS 列是常驻物理内存单位 KB想换算成 GB 就除以 1048576。看到某个进程 RSS 异常高就得结合业务判断是缓存没释放还是真有内存泄漏。一个基本思路是拿进程 RSS 和它的业务数据量对比如果 RSS 持续上涨、重启后短期又涨回高位基本可以判定是泄漏方向。/proc/meminfo是内核暴露内存统计的原始文件free、top 底层都读它。直接cat /proc/meminfo能看到 MemTotal、MemFree、MemAvailable、Buffers、Cached、SwapTotal、SwapFree 等上百个字段。日常运维用不着全读但有两个场景很值得看一是某个监控指标异常时到这里查原始数据二是写监控脚本时直接读取这个文件比解析 free 输出更可靠很多采集程序的实现就是抓这个文件再套公式。提示排查内存泄漏有个土办法——连续两次记录同一个进程的 RSS中间隔一个小时例如ps -o pid,rss,vsz,cmd -p PID。如果 RSS 不断往上走业务请求量却没变那就要高度怀疑代码里有资源没释放了。3. 实战场景告警来了按这个顺序操作3.1 磁盘 100%从 df 到释放空间的完整链路假设监控告警已经在刷屏根分区使用率 100%。这时候别乱删文件按下面顺序一步步来。第一步确认现状。df -hT /查看根分区容量df -i /看一眼 inode 使用率。很多人会忽略 inode磁盘明明有空间但 inode 耗尽同样写不进文件报错也是 No space left on device。如果 inode 满了去找大量小文件堆积的目录删掉即可。第二步定位大目录。执行cd / sudo du -h --max-depth1 / 2/dev/null | sort -rh | head从输出中挑占用最高的目录继续深入。如果是 /var就重复sudo du -h --max-depth1 /var 2/dev/null | sort -rh | head逐层定位几分钟就能从根目录缩小到具体文件。第三步根据占用类型做清理。如果大户是日志sudo ls -lahS /var/log看最大日志文件日志交给 systemd 管理的话用sudo journalctl --vacuum-size200M对历史日志做压缩回收。如果大户在 /var/lib/docker先用docker system df看各类型占用再用docker system prune -a清理悬空镜像和停止的容器——这个命令会删掉所有没在用的镜像真要清之前先确认没有需要保留的旧版本。第四步顺手清 apt 缓存。Ubuntu 长期用下来/var/cache/apt/archives会积累不少 .deb 安装包sudo apt clean一键清理。大文件若是临时文件清理 /tmp 也能释放空间但注意 /tmp 可能是 tmpfs清它不释放磁盘。第五步处理最诡异的情况df 显示快满du 却找不到任何大文件。这几乎一定是“文件被删除但进程仍占用”。执行sudo lsof L1 | grep -i deleted找出被删除但仍被打开的文件拿到 PID 后用sudo lsof -p PID确认是哪个进程。确认业务影响后重启该服务或结束进程空间立刻就能释放。这个坑常见于日志被 logrotate 切割后服务进程还握着旧日志文件句柄继续写。提示删除大文件后 df 不会立刻刷新释放过程是异步的。可以先等一下再重新执行 df不用反复跑命令怀疑自己删错了。3.2 内存告警OOM、Swap 和内核日志怎么配合内存告警比磁盘告警更紧急因为一旦触发 OOM内核会直接挑一个进程杀掉运气不好就是数据库主进程。收到告警后我的排查顺序一般是三步。快速确认现状free -hvmstat 1 3看 available 是否见底、si/so 是否持续非零。定位吃内存的进程ps aux --sort-%mem | head -15结合业务判断哪个异常。有容器环境的话docker stats可以看容器级内存占用。查内核日志有没有 OOM 记录sudo dmesg -T | grep -i -E oom|killed process sudo journalctl -k --since 1 hour ago | grep -i oomOOM 日志会明确写出 “Out of memory: Killed process 1234 (mysqld)”这一条就能告诉你内核到底把谁杀了。正常系统不该频繁 OOM一旦出现要么物理内存确实不够要么某个进程内存泄漏。如果只是短期内存吃紧可以调整 swappiness 缓解压力sudo sysctl vm.swappiness10 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf默认 swappiness 一般是 60代表内核在匿名内存和文件缓存之间做平衡的积极程度。调低到 10意思是尽量少用 swap把内存优先留给进程调高则相反更积极地换出。生产场景我一般设 10桌面环境保持默认即可。但这只是缓兵之计不能替代扩容。如果是某个业务进程持续吃光内存内核参数救不了它。要检查启动参数有没有限制例如 Java 进程的 -Xmx、容器编排里的内存 limit、systemd service 里的 MemoryMax以及代码里是否存在对象长期持有不释放。先把进程限制住别让一个进程拖垮整机。3.3 Swap 的“正确姿势”什么时候要、怎么加、怎么删很多 Ubuntu 新手对 swap 又怕又爱。我先给结论内存小于 2G 的小机器建议必配 swap内存 8G 以上的服务器swap 配 2~4G 作为“保险丝”就够了。不存在“swap 越大越好”的说法swap 本质是拿磁盘充当内存速度比物理内存慢几个数量级依赖 swap 只会让系统越来越卡。查看当前 swap 状态swapon --show或者直接看free -h的 Swap 一行。如果机器没配 swap可以用 swapfile 临时加一个不用重新分硬盘sudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile要重启后依然生效在 /etc/fstab 追加一行/swapfile none swap sw 0 0这里有个细节fallocate 预分配文件很快但在某些文件系统上有兼容问题更保险的写法是用 ddsudo dd if/dev/zero of/swapfile bs1M count4096慢一些但兼容性最好。什么时候会用到这种保险写法当你发现 fallocate 出来的 swapfile 在 swapon 时莫名报错换成 dd 大概率就好了。删除 swap 则反过来sudo swapoff /swapfile sudo rm /swapfileswapoff 执行时如果物理内存不足会把 swap 里的数据全部倒腾回内存这个过程可能非常慢甚至看起来像卡死。所以关闭 swap 一定要选在内存充足、负载低谷时做。swapon --show还能看到优先级 PRI多 swap 设备时可以设置优先级控制谁先被用。日常单机场景不需要搞复杂一块主 swap 足够。4. 高频命令速查与避坑清单4.1 硬盘、内存命令速查表把前文拆过的命令整理成一张表存下来当速查手册。用途命令说明查看盘符结构lsblk/lsblk -f只读树状显示分区、挂载点、文件系统查看容量df -hT文件系统层空间使用看 Use% 和 Avail查看目录大小du -sh *当前目录下各子目录大小按层级找大目录du -h --max-depth1 /配合 sort -rh 与 head 使用查看 UUID 与文件系统sudo blkid写 fstab 前必须核对交互分区工具sudo fdisk /dev/sdXn 新建分区w 保存q 不保存退出格式化分区sudo mkfs.ext4 /dev/sdX1会清空数据慎用挂载 / 自动挂载sudo mount /dev/sdX1 /mnt持久化写 /etc/fstab查看内存概况free -h重点看 available不是 free实时进程监控top按 M按内存排序可选 htop整体实时统计vmstat 1 5关注 r、si/so、wa按内存排序进程ps aux --sort-%mem配合 head 使用查看内核内存原始数据cat /proc/meminfo监控脚本首选数据源找已删除但仍打开的文件sudo lsof L1磁盘空间不释放时排查清理 systemd 日志sudo journalctl --vacuum-size200M会压缩并删除旧日志清理 docker 环境docker system prune -a会删停止容器与悬空镜像调整系统参数sysctl vm.swappiness10配合 /etc/sysctl.conf 持久化查看 / 添加 swapswapon --show/swapon /swapfile持久化修改 fstab4.2 实操中反复踩的5个细节坑忘了 sudo。很多命令普通用户执行会直接 Permission denied新手第一反应是“命令不对”其实是没提权。lsblk 和 df 是特例默认可读但 blkid、fdisk、dmesg、du 遍历系统目录时很多都需要 sudo。在错误目录跑 du。du 只统计当前目录及其子目录当根文件系统有多个挂载点时你在一个目录里逐层找永远找不到另一个挂载点上的大文件。正确顺序是先 df 看哪个挂载点满再进对应目录 du。误把 buff/cache 高当成内存泄漏。Linux 会尽量用空闲内存做缓存这是设计行为不是故障。判断内存是否足够要看 available 和 swap 换页情况不是看 free 和 buff/cache。在 fdisk 里误删分区。生产机器上分区先 p 打印分区表确认盘符和分区编号。所有修改在按下 w 之前都可以按 q 退出别急着落盘。删除文件后空间不释放以为是文件没删干净。如果文件被进程打开着即使从目录里删除空间也不会归还。让日志进程重新打开日志文件或重启服务才是正解重复删文件没有意义。5. 写在最后我最后分享一个自己摸索出来的习惯无论排查硬盘还是内存永远先跑三条只读命令——lsblk、df -hT、free -h把盘、容量、内存的静态现状一次性看清然后再用du、top、vmstat去追根溯源。凡是会改变系统的操作比如 fdisk、mkfs、swapoff、lsof 之后去 kill 进程都必须确认目标再动手。遇到一时找不到原因的“空间消失”和“内存莫名被吃”优先怀疑文件句柄和进程泄漏而不是急着删数据。把这里整理的命令在自己测试机上挨个跑一遍输出和文章里的样例对照着看熟悉之后下次再碰到磁盘满、内存告警你就有一条清晰的排查路线不会慌。