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)进程状态这列信息量很大由多个字母组合SSleeping (睡眠)。进程正在等待资源绝大多数是在等硬盘读写完成。如果是R则表示 Running正在用 CPU 算如果是D则表示 Disk Sleep不可中断的磁盘睡眠极度卡顿的死锁状态。l多线程。说明这个进程启用了多个线程你用了-processors 24所以出现了 l。前台进程。说明这个进程占据着当前终端你按 CtrlC 就能中断它。如果是后台进程这里会是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找谁干活杀谁用。看 STATR在算S/D在等等 I/O。比 START 和 TIME活了很久但 TIME 很短必定卡 I/O。看 COMMAND查参数看路径找配置有没有生效。实例结合psaux|grepapptainer acz6ty428082.10.0289650075728pts/0 Sl11:414:22 apptainer build myimage.sif /tmp/jupyterlab-env/ acz6ty41078828.00.54572860688292pts/0 Sl11: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 acz6ty4315770.00.0112740960pts/1 S15:000:00grep--colorauto apptainer[acz6ty4okxa16r3n09 tmp]$[acz6ty4okxa16r3n09 tmp]$# 看 mksquashfs 进程[acz6ty4okxa16r3n09 tmp]$psaux|grepmksquashfs acz6ty41078828.00.54572860688292pts/0 Sl11: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 acz6ty4316030.00.0112740960pts/1 S15:000:00grep--colorauto mksquashfs[acz6ty4okxa16r3n09 tmp]$[acz6ty4okxa16r3n09 tmp]$# 看 CPU 占用[acz6ty4okxa16r3n09 tmp]$top-b-n1|grep-Emksquashfs|apptainer2808acz6ty4200289650075728504S0.00.14:22.04 apptainer10788acz6ty42004572860688292868S0.00.551:15.79 mksquashfsapptainer build 还在跑PID 2808 和 10788 就是之前跑了 2 小时的那个——gzip Parastorpsaux|grepmksquashfspsaux|grepapptainer # 解读好的我们来逐行解读这段进程信息它非常清晰地揭示了**为什么你的构建跑了2个小时还没完**。### 1. 父进程Apptainer (PID 2808)text acz6ty428082.10.0289650075728pts/0 Sl11: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倍这是耗时极长的核心原因。问题二读写全在 /homeParastor网络盘上源读/public/home/.../build-temp-.../rootfs目标写/public/home/.../bundle-temp-.../squashfs-...虽然你的 sandbox 在/tmp但因为之前设置了APPTAINER_TMPDIR指向/homeApptainer 把 sandbox 里几万个小文件先复制到了 /home然后在 /home 上进行读写。网络盘的随机读写极慢这叫 I/O 灾难。问题三严重等待 I/O卡在磁盘读写11:57mksquashfs 启动时间。51:15它占用的 CPU 时间51分15秒。算一笔账从 11:57 到 15:00实际流逝了 3 个多小时但 mksquashfs 真正用 CPU 计算的时间只有 51 分钟。剩下的 2 个多小时去哪了全在等网络盘响应I/O WaitCPU 闲置磁盘转不动。3. 总结为什么会跑2小时以上这段信息描绘了一个完美的“慢速灾难”场景错用 Gzip 压缩比 LZ4 慢 10-20 倍错用网络盘读写几万个小文件比本地盘慢 10-100 倍两者叠加导致 CPU 绝大多数时间都在“等磁盘”实际计算推进极慢。下一步必须怎么做这就是为什么我强烈建议你杀掉当前进程改用直接调mksquashfs的方案杀掉旧进程kill -9 2808 10788直接用 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 分钟左右就能跑完。