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

💡 总结成排查口诀：

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

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

psaux|grepapptainer acz6ty4+28082.10.0289650075728pts/0 Sl+11:414:22 apptainer build myimage.sif /tmp/jupyterlab-env/ acz6ty4+1078828.00.54572860688292pts/0 Sl+11:5751: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+315770.00.0112740960pts/1 S+15:000:00grep--color=auto apptainer[acz6ty4okx@a16r3n09 tmp]$[acz6ty4okx@a16r3n09 tmp]$# 看 mksquashfs 进程[acz6ty4okx@a16r3n09 tmp]$psaux|grepmksquashfs acz6ty4+1078828.00.54572860688292pts/0 Sl+11:5751: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+316030.00.0112740960pts/1 S+15:000:00grep--color=auto mksquashfs[acz6ty4okx@a16r3n09 tmp]$[acz6ty4okx@a16r3n09 tmp]$# 看 CPU 占用[acz6ty4okx@a16r3n09 tmp]$top-b-n1|grep-E"mksquashfs|apptainer"2808acz6ty4+200289650075728504S0.00.14:22.04 apptainer10788acz6ty4+2004572860688292868S0.00.551:15.79 mksquashfs

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

psaux|grepmksquashfspsaux|grepapptainer ```# 解读，好的，我们来逐行解读这段进程信息，它非常清晰地揭示了**为什么你的构建跑了2个小时还没完**。### 1. 父进程：Apptainer (PID 2808)```text acz6ty4+28082.10.0289650075728pts/0 Sl+11:414: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小时以上？

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

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

下一步必须怎么做？

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

1. 杀掉旧进程：kill -9 2808 10788
2. 直接用 mksquashfs 手动打包（绕过 Apptainer 复制文件到 /home 的智障行为）：

   mksquashfs /tmp/jupyterlab-env/ /public/home/acz6ty4okx/rootfs.img\-complz4-processors24-b1048576\-noappend-all-root

   • 这个命令：强制用 LZ4 + 24核，从 /tmp（本地盘）读，写一个大文件到 /home（写一个大文件对网络盘压力很小）。
     按照这个新方案，原本 2 小时的活，10-20 分钟左右就能跑完。