WEBVTT 00:00.090 --> 00:00.960 -：このレッスンでは､ 00:00.960 --> 00:02.730 パフォーマンスの問題についてお話しします｡ 00:02.730 --> 00:08.010 具体的には､ あるシステムで長期間にわたって観察されるパフォーマンスの鈍さや遅さだ｡ 00:08.010 --> 00:09.060 パフォーマンスの問題は､ 00:09.060 --> 00:18.150 コンピューター・システム内部で適切に診断するのが最も難しいもののひとつである｡ 00:18.150 --> 00:20.700 このため､ 何が問題なのかを正確に把握するのは実に難しいが､ 00:20.700 --> 00:25.931 このレッスンでは一般的なガイドラインをいくつか紹介しよう｡ 00:25.931 --> 00:28.650 さて､ パフォーマンス問題のトラブルシューティングを開始する際には､ 00:28.650 --> 00:35.370 常に構造化されたアプローチを使用し､ パフォーマンス問題を引き起こしている可能性のあるさまざまな問題をそれぞれ分類してみるべきである｡ 00:35.370 --> 00:38.947 そこで､ まずベースラインとは何かを知る必要がある｡ 00:38.947 --> 00:42.000 たとえば､ 3ギガヘルツのプロセッサー､ 16ギガバイトのラム､ 00:42.000 --> 00:44.070 1テラバイトのハードディスク､ 00:44.070 --> 00:50.520 毎秒1ギガビットのネットワーキング・カードを搭載したシステムがあるとしよう｡ 00:50.520 --> 00:54.420 しかし､ 実際にそのシステムを触ったことも見たこともなければ､ 00:54.420 --> 00:58.950 それらがどのように連動しているのかもわからない｡ 00:58.950 --> 01:00.600 だから､ 新しいシステムを導入するときは､ 01:00.600 --> 01:03.720 そのシステムと現在の運用方法を観察したいものだ｡ 01:03.720 --> 01:05.820 今あげた例のシステムを例にとると､ 最初にその真新しいシステムを手に入れたとき､ 01:05.820 --> 01:10.080 私たちは普通の感覚がどのようなものかを知っているはずだ｡ 01:10.080 --> 01:12.000 実際の動作速度は？ 01:12.000 --> 01:15.957 オペレーティング・システムだけをロードしているとき､ あるいはオペレーティング・システムとオフィス・スイートを開いているとき､ 01:15.957 --> 01:19.290 日常的にどれくらいのRAMを使用しているのだろうか？ 01:19.290 --> 01:21.390 また､ ネットワークの速度も知る必要がある｡ 01:21.390 --> 01:23.280 なぜなら､ 毎秒1ギガビットのカードがあるからといって､ 01:23.280 --> 01:27.360 毎秒1ギガビットのスループットが得られるとは限らないからだ｡ 01:27.360 --> 01:29.910 それに加えて､ ハードディスクも見なければならない｡ 01:29.910 --> 01:31.860 1テラバイトのハードドライブと言ったが､ 01:31.860 --> 01:34.290 ソリッド・ステート・ドライブだったのか？ 01:34.290 --> 01:36.726 5400RPMのハードドライブだったのか､ 7200RPMだったのか､ 01:36.726 --> 01:39.480 1万RPMだったのか｡ 01:39.480 --> 01:42.000 そして､ そのすべてが異なるパフォーマンスを持つことになる｡ 01:42.000 --> 01:44.670 さて､ 正常なパフォーマンスが分かれば､ 01:44.670 --> 01:45.630 何が不調なのか､ 01:45.630 --> 01:53.190 遅いのかを判断することができ､ トラブルシューティングに力を入れるべき領域を特定することができる｡ 01:53.190 --> 01:54.900 さて､ 観察しているパフォーマンスの低下から､ 01:54.900 --> 02:04.260 どのサブシステムが実際に問題になりそうかを特定できるようになったことに加えて､ それらのサブシステムを最適化するために設定を変更することができるようになった｡ 02:04.260 --> 02:07.110 例えば､ 平均的なユーザーが常にRAM不足に陥っていることがわかり始めたら､ 02:07.110 --> 02:15.090 8ギガバイトから16ギガバイトに､ あるいは16ギガバイトから32ギガバイトにアップグレードしたくなるかもしれない｡ 02:15.090 --> 02:19.648 繰り返すが､ これはシステムのパフォーマンスを上げるためにできる最もシンプルで簡単なことのひとつだからだ｡ 02:19.648 --> 02:22.380 しかし､ もしあなたが低速なパフォーマンスを経験していて､ 02:22.380 --> 02:23.820 空きラムを見て､ 16GBのうち8GBの空きラムがあるのなら､ 02:23.820 --> 02:33.270 32GBにアップグレードしても､ すでにあるラムをすべて使っているわけではないので､ パフォーマンスという点ではあまり意味がないだろう｡ 02:33.270 --> 02:35.153 パフォーマンス問題のトラブルシューティングでは､ 02:35.153 --> 02:37.290 このようなことを考えなければならない｡ 02:37.290 --> 02:41.430 それに加えて､ システムがオーバーヒートしていないことも確認したい｡ 02:41.430 --> 02:42.471 現代のシステムの多くは､ 02:42.471 --> 02:47.790 オーバーヒートから身を守るために､ プロセッシング・ユニットにスロットリングを搭載している｡ 02:47.790 --> 02:50.010 そのため､ システムが熱を持ち始めた場合､ 3ギガヘルツで動作するはずのプロセッサが､ 02:50.010 --> 02:57.180 実際には2ギガヘルツか1ギガヘルツにダウングレードしてしまうかもしれない｡ 02:57.180 --> 02:57.180 5ギガヘルツで熱負荷を下げ､ 02:59.430 --> 03:01.740 システムの過熱を抑える｡ 03:01.740 --> 03:03.270 というのも､ システムがオーバーヒートすると､ 再起動したり､ 03:03.270 --> 03:05.190 シャットダウンしたりする可能性があるからだ｡ 03:05.190 --> 03:12.330 そのため､ 温度センサーの多くは､ グラフィックス・プロセッシング・ユニットやセントラル・プロセッシング・ユニットなどのコンポーネントの動作速度を低下させ､ 03:12.330 --> 03:14.492 全体的な熱負荷を下げることができる｡ 03:14.492 --> 03:16.363 温度センサーに欠陥がある場合､ 03:16.363 --> 03:19.710 実際よりも温度が高いことを示す可能性があり､ 03:19.710 --> 03:23.940 そのためCPUはそれを補うために性能を下げ始める｡ 03:23.940 --> 03:25.429 だから､ このことも覚えておいてほしい｡ 03:25.429 --> 03:28.530 パフォーマンスの問題をトラブルシューティングする際に考慮すべきもう1つのことは､ 03:28.530 --> 03:30.780 設定ミスの可能性だ｡ 03:30.780 --> 03:35.970 例えば､ メモリを8ギガバイトから16ギガバイトにアップグレードしたとします｡ 03:35.970 --> 03:37.260 そうすると､ 4ギガバイトのモジュールを2つ取り出して､ 03:37.260 --> 03:41.760 新しい8ギガバイトのモジュールを2つ入れたかもしれないが､ スロット0と2ではなく､ 03:41.760 --> 03:46.320 スロット0と1に入れたことになる｡ 03:46.320 --> 03:49.440 そのため､ メモリはデュアル・チャネル・モードで動作していない｡ 03:49.440 --> 03:51.990 その代わり､ シングルチャンネルモードでしか動作しない｡ 03:51.990 --> 03:57.990 一度に128ビットではなく64ビットにしかアクセスできないため､ 03:57.990 --> 04:01.230 メモリが2倍になったにもかかわらず､ 04:01.230 --> 04:05.190 パフォーマンスが半分になってしまうのだ｡ 04:05.190 --> 04:10.530 つまり､ この種の設定ミスは､ システム全体に連鎖的な影響を及ぼす可能性があるのだ｡ 04:10.530 --> 04:15.166 また､ オペレーティング・システムやアプリケーション・ソフトウェア自体に設定ミスがある場合もある｡ 04:15.166 --> 04:17.100 例えば､ ウィンドウズのページサイズを大きくしたり､ 04:17.100 --> 04:21.240 Linuxのスワップ領域を大きくしたりする人をよく見かける｡ 04:21.240 --> 04:23.400 これでパフォーマンスが上がると思っているのだろうが､ 04:23.400 --> 04:33.000 実際は仮想メモリを増やすだけで､ 物理メモリからハードディスクやソリッドステート・デバイスへのスワップが増え､ システム全体が遅くなるのだ｡ 04:33.000 --> 04:36.390 そのため､ システムの設定を始める際には､ これらすべてを念頭に置いておく必要がある｡ 04:36.390 --> 04:39.240 そして忘れてはならないのは､ どれも単独では機能しないということだ｡ 04:39.240 --> 04:40.707 このようなパフォーマンス上の問題を抱えている場合､ 04:40.707 --> 04:45.300 無数の異なる要因が同時に働いている可能性がある｡ 04:45.300 --> 04:46.620 それはオペレーティング・システムかもしれないし､ 04:46.620 --> 04:47.850 アプリケーションかもしれないし､ 04:47.850 --> 04:49.260 コンフィギュレーションかもしれないし､ 04:49.260 --> 04:50.130 ネットワークかもしれないし､ 04:50.130 --> 04:52.050 ハードウェアかもしれない｡ 04:52.050 --> 04:53.400 そして､ すべてをサブシステムに分割して検討し､ 04:53.400 --> 05:01.233 パフォーマンス上の問題を特定することで､ これを識別できるようになることは､ 現場の技術者として非常に重要になる｡