-：このレッスンでは､
パフォーマンスの問題についてお話しします｡
具体的には､ あるシステムで長期間にわたって観察されるパフォーマンスの鈍さや遅さだ｡
パフォーマンスの問題は､
コンピューター・システム内部で適切に診断するのが最も難しいもののひとつである｡
このため､ 何が問題なのかを正確に把握するのは実に難しいが､
このレッスンでは一般的なガイドラインをいくつか紹介しよう｡
さて､ パフォーマンス問題のトラブルシューティングを開始する際には､
常に構造化されたアプローチを使用し､ パフォーマンス問題を引き起こしている可能性のあるさまざまな問題をそれぞれ分類してみるべきである｡
そこで､ まずベースラインとは何かを知る必要がある｡
たとえば､ 3ギガヘルツのプロセッサー､ 16ギガバイトのラム､
1テラバイトのハードディスク､
毎秒1ギガビットのネットワーキング・カードを搭載したシステムがあるとしよう｡
しかし､ 実際にそのシステムを触ったことも見たこともなければ､
それらがどのように連動しているのかもわからない｡
だから､ 新しいシステムを導入するときは､
そのシステムと現在の運用方法を観察したいものだ｡
今あげた例のシステムを例にとると､ 最初にその真新しいシステムを手に入れたとき､
私たちは普通の感覚がどのようなものかを知っているはずだ｡
実際の動作速度は？
オペレーティング・システムだけをロードしているとき､ あるいはオペレーティング・システムとオフィス・スイートを開いているとき､
日常的にどれくらいのRAMを使用しているのだろうか？
また､ ネットワークの速度も知る必要がある｡
なぜなら､ 毎秒1ギガビットのカードがあるからといって､
毎秒1ギガビットのスループットが得られるとは限らないからだ｡
それに加えて､ ハードディスクも見なければならない｡
1テラバイトのハードドライブと言ったが､
ソリッド・ステート・ドライブだったのか？
5400RPMのハードドライブだったのか､ 7200RPMだったのか､
1万RPMだったのか｡
そして､ そのすべてが異なるパフォーマンスを持つことになる｡
さて､ 正常なパフォーマンスが分かれば､
何が不調なのか､
遅いのかを判断することができ､ トラブルシューティングに力を入れるべき領域を特定することができる｡
さて､ 観察しているパフォーマンスの低下から､
どのサブシステムが実際に問題になりそうかを特定できるようになったことに加えて､ それらのサブシステムを最適化するために設定を変更することができるようになった｡
例えば､ 平均的なユーザーが常にRAM不足に陥っていることがわかり始めたら､
8ギガバイトから16ギガバイトに､ あるいは16ギガバイトから32ギガバイトにアップグレードしたくなるかもしれない｡
繰り返すが､ これはシステムのパフォーマンスを上げるためにできる最もシンプルで簡単なことのひとつだからだ｡
しかし､ もしあなたが低速なパフォーマンスを経験していて､
空きラムを見て､ 16GBのうち8GBの空きラムがあるのなら､
32GBにアップグレードしても､ すでにあるラムをすべて使っているわけではないので､ パフォーマンスという点ではあまり意味がないだろう｡
パフォーマンス問題のトラブルシューティングでは､
このようなことを考えなければならない｡
それに加えて､ システムがオーバーヒートしていないことも確認したい｡
現代のシステムの多くは､
オーバーヒートから身を守るために､ プロセッシング・ユニットにスロットリングを搭載している｡
そのため､ システムが熱を持ち始めた場合､ 3ギガヘルツで動作するはずのプロセッサが､
実際には2ギガヘルツか1ギガヘルツにダウングレードしてしまうかもしれない｡
5ギガヘルツで熱負荷を下げ､
システムの過熱を抑える｡
というのも､ システムがオーバーヒートすると､ 再起動したり､
シャットダウンしたりする可能性があるからだ｡
そのため､ 温度センサーの多くは､ グラフィックス・プロセッシング・ユニットやセントラル・プロセッシング・ユニットなどのコンポーネントの動作速度を低下させ､
全体的な熱負荷を下げることができる｡
温度センサーに欠陥がある場合､
実際よりも温度が高いことを示す可能性があり､
そのためCPUはそれを補うために性能を下げ始める｡
だから､ このことも覚えておいてほしい｡
パフォーマンスの問題をトラブルシューティングする際に考慮すべきもう1つのことは､
設定ミスの可能性だ｡
例えば､ メモリを8ギガバイトから16ギガバイトにアップグレードしたとします｡
そうすると､ 4ギガバイトのモジュールを2つ取り出して､
新しい8ギガバイトのモジュールを2つ入れたかもしれないが､ スロット0と2ではなく､
スロット0と1に入れたことになる｡
そのため､ メモリはデュアル・チャネル・モードで動作していない｡
その代わり､ シングルチャンネルモードでしか動作しない｡
一度に128ビットではなく64ビットにしかアクセスできないため､
メモリが2倍になったにもかかわらず､
パフォーマンスが半分になってしまうのだ｡
つまり､ この種の設定ミスは､ システム全体に連鎖的な影響を及ぼす可能性があるのだ｡
また､ オペレーティング・システムやアプリケーション・ソフトウェア自体に設定ミスがある場合もある｡
例えば､ ウィンドウズのページサイズを大きくしたり､
Linuxのスワップ領域を大きくしたりする人をよく見かける｡
これでパフォーマンスが上がると思っているのだろうが､
実際は仮想メモリを増やすだけで､ 物理メモリからハードディスクやソリッドステート・デバイスへのスワップが増え､ システム全体が遅くなるのだ｡
そのため､ システムの設定を始める際には､ これらすべてを念頭に置いておく必要がある｡
そして忘れてはならないのは､ どれも単独では機能しないということだ｡
このようなパフォーマンス上の問題を抱えている場合､
無数の異なる要因が同時に働いている可能性がある｡
それはオペレーティング・システムかもしれないし､
アプリケーションかもしれないし､
コンフィギュレーションかもしれないし､
ネットワークかもしれないし､
ハードウェアかもしれない｡
そして､ すべてをサブシステムに分割して検討し､
パフォーマンス上の問題を特定することで､ これを識別できるようになることは､ 現場の技術者として非常に重要になる｡