☰

获取 Debian 进程花费的总 CPU 时间（即使是短暂的进程）

tag-icon • tag-icon linux bash cpu shell debian-stretch
获取 Debian 进程花费的总 CPU 时间（即使是短暂的进程）

为了我的硕士论文，我正在尝试获取有关 Debian 机器上的 MQTT 代理的资源使用信息。

我一直无法找到一种方法来找出 Debian 在我正在为其做资源使用统计的进程上总共花费了多少 CPU 时间。我尝试使用 pidstat 和 cpustat 来获取有关此进程的 CPU 统计信息，但要么：

  • CPU 时间以百分比显示（pidstat）
  • 对于短寿命进程 (cpustat) 来说，1s 的最小测量间隔太小。

有人能告诉我一种方法来找出一个进程使用了​​多少 CPU 时间（甚至是 CPU 周期）吗？

答案1

在顶上是一款很棒的工具，应该适合您的情况。它是一款改进的top会计工具（这正是您所需要的，原因我将在下文中说明）。

atop是一个守护进程，每 X 秒会记录大量统计数据（无论你如何配置，Debian 上的默认值是 60 秒），它会保存系统上所有进程及其使用情况的历史记录，基本上就像top快照。

atop还具有以可解析格式打印特定统计数据的功能：

atop -r /var/log/atop/atop_<date> -P <format>

这将从指定日期的日志文件中读取进程历史记录，并以特定于某些统计数据的机器可解析格式将其打印出来。

您需要的格式是中华人民共和国：

PRC  Process and thread level totals.
            This  line  contains the total cpu time consumed in system mode (`sys') and in user mode (`user'), the total number of processes present at this moment (`#proc'), the total number of threads present at this moment in state `running' (`#trun'), `sleeping
            interruptible' (`#tslpi') and `sleeping uninterruptible' (`#tslpu'), the number of zombie processes (`#zombie'), the number of clone system calls (`clones'), and the number of processes that ended during the interval (`#exit') when process accounting is
            used. Instead of `#exit` the last column may indicate that process accounting could not be activated (`no procacct`).
            If the screen-width does not allow all of these counters, only a relevant subset is shown.

例如，使用以下命令，您将获得如下输出：

$ atop -r /var/log/atop/atop_20200617 -P PRC
PRC hostname 1592403710 2020/06/17 14:21:50 5000098 377 (google_osconfig) S 100 262341 41122 0 120 0 0 0 0 377 y

其中，PID进程的总 SYS CPU 时间262341和总 USR CPU 时间是多少。41122google_osconfig377

atopacct.service是进行会计核算的服务，它是一个守护进程，因此它甚至可以核算短期运行的进程。

您可以通过包管理器在 Debian 9 上安装它：

sudo apt-get update
sudo apt-get install atop

然后它会自动开始记账。您可以在手册页。

答案2

使用time(1)。但对于真正短暂的过程来说，它可能不够准确。

记住shelltime内置命令不是time独立的可执行文件. 在 Bash 中help time描述内置命令；man 1 time描述可执行文件。

如果你可以自己运行要测量的工具（即你选择要运行的命令），那么它就很简单了。而不是the-tool argument1 argument2运行

time the-tool argument1 argument2
# or
/usr/bin/time the-tool argument1 argument2

如果the-tool它由其他工具运行，而您无法轻松地让它运行time the-tool …，那么请创建一个包装器脚本：

  1. 移至the-tool另一个名称，例如the-real-tool。

  2. 创建一个名为 的脚本the-tool，使其可执行并可通过 访问$PATH。内容：

    #!/bin/sh
exec /usr/bin/time the-real-tool "$@"

（或者，您也可以不重命名the-tool，而只将脚本放在the-tool出现在早期的目录中$PATH，以便其他工具在尝试运行时会找到该脚本the-tool。在脚本内部，您需要一个满的路径到真实的the-tool，所以脚本不会递归运行。）

研究man 1 time并注意--format和--output选择。您可能希望-a --output在包装器脚本中使用特别是来自动收集结果：

#!/bin/sh
log="/tmp/the-tool-$(date --rfc-3339=seconds)-$$.log"
printf '<%s> ' "$0" "$@" >"$log"
printf '\n' >>"$log"
exec /usr/bin/time -a --output="$log" the-real-tool "$@"

如果您使用bash并且其内置，那么您可以测量更精确. 仅记录time来自有点棘手在这种情况下，仍有可能：

#!/bin/bash
log="/tmp/the-tool-$(date --rfc-3339=seconds)-$$.log"
printf '<%s> ' "$0" "$@" >"$log"
printf '\n' >>"$log"
{ time the-real-tool "$@" 2>&3; } 3>&2 2>>"$log"

time研究了我的这个答案。与 的分辨率相比，它应该可以忽略不计time，尤其是对于内置的。对于包装脚本，解释器（sh或bash）也会增加总时间，但不会增加 报告的结果time。换句话说，测量结果the-real-tool不应该被夸大，但您需要等待the-tool-script 的时间会比等待the-tool-original（即the-real-tool现在）的时间稍长。

相关内容