3.2. 処理能力
CPU処理能力、CPUサイクル、その他さまざまな名前で知られている処理能力とは、 コンピュータがデータを処理する能力のことです。 処理能力はCPUのアーキテクチャ(及びクロックスピード)により異なります。— 一般的には、高速なクロックスピードのCPUや大きいワードサイズをサポートするCPUは、 小さいワードサイズをサポートする低速のCPUより処理能力に優れています。
3.2.1. 処理能力に関して
処理能力に関して注意すべき主要な事項が2つあります。
処理能力は固定です。
処理能力は蓄積できません。
処理能力は固定です。つまり、CPUは決められた速度が限度です。例えば、2つの数を足す場合(ほとんどのアーキテクチャでマシン命令が1つのみの動作)、特定のCPUは一定の速度で処理を行うことができ、その速度は固定です。例外を除けば、CPUが命令を処理する速度を速くするのは言うまでもなく遅くすることさえ不可能です。
また、処理能力は別の意味でも固定で、限りがあります。特定のコンピュータにプラグインできるCPUのタイプは限られてます。異なる速度の CPU を幅広くサポートする機能があるシステムもあれば、まったくアップグレードできないものもあります[1]
処理能力は後日に使用するため保存することはできません。 つまり、CPUが毎秒1億の命令を処理できるなら、 アイドルタイムの1秒は1億分の命令処理に値するものが浪費されていたということになります。
これらのことを理解した上で視点を変えて見てみると、CPUは一定レートで実行された命令の流れを"作り出して"います。また、CPUが実行された命令を"作り出す"なら、別の何かがそれを"消費"しなければならないことになります。次のセクションではこの消費側について述べていきます。
3.2.2. 処理能力を消費するもの
処理能力を消費するものには主として2種類あります。
アプリケーション
オペレーティングシステム自身
3.2.2.1. アプリケーション
最も処理能力を消費するのがコンピュータを作動させるためのアプリケーションとプログラムです。表計算ソフトからデータベースまで、アプリケーションあってのコンピュータです。
CPUが単一のシステムは任意の時間で1つの作業しか行うことができません。 従って、アプリケーションが実行中なら、システム上のその他すべてが実行しません。 その反対は、言うまでもなく、アプリケーション以外の何かが実行中であれば、 アプリケーションは動作しません。
しかし、最近のオペレーティングシステムでは、数多くの異なるアプリケーションが同時に実行できるように見えるのはどうしてでしょう。こうしたオペレーティングシステムがマルチタスクだからです。つまり、実際には不可能なことなのですが多くの異なるアプリケーションが同時に作動しているように幻想を作り出しているわけです。実際には、実行中の各プロセスに数分の一秒間を次々と与えています。このコンテキストスイッチが頻繁に起こると、複数アプリケーションが同時に実行しているような幻想を作り出せることになります。
もちろん、アプリケーションはCPUを使ってデータを処理するだけではありません。 ユーザーの入力待ち、ディスクドライブやグラフィック表示などのデバイスにI/Oを実行したりします。 こうしたイベントが行われると、アプリケーションはCPUを必要としなくなります。 すると、待ちアプリケーションをまったくスローダウンすることなく、 CPUは他のアプリケーションを実行している他のプロセスに使用されます。
また、CPUはオペレーティングシステム自身によっても使用されます。
3.2.2.2. オペレーティングシステム
オペレーティングシステムによって消費される処理能力がどのくらいになるかを確定するのは 難しいことになります。 これはオペレーティングシステムが作業を行うためにプロセスレベル及びシステムレベルを 混合したコードを使用しているためです。 例えば、デーモンやサービスを 実行中のプロセスが行っていることを確認するにはプロセスモニタを使用するのが簡単ですが、 システムレベルの入出力関連処理に消費されている処理能力がどのくらいになるかを確認するのは 容易なことではありません(通常、入出力を要求しているプロセスのコンテキスト内で行われる)。
一般に、この種のオペレーティングシステムのオーバーヘッドは2種類に分類することができます。
オペレーティングシステムの管理
プロセス関連のアクティビティ
オペレーティングシステムの管理にはプロセスのスケジュールやメモリ管理などのアクティビティが含まれ、 プロセス関連のアクティビティには システム全体のイベントのログや入出力キャッシュのフラッシュを処理するプロセスなど オペレーティングシステム自身をサポートするプロセスすべてが含まれます。
3.2.3. CPUの不足を改善する
必要とされる作業に十分な処理能力がない場合、2つの選択肢があります。
負荷を軽減する
容量を増やす
3.2.3.1. 負荷を軽減する
CPU負荷の軽減はまず費用をかけずに行えることです。 秘訣はシステム管理者の管理下において削減できるシステム負荷の状況を識別することです。 重点をおくべき点が3つあります。
オペレーティングシステムのオーバーヘッドを減らす
アプリケーションのオーバヘッドを減らす
アプリケーションを完全に取り除く
3.2.3.1.1. オペレーティングシステムのオーバーヘッドを減らす
オペレーティングシステムのオーバーヘッドを減らすには、現在のシステム負荷を調べ どの部分が過度のオーバーヘッドになっているのかを確定します。 次のようなことが考えられます。
頻繁なプロセススケジュールの必要性を減らす
実行される入出力の量を減らす
奇跡が起るわけではありません。適度に構築されたシステムでは、 オペレーティングシステムのオーバーヘッドを減らすことによって 大きくパフォーマンスが向上することはあまり期待できません。 定義上、適度に構築されたシステムとはオーバーヘッドが最小限であるからです。 ただし、例えばシステムがほとんどRAMがない状態で実行している場合、 RAMの不足を軽減することによりオーバーヘッドを削減することができるかもしれません。
3.2.3.1.2. アプリケーションのオーバーヘッドを減らす
アプリケーションのオーバヘッドを減らすということは、 アプリケーションが正しく実行するために必要とされるものすべてがあることを確認することです。 異なる環境下ではかなり違う動作を見せるアプリケーションがあります— 例えば、特定の種類のデータを処理しているときに限ってCPUを非常に消費するように なることがあります。
ここで注意すべきは、できる限り効率的にアプリケーションが実行されるようにする場合は システムで実行中のアプリケーションをよく理解している必要があります。 アプリケーションがより効率的に動作できるようにする方法を模索するためには ユーザーや組織の開発者と共同で作業する必要性がしばしば生じてきます。
3.2.3.1.3. アプリケーションを完全に除去する
組織や企業により、実行するアプリケーションの指定は システム管理者の責任外となることが多いためこの手段は使えないかもしれません。 ただし、"CPU への負荷がかなり大きい"とわかるアプリケーションを確認できる場合は、 それらを使用しないよう責任者に対して影響を与えることはできるかもしれません。
アプリケーションの除去は他の人にも関与する可能性があります。 影響を受けるユーザーは必ずこのプロセスに含ませる必要があります。 多くの場合、こうしたユーザーがアプリケーションの構成に必要な変更を加えるための知識と 組織上の権限を有していることがあります。
 | ヒント |
|---|---|
アプリケーションはすべてのシステムから必ず除去する必要はないかもしれませんので 注意してください。 オーバーロードしているシステムから特にCPU負荷の大きいアプリケーションを アイドル状態に近い別のシステムに移動することができることもあります。 |
3.2.3.2. 容量を増やす
もちろん、処理能力に対する要求を減らすことができない場合には、 使用できる処理能力を増やす方法を探す必要があります。 費用はかかりますが処理能力を増やすことはできます。
3.2.3.2.1. CPUのアップグレード
最も単純な方法はシステムのCPUをアップグレードできるかどうか確認することです。 まずはじめに、現在のCPUを取り除くことができるか確認します。 CPUがハンダ付けにされているためアップグレードができないシステムがあります。 ただし、これ以外のソケットにはめるCPUなら(少なくとも理論上は) アップグレードができます。
次に、システム構成に合う今より高速なCPUがあるかどうか調べる必要があります。 例えば、現在1GHz CPUで同じ種類の2GHzユニットがあるなら、 アップグレードができる可能性があります。
最後に、最大クロック速度をシステムがサポートしているか確認する必要があります。 前述の例を行うには、適当な種類の2GHz CPUがあっても、 システムが1GHz以下で動作するプロセッサしかサポートしない場合は CPUを単純に交換する方法は行えません。
システムには今より高速のCPUをインストールできないと判明した場合、 マザーボードの交換あるいは前述のようにさらに費用のかかるアップグレードに 限定されてしまうかもしれません。
ただし、若干異なる手段がとれるシステム構成もあります。 現在のCPUを交換するのではなく、単にもう1つCPUを足してみてはどうでしょうか。
3.2.3.2.2. SMPを選択するにあたって
対称型マルチプロセッシング(SMPとも呼ばれる)で すべてのシステムリソースを共有する複数のCPUをコンピュータシステムに持たせることが 可能になります。 つまり、ユニプロセッサのシステムと異なり、 SMPシステムは同時に作動する複数のプロセッサを実際に搭載することができます。
一見したところでは、すべてのシステム管理者の夢ように見えます。 第一に、高速なクロック速度のCPUがない場合であってもSMPならシステムの CPU処理能力を増強することが可能になります—もうひとつCPUを足せばいいわけです。 ただし、こうした柔軟性にはいくつか注意を要します。
最初に注意したいのはすべてのシステムがSMP作動できるわけではないことです。複数のプロセッサをサポートするようデザインされているマザーボードが必要です。サポートされていない場合は、(少なくとも)マザーボードのアップグレードが要されます。
次に注意すべきことは、SMP によってシステムのオーバーヘッドが増えることです。 これが要因で SMP をあきらめてしまうのも理解できます。 多くの CPU が作業を行うようスケジュールすれば、オペレーティングシステムはオーバーヘッドにより多くの CPU サイクルを必要とするからです。 また、複数の CPU では、システムリソースの競合が増える可能性があります。 こうしたことから、デュアルプロセッサシステムを 4 プロセッサユニットにアップグレードするのは利用できる CPU 処理能力において 100% の増加にはならないことになります。 実際、ハードウェアそのものや、ワークロード、プロセッサのアーキテクチャにより、別のプロセッサを追加することにより実際にはシステムのパフォーマンスを低下させることになりかねないこともあります。
また、シングルストリームで実行する単一モノリシックアプリケーションから成る作業負荷には SMP は役に立たないので注意してください。 つまり、CPU の消費が激しい 1 つの大きなシミュレーションプログラムがスレッドなしの 1 つのプロセスとして作動すると、 SMPシステムでの作動は単一プロセッサのマシンでの作動より速くはなりません。 実際には、SMP によるオーバーヘッドが増えるために動作が遅くなることさえあります。 こうした理由から、システム管理者の多くはCPU 処理能力に問題を感じた場合、 シングルストリームの処理能力を選択します。 これを使用するともっとも少ない制限で最大限の CPU 能力を提供します。
ここでは SMP がよい選択とは言えないことが解説されていますが、役に立つ状況もあります。 例えば、CPUの消費が非常に激しい複数のアプリケーションを稼働している環境は SMP を採用する対象となります。 その理由は、実行時間のほとんどが計算処理となるアプリケーションのアクティブなプロセス間での競合(したがって、オペレーティングシステムのオーバーヘッドとなる)を最小限に抑え、一方でプロセス自身がすべての CPU を活発に使用するようにします。
SMPに関してもう1つ注意しておきたいことは、SMP システムのパフォーマンスはシステム負荷の増加にともないより適切な低均化を行う傾向にあります。変わり続けるプロセスの混入がマルチプロセッサマシンでシステム全体の負荷を少なくすることができるため、SMP システムがサーバー及びマルチユーザー環境において一般的となっています。