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

ps aux讲解

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

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

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，从而锁定了“慢”的另一个元凶。

💡 总结成排查口诀：

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

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，

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) —— 罪魁祸首

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小时以上？

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

下一步必须怎么做？

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