CPU使用率メト​​リクスを分析！

そうです、私がここで話しているのは、あらゆるパフォーマンス監視製品で、誰もがどこでも使用している「%CPU」メトリクスです。これを表示するには、top(1) コマンドを使用します。
CPU 使用率が 90% ということは次のことを意味すると思うかもしれません:

そして実際には次のような意味になるかもしれません:

ストールとは、通常、プロセッサがメモリの入出力を待機しているために、プロセッサが命令の処理を進めていないことを意味します。上で描いた比率 (ビジーとスタックの比率) は、実際の運用環境でよく見られるものです。基本的に行き詰まっていて、それに気づいていない可能性があります。

これはあなたにとって何を意味しますか? CPU のどの程度が停止しているかを把握すると、コードの削減とメモリ I/O の削減の間でパフォーマンス チューニングの取り組みを進めることができます。 CPU のパフォーマンスを懸念している人、特に CPU に基づいてリソースを自動的にスケーリングするクラウドにおいて、%CPU がどこで停止しているかを知ることは有益です。

CPU 使用率と呼ばれる尺度は、実際には「非アイドル時間」、つまり CPU がアイドル スレッドを実行していない時間です。オペレーティング システムのカーネル (それが何であれ) は通常、コンテキストの切り替え中にこのメトリックを追跡します。アイドル状態ではないプロセスが実行を開始して 100 ミリ秒間停止した場合でも、カーネルは CPU がその期間全体にわたって使用されているとみなします。

この指標はタイムシェアリング システムと同じくらい古いものです。先駆的なタイムシェアリング システムであるアポロ月着陸船誘導コンピューターは、そのアイドル スレッドを「ダミー ジョブ」と呼びました。エンジニアは、コンピューターの尺度として、アイドル スレッドの実行にかかるサイクルと実際のタスクの実行にかかるサイクルを追跡しました。使用状況を示す重要な指標。

現在、CPU はメイン メモリよりもはるかに高速になっており、待機中のメモリは依然として「CPU 使用率」と呼ばれるものの大部分を占めています。高い %CPU 数値が表示された場合、プロセッサ (つまり、ヒートシンクとファンの下にある CPU パッケージ) がボトルネックであると考えるかもしれませんが、実際には DRAM モジュールがボトルネックです。

この点に関する状況はますます深刻になっています。長い間、プロセッサ メーカーは DRAM のアクセス遅延よりもクロック速度の高速化を行ってきました。これがいわゆる「CPU DRAM ギャップ」です。この状況は 3 GHz プロセッサが導入された 2005 年頃に安定しました。それ以来、プロセッサはパフォーマンスを向上させるためにより多くのコアとハイパースレッディングを使用し、そのすべてがメモリ サブシステム要件に対してより高い要求を課すようになりました。プロセッサ メーカーは、より大規模で高性能な CPU キャッシュと、より高速なメモリ バスおよび相互接続テクノロジを使用して、このメモリのボトルネックを軽減しようとしています。しかし、私たちは依然として全般的に行き詰まっています。

パフォーマンス監視カウンター (PMC) を使用することもできます。これは、Linux perf およびその他のツールを使用して読み取ることができるハードウェア カウンターです。たとえば、システム全体を 10 秒間測定します:

ここで重要な指標はサイクルあたりの命令数 (つまり IPC) であり、CPU クロック サイクルあたり平均で完了する命令の数を示します。簡単に言えば、値が高いほど良いことになります。上の例の 0.78 は良いように思えます (時間の 78% でビジー状態) が、プロセッサーの最高速度が 4.0 であることを理解すると、そうではありません。これは 4 ワイドとも呼ばれ、命令フェッチ/デコード パスを指します。これは、CPU がクロック サイクルごとに 4 つの命令をリタイア (完了) できることを意味します。したがって、4 ワイド システムでの IPC が 0.78 ということは、CPU が最大速度の 19.5% で動作していることを意味します。新しい Intel Skylake プロセッサは 5 ワイドです。

さらに詳しく調べるために使用できる PMC はさらに数百あり、さまざまなタイプごとに停滞期を直接測定できます。

如果你在虚拟环境中，可能无法访问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使用率具有误导性的不仅仅是内存停滞周期。其他因素包括如下：

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

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

以上がCPU使用率メト​​リクスを分析！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。