ps aux的输出包含以下内容：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ubuntu 1496 9.1 0.0 0 0 pts/0 Z+ 19:47 0:30 [python] <defunct>
ubuntu 1501 14.6 0.0 0 0 pts/0 Z+ 19:47 0:48 [python] <defunct>
ubuntu 1502 14.8 0.0 0 0 pts/0 Z+ 19:47 0:48 [python] <defunct>
ubuntu 1503 15.1 0.0 0 0 pts/0 Z+ 19:47 0:49 [python] <defunct>
ubuntu 1504 15.4 0.0 0 0 pts/0 Z+ 19:47 0:50 [python] <defunct>
ubuntu 1505 15.8 0.0 0 0 pts/0 Z+ 19:47 0:52 [python] <defunct>
ubuntu 1506 16.0 0.0 0 0 pts/0 Z+ 19:47 0:53 [python] <defunct>
ubuntu 1507 14.1 0.0 0 0 pts/0 Z+ 19:47 0:46 [python] <defunct>
ubuntu 1508 14.3 0.0 0 0 pts/0 Z+ 19:47 0:47 [python] <defunct>
ubuntu 1509 14.4 0.0 0 0 pts/0 Z+ 19:47 0:47 [python] <defunct>
ubuntu 1510 14.6 0.0 0 0 pts/0 Z+ 19:47 0:48 [python] <defunct>
ubuntu 1511 14.9 0.0 0 0 pts/0 Z+ 19:47 0:49 [python] <defunct>
ubuntu 1512 10.7 0.0 0 0 pts/0 Z+ 19:47 0:35 [python] <defunct>
ubuntu 1513 71.3 0.0 0 0 pts/0 Z+ 19:47 3:55 [python] <defunct>
这些是通过多处理产生的一堆进程已经完成并等待父进程加入。他们为什么要占用CPU？
如果这只是ps的工件，我怎样才能准确了解正在使用多少CPU？
答案 0 :(得分：3)
僵尸进程（即'defunct'进程）不消耗CPU：它只是由内核保留，以便父进程可以检索有关它的信息（例如返回状态，资源使用等......）
ps命令指示的CPU使用率对应于进程运行时的CPU使用率：即之前终止并成为僵尸。
答案 1 :(得分：1)
这些是Zombie进程，如stat列中的Z所示 - 在父进程终止之前，它们不会被清除。我不太了解python，但可能是你在python解释器中调用了fork或类似的东西来生成它们。杀死翻译，僵尸将被收割（清理）。
如果您想获得有关CPU的最新信息，请尝试使用“top”命令。
另外，我更喜欢从“ps -ef”输出而不是“ps aux”aux总是让我感到非标准的黑客攻击（因此缺少用于分离命令和参数的' - '）它也无法工作许多其他Unix系统，如HPUX，AIX等。
“ps -ef”显示ppid（父母pid），它可以帮助您跟踪此类问题。
答案 2 :(得分：0)
有趣的是，也许令人困惑的是，到目前为止，我有一个僵尸进程，它正在我的系统上积累 CPU 时间。那么问题来了，为什么？常识是，ps 的任何显示僵尸进程的输出都意味着唯一使用的是进程表条目；来自维基百科：“...僵尸进程或失效进程是一个已经完成执行（通过退出系统调用）但在进程表中仍然有一个条目的进程：它是一个处于‘终止状态’的进程。”和来自unix.stackexchange：https://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init“僵尸进程几乎不占用资源，因此让它们停留不会产生性能成本。”
所以我有一个僵尸进程：
# ps -e -o pid,ppid,stat,comm| grep Z
7296 1 Zl myproc <defunct>
似乎在使用 CPU 时间：
# ps -e -o pid,ppid,bsdtime,stat,comm| grep Z; sleep 10; ps -e -o pid,ppid,bsdtime,stat,comm | grep Z
7296 1 56:00 Zl myproc <defunct>
7296 1 56:04 Zl myproc <defunct>
Zombie 进程如何累积 CPU 时间？
我更改了搜索：
# ps -eT -o pid,lwp,ppid,bsdtime,stat,comm| grep 7296
7296 7296 1 1:29 Zl myproc <defunct>
7296 8009 1 56:11 Dl myproc
并且我看到我有一个正在运行的线程，并且正在使用系统 i/o。事实上，如果我这样做，我可以看到字段 15 (stime) 发生变化：
# watch -d -n 1 cat /proc/8009/stat
Every 1.0s: cat /proc/8009/stat Fri Jun 4 11:19:55 2021
8009 (myproc) D 1 7295 7295 0 -1 516 18156428 12281 37 0 11609 344755
（在字段 15 处修剪）
所以我尝试使用 TERM 杀死进程 8009... 没有用。用 KILL 杀死它也是徒劳的。
对我来说听起来像是内核错误。我确实尝试跟踪它，这是愚蠢的，因为现在我的 strace 不会退出。
这是在内核为 3.10.0-1062 的 RHEL 7.7 上。在这个时候很老，但足够年轻，可以得出结论（在我看来）僵尸进程可能由于某个地方的错误而积累系统资源。
顺便说一下，根据 iotop 我们的 I/O 峰值为 4 GBps，这已经很多了。我觉得这个东西肯定对我们的系统有影响，我想重新启动。
/proc/8009 的 ls 输出返回：
# ls -l /proc/8009
ls: cannot read symbolic link /proc/8009/cwd: No such file or directory
ls: cannot read symbolic link /proc/8009/root: No such file or directory
ls: cannot read symbolic link /proc/8009/exe: No such file or directory
（正常的 /proc/pid 输出如下......但我修剪了它）
/proc/8009/fd 是空的。因此，即使我进行了大量的 I/O，它也不会写入任何文件。我没有看到文件系统空间被使用，如 df -h 输出所示。
最后：事实证明，尝试重新启动是不可能的。 shutdown -r now 不起作用。有几个 systemd 进程卡在 i/o 等待中：
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
22725 root 20 0 129M 2512 1548 R 0.0 0.0 0:00.19 htop
22227 root 20 0 195M 4776 2652 D 0.0 0.0 0:00.00 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
1 root 20 0 195M 4776 2652 D 0.0 0.0 0:58.41 /usr/lib/systemd/systemd --switched-root --system --deserialize 22
这是关机输出。我会说 init 在这一点上很困惑：
# shutdown -r now
Failed to open /dev/initctl: No such device or address
Failed to talk to init daemon.
reboot 说同样的话。我得拔掉这台机器的插头。
...更新：就在我登录控制台时，系统重新启动！大概需要10分钟。所以我不知道 systemd 在做什么，但它正在做一些事情。
...另一个更新：所以我今天有 3 台机器发生了这种情况，它们都具有相同的特征：相同的二进制文件，某种行为（没有打开的文件描述符，但是发生了 I/O，两个线程，子进程线程正在累积 CPU 时间）。正如@Stephane Chazelas 提到的，我执行了堆栈跟踪。这是一个典型的输出；我不是很精通内核，但也许将来某些闯入者会感兴趣......请注意，242603 是父线程，242919 是忙碌的子线程：
# grep -H . /proc/242919/task/*/stack
/proc/242919/task/242603/stack:[<ffffffff898a131e>] do_exit+0x6ce/0xa50
/proc/242919/task/242603/stack:[<ffffffff898a171f>] do_group_exit+0x3f/0xa0
/proc/242919/task/242603/stack:[<ffffffff898b252e>] get_signal_to_deliver+0x1ce/0x5e0
/proc/242919/task/242603/stack:[<ffffffff8982c527>] do_signal+0x57/0x6f0
/proc/242919/task/242603/stack:[<ffffffff8982cc32>] do_notify_resume+0x72/0xc0
/proc/242919/task/242603/stack:[<ffffffff89f8c23b>] int_signal+0x12/0x17
/proc/242919/task/242603/stack:[<ffffffffffffffff>] 0xffffffffffffffff
/proc/242919/task/242919/stack:[<ffffffffc09cbb03>] ext4_mb_new_blocks+0x653/0xa20 [ext4]
/proc/242919/task/242919/stack:[<ffffffffc09c0a36>] ext4_ext_map_blocks+0x4a6/0xf60 [ext4]
/proc/242919/task/242919/stack:[<ffffffffc098fcf5>] ext4_map_blocks+0x155/0x6e0 [ext4]
/proc/242919/task/242919/stack:[<ffffffffc0993cfa>] ext4_writepages+0x6da/0xcf0 [ext4]
/proc/242919/task/242919/stack:[<ffffffff899c8d31>] do_writepages+0x21/0x50
/proc/242919/task/242919/stack:[<ffffffff899bd4b5>] __filemap_fdatawrite_range+0x65/0x80
/proc/242919/task/242919/stack:[<ffffffff899bd59c>] filemap_flush+0x1c/0x20
/proc/242919/task/242919/stack:[<ffffffffc099116c>] ext4_alloc_da_blocks+0x2c/0x70 [ext4]
/proc/242919/task/242919/stack:[<ffffffffc098a4d9>] ext4_release_file+0x79/0xc0 [ext4]
/proc/242919/task/242919/stack:[<ffffffff89a4a9cc>] __fput+0xec/0x260
/proc/242919/task/242919/stack:[<ffffffff89a4ac2e>] ____fput+0xe/0x10
/proc/242919/task/242919/stack:[<ffffffff898c1c0b>] task_work_run+0xbb/0xe0
/proc/242919/task/242919/stack:[<ffffffff898a0f24>] do_exit+0x2d4/0xa50
/proc/242919/task/242919/stack:[<ffffffff898a171f>] do_group_exit+0x3f/0xa0
/proc/242919/task/242919/stack:[<ffffffff898b252e>] get_signal_to_deliver+0x1ce/0x5e0
/proc/242919/task/242919/stack:[<ffffffff8982c527>] do_signal+0x57/0x6f0
/proc/242919/task/242919/stack:[<ffffffff8982cc32>] do_notify_resume+0x72/0xc0
/proc/242919/task/242919/stack:[<ffffffff89f8256c>] retint_signal+0x48/0x8c
/proc/242919/task/242919/stack:[<ffffffffffffffff>] 0xffffffffffffffff