Analyse des métriques d'utilisation du processeur !

C'est vrai, ce dont je parle ici, c'est la métrique « %CPU » que tout le monde utilise partout, dans chaque produit de surveillance des performances. Utilisez la commande top(1) pour l'afficher.
Vous pensez peut-être qu'une utilisation du processeur à 90 % signifie :

Et en fait, cela pourrait signifier :

Bloqué signifie que le processeur ne progresse pas dans le traitement des instructions, généralement parce que le processeur attend des entrées/sorties mémoire. Le rapport que j'ai dessiné ci-dessus (entre occupé et bloqué) est ce que je vois souvent dans les environnements de production réels. Il est possible que vous soyez pratiquement au point mort et que vous ne le sachiez même pas.

Qu'est-ce que cela signifie pour vous ? Savoir dans quelle mesure votre processeur est bloqué peut guider les efforts de réglage des performances entre la réduction du code ou la réduction des E/S de la mémoire. Quiconque s'intéresse aux performances du processeur, en particulier dans un cloud qui met automatiquement à l'échelle les ressources en fonction du processeur, aurait intérêt à savoir où se situe le pourcentage de processeur.

Quelle est réellement l’utilisation du processeur ?

La mesure que nous appelons l'utilisation du processeur est en fait le « temps non inactif » : c'est-à-dire le temps pendant lequel le processeur n'exécute pas de threads inactifs. Le noyau de votre système d'exploitation (quel qu'il soit) suit généralement cette métrique lors des changements de contexte. Si un processus non inactif démarre puis s'arrête pendant 100 millisecondes, le noyau considère toujours que le processeur est utilisé pendant toute cette période.

Cette métrique est aussi ancienne que les systèmes de partage de temps. L'ordinateur de guidage du module lunaire Apollo, un système pionnier de partage de temps, a appelé son thread inactif « DUMMY JOB ». Les ingénieurs ont suivi les cycles nécessaires pour exécuter le thread inactif par rapport aux cycles nécessaires pour exécuter la tâche réelle, afin de mesurer la performance de l'ordinateur. Un indicateur d’usage important.

Alors, quel est le problème avec cet indicateur ?

De nos jours, les processeurs sont devenus beaucoup plus rapides que la mémoire principale, et la mémoire d'attente représente une grande partie de ce que l'on appelle encore « l'utilisation du processeur ». Si vous voyez un nombre % CPU élevé, vous pourriez penser que le processeur est le goulot d'étranglement (c'est-à-dire le boîtier CPU sous le dissipateur thermique et le ventilateur), alors qu'en fait ce sont les modules DRAM qui sont le goulot d'étranglement.

La situation à cet égard devient de plus en plus grave. Pendant longtemps, les fabricants de processeurs ont augmenté les vitesses d'horloge plus que la DRAM n'a augmenté les latences d'accès. C'est ce qu'on appelle « l'écart CPU-DRAM ». Cette situation s'est stabilisée vers 2005, lorsque les processeurs 3 GHz ont été introduits ; depuis lors, les processeurs ont utilisé davantage de cœurs et d'hyper-threading pour améliorer les performances, et ont utilisé des configurations multi-sockets, qui ont toutes imposé des exigences plus élevées au sous-système de mémoire. Les fabricants de processeurs tentent d'atténuer ce goulot d'étranglement de mémoire en utilisant des caches de processeur plus grands et plus intelligents et des technologies de bus mémoire et d'interconnexion plus rapides. Mais nous sommes encore globalement au point mort.

Comment indiquer ce que le CPU est réellement en train de traiter ?

Autant utiliser les compteurs de surveillance des performances (PMC) : il s'agit d'un compteur matériel qui peut être lu à l'aide des performances Linux et d'autres outils. Par exemple, mesurer l'ensemble du système pendant 10 secondes :

# perf stat -a — sleep 10
Performance counter stats for ‘system wide’:
641398.723351      task-clock (msec)         #  64.116 CPUs utilized         (100.00%)
379,651      context-switches          #    0.592 K/sec                 (100.00%)
51,546      cpu-migrations           #    0.080 K/sec                 (100.00%)
13,423,039       page-faults              #    0.021 M/sec
1,433,972,173,374      cycles                  #    2.236 GHz                  (75.02%)
<not>      stalled-cycles-frontend
<not>      stalled-cycles-backend
1,118,336,816,068      instructions              #    0.78  insns per cycle          (75.01%)
249,644,142,804       branches               #   389.218 M/sec                (75.01%)
7,791,449,769       branch-misses            #  3.12% of all branches          (75.01%)
10.003794539 seconds time elapsed</not></not>

Une mesure clé ici est les instructions par cycle (c'est-à-dire IPC), qui indiquent le nombre d'instructions que nous exécutons en moyenne par cycle d'horloge du processeur. En termes simples, plus la valeur est élevée, mieux c'est. Le 0,78 dans l'exemple ci-dessus semble bon (occupé 78 % du temps) ; mais pas lorsque l'on réalise que l'IPC à la vitesse maximale du processeur est de 4,0. Ceci est également appelé 4-wide, qui fait référence au chemin de récupération/décodage des instructions. Cela signifie que le processeur peut retirer (terminer) quatre instructions par cycle d'horloge. Ainsi, un IPC de 0,78 sur un système à 4 unités signifie que le processeur fonctionne à 19,5 % de sa vitesse maximale. Les nouveaux processeurs Intel Skylake ont une largeur de 5.

Il existe des centaines d'autres PMC que vous pouvez utiliser pour approfondir : vous pouvez mesurer directement les périodes stagnantes par différents types.

Dans le cloud

如果你在虚拟环境中，可能无法访问PMC，这要看虚拟机管理程序是否为访客（guest）支持PMC。我最近写过一篇文章：《EC2的PMC：测量IPC》，表明了如今PMC如何可用于基于Xen的AWS EC2云上面的专用主机类型。

实际对策

如果你的IPC

如果你的IPC > 1.0，你可能是指令密集型。想方设法减少代码执行：消除不必要的工作和缓存操作等。CPU火焰图是一款很适合开展这项调查的工具。至于硬件调优，不妨试一试更快的时钟频率和数量更多的核心/超线程。

性能监测产品应该能告诉你什么？

每一款性能工具应该显示IPC以及%CPU。或者将%CPU分解成指令完成周期与停滞周期，比如%INS和%STL。

面向Linux的tiptop(1)可按进程显示IPC：

tiptop –                 [root]
Tasks: 96 total,    3 displayed                                 screen   0: default
 
PID [ %CPU] %SYS  P   Mcycle   Minstr  IPC %MISS %BMIS  %BUS COMMAND
3897   35.3   28.5    4   274.06   178.23 0.65   0.06  0.00   0.0     java
1319+   5.5    2.6   6    87.32   125.55 1.44   0.34  0.26  0.0    nm-applet
900    0.9  0.0    6    25.91    55.55 2.14   0.12  0.21     0.0     dbus-daemo

CPU使用率具有误导性的其他理由

让CPU使用率具有误导性的不仅仅是内存停滞周期。其他因素包括如下：

• 温度过高导致处理器停滞。
• 睿频加速（Turboboost）导致时钟频率不一。
• 内核因speedstep导致时钟频率不一。
• 平均值方面的问题：1分钟内的使用率为80%，隐藏了100%的突发使用率。
• 自旋锁：CPU被使用，有很高的IPC，但是应用程序在处理指令方面没有合理的进展。

结束语

CPU使用率已成为一个极具误导性的度量指标：它包括了等待主内存的周期，而这类周期在现代工作负载中占了大头。如果使用额外的度量指标，你就能搞清楚%CPU到底意味着什么，包括每个周期指令（IPC）。IPC 1.0可能意味着指令密集型。我在之前的一篇文章中介绍了IPC，包括介绍了衡量IPC所需要的性能监控计数器（PMC）。 显示%CPU的性能监控产品还应该显示PMC度量指标，解释那个值意味着什么，那样才不会误导最终用户。比如说，它们可以一并显示%CPU及IPC，以及/或指令完成周期与停滞周期。有了这些度量指标，开发人员和操作人员才能决定如何才能更好地调优应用程序和系统。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!