Question

我有一个ARMv7 Cortex-A8 (1 Core , 13-pipeline depth)和512M的设备运行超过250个线程；但是，最高命令的平均负载似乎低于1或略高于1.5 [1]。

使用vmstat [2]时，我可以看到procs（r）似乎经常比设备上可用的内核[2]高，在这种情况下，它只是一个单核cpu。

在设备上运行的一个进程中对GC收集进行概要分析时，我得到以下信息[3] ：，有趣的是，与（用户+ sys）时间相比，实时时间要高得多；因此，例如，据报道，GC消耗了226毫秒，而实时消耗了230毫秒。

给出以下内容：假设设备正在遭受CPU争用是否正确如果可以，CPU争用是否会反映在使用top的平均负载上？最上面的平均负载是线程引起的cpu争用的良好指示器吗？还有什么会导致vmstat的procs -r count值偏高？

[3]
2019-01-21T10:18:55.607+0000: 78.012: [GC (Allocation Failure) 2019-01-21T10:18:55.608+0000: 78.013: [DefNew: 5632K->576K(5632K), 0.2220500 secs] 13789K->9541K(17928K), 0.2260043 secs] [Times: user=0.06 sys=0.00, real=0.23 secs]

2019-01-21T10:26:18.394+0000: 520.799: [GC (Allocation Failure) 2019-01-21T10:26:18.396+0000: 520.801: [DefNew: 9423K->601K(9792K), 0.1988650 secs] 30450K->21806K(31360K), 0.2060742 secs] [Times: user=0.07 sys=0.00, real=0.21 secs]

2019-01-21T10:19:51.661+0000: 134.066: [GC (Allocation Failure) 2019-01-21T10:19:51.663+0000: 134.068: [DefNew: 9560K->766K(9792K), 0.3196409 secs] 22499K->13926K(31360K), 0.3309429 secs] [Times: user=0.04 sys=0.02, real=0.33 secs] 


[1]
//Top
top - 10:40:04 up  1:58,  8 users,  load average: 1.66, 1.23, 1.64
Threads: 251 total,   3 running, 248 sleeping,   0 stopped,   0 zombie

[2]
Vmsatat 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0      0  16136  22012 232432    0    0     0     0 1614 3670 40 35 26  0  0
 3  0      0  21740  22012 232444    0    0     0     0 2576 5744 61 39  0  0  0
 0  0      0  21628  22012 232448    0    0     0     0 2006 4809 52 22 26  0  0
 0  0      0  21740  22012 232448    0    0     0     0  595  843  5  8 87  0  0
 3  0      0  21740  22012 232448    0    0     0     0  140  309  2  4 94  0  0
 0  0      0  21740  22036 232448    0    0     0   116  220  349  8  3 89  0  0
 2  0      0  21740  22036 232448    0    0     0     0  125  282  2  3 95  0  0
 0  0      0  21740  22036 232448    0    0     0     0  129  280  2  4 94  0  0
 1  0      0  21740  22036 232448    0    0     0     0  127  266  3  3 94  0  0
 0  0      0  21740  22036 232448    0    0     0     4  145  315  3  3 94  0  0
 2  0      0  18988  22036 232448    0    0     0     0 1619 3888 43 38 19  0  0
 2  0      0  24592  22040 232444    0    0     0    36 2315 5472 64 36  0  0  0
 0  0      0  24480  22040 232444    0    0     0     0 1766 4273 51 23 26  0  0
 0  0      0  24512  22040 232444    0    0     0     0  658 1033  6  7 87  0  0
 0  0      0  24544  22040 232444    0    0     0     0  163  353  1  4 95  0  0
 0  0      0  24544  22040 232444    0    0     0     0  122  242  3  3 94  0  0
 1  0      0  24544  22040 232444    0    0     0     0  142  304  1  4 95  0  0
 0  0      0  24544  22040 232444    0    0     0     0  137  294  2  4 94  0  0
 0  0      0  24544  22040 232444    0    0     0     0  137  276  3  4 93  0  0
 0  0      0  24544  22040 232444    0    0     0     0  134  308  3  2 95  0  0
 9  0      0  19080  22040 232448    0    0     0     0 1952 4268 42 37 20  0  0
 1  0      0  24460  22040 232456    0    0     0     0 2058 4523 65 35  0  0  0
 2  0      0  24560  22040 232452    0    0     0     0 3057 7385 58 42  0  0  0

Answer 1

Linux平均负载代表（大致而言）处于R，D或（历史上）W状态的操作系统进程队列中的进程或线程数。

https://unix.stackexchange.com/questions/9465/understanding-top-and-load-average

top上的平均负载是否很好地表明了线程导致的CPU争用？

不一定。

这可能是由进程而不是线程引起的。
D状态意味着该进程正在等待“不可互斥”的I / O：通常是文件系统操作。因此，如果您访问的文件系统速度较慢（例如，网络文件服务器负载很重），则可能会增加平均负载。

还有什么会导致vmstat的{{1}}计数较高？

根据procs -r手动输入，vmstat列实际上是处于r状态的进程（或线程）数。 R列是处于d状态的进程数。请注意，这些是瞬时量度，而不是平均值。

所以，答案是过程。

要注意的另一件事是，JVM可能在运行GC时挂起了所有应用程序线程（用于该进程）。根据GC的实施，此暂停可能在GC运行期间或仅在某些阶段进行。

因此，您观察到GC CPU时间和时钟时间几乎相同并不意味着没有CPU争用。

相反，GC CPU时间和时钟时间之间的重大差异并不一定意味着存在CPU争用（应用程序线程或其他进程）。另一种可能性是争用（实际的）内存页面。即虚拟内存崩溃。

使用GC中报告的实时信息来验证单个内核上的CPU竞争吗？

1 个答案: