ps aux讲解，结合国家超算中心 hpc apptainer

`ps aux`讲解

text 复制代码

acz6ty4+ 10788 28.0  0.5 4572860 688292 pts/0  Sl+  11:57  51:15 /usr/sbin/mksquashfs ...

ps aux 的标准表头对应如下：

text 复制代码

USER      PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

下面是每一列的详细含义，以及在你这个案例中的解读：

1. 身份信息

USER (acz6ty4+)：运行该进程的用户。截断显示了你的用户名。说明这是你以普通用户身份启动的，不是 root。
PID (10788) ：进程 ID (Process ID) 。
- 这是系统给每个进程的唯一编号，极其重要 。你要杀掉卡住的进程，就要用 kill -9 10788。

2. CPU 与内存占用

%CPU (28.0) ：进程占用的 CPU 百分比。
- 你给了 24 个核，这里显示 28%，说明它大概吃满了不到 1 个核的计算能力。对于一个号称多线程的压缩任务，这个数值太低了，说明 CPU 没跑满。
%MEM (0.5) ：进程占用的物理内存 (RAM) 占总内存的百分比。
- 0.5% 说明内存占用极小，瓶颈不在内存。

3. 内存详细指标（找内存泄漏看这里）

VSZ (4572860) ：虚拟内存 ，单位是 KB（约 4.3 GB）。
- 这是进程"向系统申请"的内存总量，包含了还没实际使用的、或者映射了磁盘文件的内存。这个数字通常偏大，不能作为真实内存占用的依据。
RSS (688292) ：物理内存 ，单位是 KB（约 672 MB）。
- 这是进程真真切切住在 RAM 里的内存大小。看真实内存消耗主要看这个。对 mksquashfs 来说，不到 700MB 很正常。

4. 执行环境

TTY (pts/0) ：终端类型。
- pts/0 表示你是通过 SSH 登录的第一个虚拟终端打开的。如果是 ?，则表示该进程是后台守护进程（不需要终端）。
STAT (Sl+) ：进程状态 ，这列信息量很大，由多个字母组合：
- S ：Sleeping (睡眠) 。进程正在等待资源（绝大多数是在等硬盘读写完成）。如果是 R 则表示 Running（正在用 CPU 算），如果是 D 则表示 Disk Sleep（不可中断的磁盘睡眠，极度卡顿的死锁状态）。
- l ：多线程 。说明这个进程启用了多个线程（你用了 -processors 24，所以出现了 l）。
- + ：前台进程 。说明这个进程占据着当前终端，你按 Ctrl+C 就能中断它。如果是后台进程，这里会是 Ssl 等没有 + 的状态。

5. 时间信息（排查卡顿的核心！）

START (11:57) ：进程的启动时间 。
- 说明 mksquashfs 是在 11:57 开始跑的。
TIME (51:15) ：进程真正占用 CPU 的累计时间 。
- 这是大家最常误解的一列！它不是进程存活了多久，而是 CPU 花了多少时间在帮它干活。
- 解读：从 11:57 启动到你查看时，墙上时钟过了 3 个多小时，但 TIME 只有 51 分钟。那剩下的 2 个多小时去哪了？进程处于 S 状态（睡眠），全在等 I/O！这就是判断 I/O 瓶颈的铁证。

6. 命令详情

COMMAND (/usr/sbin/mksquashfs ...) ：启动该进程的完整命令及参数。
- 这是排错的最后一环。通过看参数，我们发现了它没有带上 -comp lz4，从而锁定了"慢"的另一个元凶。

💡 总结成排查口诀：

看 PID：找谁干活，杀谁用。
看 STAT ：R 在算，S/D 在等（等 I/O）。
比 START 和 TIME：活了很久但 TIME 很短，必定卡 I/O。
看 COMMAND：查参数，看路径，找配置有没有生效。

实例，结合ａｐｐｔａｉｎｅｒ

bash 复制代码

ps aux | grep apptainer
acz6ty4+  2808  2.1  0.0 2896500 75728 pts/0   Sl+  11:41   4:22 apptainer build myimage.sif /tmp/jupyterlab-env/
acz6ty4+ 10788 28.0  0.5 4572860 688292 pts/0  Sl+  11:57  51:15 /usr/sbin/mksquashfs /public/home/acz6ty4okx/apptainer_tmp/build-temp-4046372221/rootfs /public/home/acz6ty4okx/apptainer_tmp/bundle-temp-166374640/squashfs-1518890061 -noappend -all-root
acz6ty4+ 31577  0.0  0.0 112740   960 pts/1    S+   15:00   0:00 grep --color=auto apptainer
[acz6ty4okx@a16r3n09 tmp]$ 
[acz6ty4okx@a16r3n09 tmp]$ # 看 mksquashfs 进程
[acz6ty4okx@a16r3n09 tmp]$ ps aux | grep mksquashfs
acz6ty4+ 10788 28.0  0.5 4572860 688292 pts/0  Sl+  11:57  51:15 /usr/sbin/mksquashfs /public/home/acz6ty4okx/apptainer_tmp/build-temp-4046372221/rootfs /public/home/acz6ty4okx/apptainer_tmp/bundle-temp-166374640/squashfs-1518890061 -noappend -all-root
acz6ty4+ 31603  0.0  0.0 112740   960 pts/1    S+   15:00   0:00 grep --color=auto mksquashfs
[acz6ty4okx@a16r3n09 tmp]$ 
[acz6ty4okx@a16r3n09 tmp]$ # 看 CPU 占用
[acz6ty4okx@a16r3n09 tmp]$ top -b -n 1 | grep -E "mksquashfs|apptainer"
 2808 acz6ty4+  20   0 2896500  75728    504 S   0.0  0.1   4:22.04 apptainer
10788 acz6ty4+  20   0 4572860 688292    868 S   0.0  0.5  51:15.79 mksquashfs

apptainer build 还在跑！ PID 2808 和 10788 就是之前跑了 2 小时的那个------gzip + Parastor，

bash 复制代码

ps aux | grep mksquashfs
ps aux | grep apptainer
```　


# 解读，
好的，我们来逐行解读这段进程信息，它非常清晰地揭示了**为什么你的构建跑了2个小时还没完**。
### 1. 父进程：Apptainer (PID 2808)
```text
acz6ty4+  2808  2.1  0.0 2896500 75728 pts/0   Sl+  11:41   4:22 apptainer build myimage.sif /tmp/jupyterlab-env/

11:41：这是你启动构建的时间。
4:22 ：这是该进程占用的 CPU 时间（4分22秒）。
解读：这是总控进程。它启动后，把打包工作交给了子进程 mksquashfs，自己就在那干等。所以它占用的CPU时间极短，基本没干活。

2. 子进程：mksquashfs (PID 10788) ------ 罪魁祸首

text 复制代码

acz6ty4+ 10788 28.0  0.5 4572860 688292 pts/0  Sl+  11:57  51:15 /usr/sbin/mksquashfs /public/home/acz6ty4okx/apptainer_tmp/build-temp-4046372221/rootfs /public/home/acz6ty4okx/apptainer_tmp/bundle-temp-166374640/squashfs-1518890061 -noappend -all-root

这是真正在干活的进程，这段信息暴露了三个致命问题：

问题一：LZ4 参数完全没生效！
- 看命令结尾：只有 -noappend -all-root。
- 没有 -comp lz4，没有 -processors 24，没有 -b 1048576！
- 这意味着它用的是默认的 gzip 压缩 。Gzip 压缩率稍高，但速度比 LZ4 慢 10到20倍！这是耗时极长的核心原因。
问题二：读写全在 /home（Parastor网络盘）上！
- 源（读）：/public/home/.../build-temp-.../rootfs
- 目标（写）：/public/home/.../bundle-temp-.../squashfs-...
- 虽然你的 sandbox 在 /tmp，但因为之前设置了 APPTAINER_TMPDIR 指向 /home，Apptainer 把 sandbox 里几万个小文件先复制到了 /home，然后在 /home 上进行读写。网络盘的随机读写极慢，这叫 I/O 灾难。
问题三：严重等待 I/O（卡在磁盘读写）
- 11:57：mksquashfs 启动时间。
- 51:15：它占用的 CPU 时间（51分15秒）。
- 算一笔账 ：从 11:57 到 15:00，实际流逝了 3 个多小时 ，但 mksquashfs 真正用 CPU 计算的时间只有 51 分钟。剩下的 2 个多小时去哪了？全在等网络盘响应（I/O Wait）！ CPU 闲置，磁盘转不动。

3. 总结：为什么会跑2小时以上？

这段信息描绘了一个完美的"慢速灾难"场景：

错用 Gzip 压缩（比 LZ4 慢 10-20 倍）
错用网络盘读写几万个小文件（比本地盘慢 10-100 倍）
两者叠加，导致 CPU 绝大多数时间都在"等磁盘"，实际计算推进极慢。

下一步必须怎么做？

这就是为什么我强烈建议你杀掉当前进程，改用直接调 mksquashfs 的方案：

杀掉旧进程 ：kill -9 2808 10788
直接用 mksquashfs 手动打包 （绕过 Apptainer 复制文件到 /home 的智障行为）：
bash 复制代码
```
mksquashfs /tmp/jupyterlab-env/ /public/home/acz6ty4okx/rootfs.img \
  -comp lz4 -processors 24 -b 1048576 \
  -noappend -all-root
```
- 这个命令：强制用 LZ4 + 24核，从 /tmp（本地盘）读 ，写一个大文件到 /home （写一个大文件对网络盘压力很小）。
  按照这个新方案，原本 2 小时的活，10-20 分钟左右就能跑完。