为什么/proc/stat数超过100个勾/S？

Question

我有一位开发人员抱怨/proc/stat报告的CPU使用情况不一致。

据我了解，/proc/stat正在计算蜱数，自内核2.6以来，已将其固定为100/s。

现在我已经在CPU1上观察到，/proc/stat可能在一秒钟内计数超过100个蜱，这是不可能的。

这个脚本显示了我是如何计算的。

cat /proc/uptime
b=`awk /cpu1/'{print $2+$3+$4+$5+$6+$7+$8+$9+$10+$11}' /proc/stat`
sleep 1
a=`awk /cpu1/'{print $2+$3+$4+$5+$6+$7+$8+$9+$10+$11}' /proc/stat`
cat /proc/uptime
expr $a - $b

示例输出

32.80 19.06
33.86 19.51
CPU1 jiffies/s 137

我总结了/proc/stat中的字段，等等，然后再做一次。然后我有时得到一个大约140的和差。它相当稳定，可以上上下下数数。

内核的CONFIG_HZ是100。如果我用250或1000编译，变化会变小，但仍然存在。

它似乎是用户空间和空闲字段的计数，大多数jiffies。在一个样本中，我计算了102个用户空间jiffies，这可以用多睡20 ms来解释。因此，用户空间占据了所有的时间。但是，还有33条空闲的代码，它们都是在一个已经预订满的CPU上执行的。

我有一个双核ARMv7处理器，运行带有RT抢占补丁的Linux kernel 4.14.34。同时，我还运行了一个实时控制应用程序。

我的问题是/proc/stat数据不一致。但是要理解这一点，我非常想了解为什么/proc/stat可以计算在100以上。

编辑:在脚本中添加cat /proc/uptime

Answer 1

您使用的脚本是主要问题。就延迟而言，上下文切换是非常昂贵的。sleep 1将您的脚本置于休眠状态。当定时器完成后，processus将再次运行，也可能被重新分配到cpu的另一个核心(迁移)。因此，从根本上说，您并不是每1000 as就轮询一次/proc/stat，因为您可以在帖子中说明这一点。

顺便说一句，这不是评估RT内核的一个很好的方法。

我真的邀请您以Solarflare sysjitter为例，它将为您提供关于内核运行方式的更好的度量。

其主要概念是将一个无限循环固定在一个核心(每个核运行一个线程)上，该核心将时间标记计数器(TSC)寄存器集中在一起，并比较以下两个值，以了解每次内核抢占运行过程(假定为100 an )时可能发生的差异。

这样，您就可以更好地了解服务器的系统抖动，并决定对其进行更多的调优。

此外，如果您的用例需要这样的改进，您还应该查看cpu隔离，以便为您的应用程序拥有专用核心，以及动态标记内核配置。

编辑:我建议您只使用awk来满足您的所有需要，使用下面这样的小脚本：

#!/usr/bin/awk 

BEGIN { 
    sum1=0;
    sum2=0;
    result=0;
    file="/proc/stat";



while (( getline < file ) > 0 ) {
    if ($1=="cpu1"){ sum1=$2+$3+$4+$5+$6+$7+$8+$9+$10+$11 }; 
    } 
    close(file) ;
    print  "firt time " sum1;
    system("sleep 10");

while (( getline < file ) > 0 ) {
        if ($1=="cpu1") { sum2=$2+$3+$4+$5+$6+$7+$8+$9+$10+$11 }
    }
    close (file)
    print "secont time " sum2;
    result=sum2-sum1;
    print "sum is " result/10;
}

这个样本超过10秒，将结果除以10，得到1s切片的平均时间。