如何为流程测量单独的CPU核心使用情况?

时间:2010-07-27 11:00:29

标签: linux multicore measurement performance

有没有办法测量核心的特定进程CPU使用率?

我知道top适用于测量整个系统的核心CPU使用率,而taskset可以提供有关允许该进程运行的CPU核心的信息。

但是,如何通过CPU内核测量特定进程的CPU使用率?

8 个答案:

答案 0 :(得分:117)

您仍然可以在 top 中执行此操作。当 top 正在运行时,按键盘上的“1”,它将显示每个核心的CPU使用率。

通过在特定用户帐户下运行特定流程来限制所显示的流程,并使用“u”类型限制该用户

答案 1 :(得分:71)

您可以使用:

 mpstat -P ALL 1

它显示了每个核心忙碌的程度,并且每秒都会自动更新。输出将是这样的(在四核处理器上):

10:54:41 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
10:54:42 PM  all    8.20    0.12    0.75    0.00    0.00    0.00    0.00    0.00   90.93
10:54:42 PM    0   24.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00   74.00
10:54:42 PM    1   22.00    0.00    2.00    0.00    0.00    0.00    0.00    0.00   76.00
10:54:42 PM    2    2.02    1.01    0.00    0.00    0.00    0.00    0.00    0.00   96.97
10:54:42 PM    3    2.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   98.00
10:54:42 PM    4   14.15    0.00    1.89    0.00    0.00    0.00    0.00    0.00   83.96
10:54:42 PM    5    1.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.00
10:54:42 PM    6    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
10:54:42 PM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

此命令不回答原始问题,即它不显示特定进程的CPU核心使用情况。

答案 2 :(得分:35)

您可以使用ps 例如在双核CPU上有两个忙线程的python进程:

$ ps -p 29492 -L -o pid,tid,psr,pcpu
  PID   TID PSR %CPU
29492 29492   1  0.0
29492 29493   1 48.7
29492 29494   1 51.9

(PSR是线程当前分配给的CPU ID)

你看到线程在同一个cpu核心上运行(因为GIL)

在jython中运行相同的python脚本,我们看到,脚本正在使用两个核心(还有许多其他服务或任何线程,几乎都是空闲的):

$ ps -p 28671 -L -o pid,tid,psr,pcpu
  PID   TID PSR %CPU
28671 28671   1  0.0
28671 28672   0  4.4
28671 28673   0  0.6
28671 28674   0  0.5
28671 28675   0  2.3
28671 28676   0  0.0
28671 28677   1  0.0
28671 28678   1  0.0
28671 28679   0  4.6
28671 28680   0  4.4
28671 28681   1  0.0
28671 28682   1  0.0
28671 28721   1  0.0
28671 28729   0 88.6
28671 28730   1 88.5

您可以处理输出并计算每个CPU核心的总CPU。

不幸的是,这种方法似乎不是100%可靠,有时我看到在第一种情况下,报告两个工作线程被分离到每个CPU核心,或者在后一种情况下,报告两个线程在同一个核心..

答案 3 :(得分:9)

htop概述了各个核心用法

答案 4 :(得分:4)

ps解决方案几乎就是我所需要的,并且抛出一些bash完全符合原始问题的要求:查看特定进程的每个核心用法

这也显示了多线程进程的每个核心用法。

使用如下: cpustat`pgrep processname``pgrep otherprocessname` ...

#!/bin/bash

pids=()
while [ $# != 0 ]; do
        pids=("${pids[@]}" "$1")
        shift
done

if [ -z "${pids[0]}" ]; then
        echo "Usage: $0 <pid1> [pid2] ..."
        exit 1
fi

for pid in "${pids[@]}"; do
        if [ ! -e /proc/$pid ]; then
                echo "Error: pid $pid doesn't exist"
                exit 1
        fi
done

while [ true ]; do
        echo -e "\033[H\033[J"
        for pid in "${pids[@]}"; do
                ps -p $pid -L -o pid,tid,psr,pcpu,comm=
        done
        sleep 1
done

注意:这些统计信息基于进程生存期,而非最后 X 秒,因此您需要重新启动进程才能重置计数器。

答案 5 :(得分:2)

dstat -C 0,1,2,3 

还会为您提供前4个核心的CPU使用率。当然,如果你有32个内核,那么这个命令会更长一点,但如果你只对几个内核感兴趣,那么这个命令很有用。

例如,如果您只对核心3和7感兴趣,那么您可以

dstat -C 3,7

答案 6 :(得分:1)

我认为perf stat就是你所需要的。

当您指定--cpu=list选项时,它会显示进程的特定用法。以下是使用perf stat --cpu=0-7 --no-aggr -- make all -j命令监视构建项目的CPU使用情况的示例。输出是:

CPU0         119254.719293 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU1         119254.724776 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU2         119254.724179 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU3         119254.720833 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU4         119254.714109 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU5         119254.727721 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU6         119254.723447 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU7         119254.722418 task-clock (msec)         #    1.000 CPUs utilized            (100.00%)
CPU0                 8,108 context-switches          #    0.068 K/sec                    (100.00%)
CPU1                26,494 context-switches                                              (100.00%)
CPU2                10,193 context-switches                                              (100.00%)
CPU3                12,298 context-switches                                              (100.00%)
CPU4                16,179 context-switches                                              (100.00%)
CPU5                57,389 context-switches                                              (100.00%)
CPU6                 8,485 context-switches                                              (100.00%)
CPU7                10,845 context-switches                                              (100.00%)
CPU0                   167 cpu-migrations            #    0.001 K/sec                    (100.00%)
CPU1                    80 cpu-migrations                                                (100.00%)
CPU2                   165 cpu-migrations                                                (100.00%)
CPU3                   139 cpu-migrations                                                (100.00%)
CPU4                   136 cpu-migrations                                                (100.00%)
CPU5                   175 cpu-migrations                                                (100.00%)
CPU6                   256 cpu-migrations                                                (100.00%)
CPU7                   195 cpu-migrations                                                (100.00%)

左列是特定的CPU索引,最右边的列是CPU的使用情况。如果您未指定--no-aggr选项,则结果将汇总在一起。如果要监视正在运行的进程,--pid=pid选项将有所帮助。

尝试-a --per-core-a perf-socket,这将提供更多机密信息。

在本教程中可以看到有关perf stat用法的更多信息:perf cpu statisticperf help stat也有助于选项的含义。

答案 7 :(得分:0)

我遇到了这个问题,我找到了类似的答案here

方法是按照您希望的方式设置top,然后按W(大写W)。 这将top的当前布局保存到$ HOME / .toprc

中的配置文件中

如果您想要使用不同的配置运行多个top,这可能不起作用。

因此,通过我认为的解决方法,您可以通过执行以下操作之一来编写不同的配置文件/使用不同的配置文件...

1)重命名二进制文件

  ln -s /usr/bin/top top2
  ./top2

现在.top2rc将被写入您的$ HOME

2)将$ HOME设置为某个替代路径,因为它会将其配置文件写入$ HOME / .binary-name.rc文件

HOME=./
top

现在.toprc将被写入当前文件夹。

通过使用其他人的评论在顶部添加各种使用记帐,您可以为该信息创建批量输出,然后通过脚本合并信息。也许不像脚本那么简单,但我发现top可以为我提供所有进程,以便稍后我可以回顾并捕获长期运行中的状态,否则我可能会错过(由于杂散进程导致无法解释的突然CPU使用率)