この記事は、インテル® ソフトウェア・ネットワークに掲載されている「Hyper-Threading: Be Sure You Know How to Correctly Measure Your Server’s End-User Response Time」(http://software.intel.com/en-us/articles/hyper-threading-be-sure-you-know-how-to-correctly-measure-your-servers-end-user-response-time-1/) の日本語参考訳です。
はじめに
最近、独立系ソフトウェア・ベンダー (ISV) からある問題がインテルへ寄せられました。テスト測定において、インテル® Xeon® プロセッサー上でハイパースレッディング (HT) [1] を有効にした場合、Web サーバーシステムの応答時間が増加したというのです。簡単な解析を行ったところ、HT が有効な場合、実際にはユーザーの応答時間は短縮していることが分かりました。原因は、ISV による応答時間の測定方法にありました。
ここでは、混乱を引き起こした原因とその回避方法について説明します。
背景情報
まず、簡略化されたサーバーシステムについて見てみましょう。待機キューとハードウェア CPU ごとに作業プロセスがあります。クライアントのトランザクションは、サーバーに入り、キューで待機し、作業プロセスで必要な処理を行う間留まって、そしてクライアントにデータを返します。エンドユーザーから見たサーバーの応答時間は、サーバーが待機キューに作業を追加してから、作業プロセスがクライアントのトランザクションを完了する時点までです。
作業プロセスだけを分離してテストする場合、ISV が次の 2 つの測定値に注目するのは当然といえるでしょう。
(a) プロセスの CPU 時間
(b) プロセスがクライアントのトランザクション処理を完了するのにかかったウォールクロック時間 (作業プロセスの逗留時間)
ISV では、作業プロセスの逗留時間の増加はすべて、直接エンドユーザーから見た応答時間の増加につながると仮定していました。
一般に、HT が有効な場合と無効な場合のパフォーマンスを比較する際に、この 2 つの測定値は誤解されやすいものです。HT はシステムの全体的なスループットを向上させますが、通常のパフォーマンス測定では、解釈が困難になります。
簡単な例
CPU 処理能力を最大限に活用した場合、1 秒あたり 1 件のトランザクションを処理できるシングル CPU と作業プロセスについて考えてみましょう。平均応答時間が 4 秒になるように、複数のユーザーがシステムにアクセスします。各ユーザーには、思考時間として 10 秒が与えられます。クローズドループ・システムの標準的なキューイング理論/負荷方程式 [2] から、平均応答時間を 4 秒と想定するとシステムにアクセスするユーザー数は 14 でなければならないことが分かります。
ここで R は応答時間、N はユーザー数、 X はスループット、Z はユーザーの思考時間です。サーバーの応答時間は、さらに 2 つのコンポーネントに分けられます: R = Q + C。ここで Q は待機キューで待機した時間、C はジョブが作業プロセスに逗留した時間です。X <= 1/C になることは明らかで、作業プロセスがアイドル状態にならない場合のみ等しくなります。
この状況をサーバー側から見ると、1 秒あたり 1 件のトランザクションを処理するには CPU が 100% ビジーでなければなりません。トランザクション 1 件あたりの CPU 時間は 1 秒です。作業プロセスの逗留時間は 1 秒で、平均キュー時間は 3 秒です。常に 1 人のユーザーが作業プロセスにおり、別の 3 人のユーザーがキューで待機していることになります。
HT を有効にしてみましょう。ここでの変更点は、両方の論理 CPU が作業プロセスを持つように、別の作業プロセスを追加するだけです。HT を有効にしても利点が得られないと仮定してみます。つまり、スループットが HT が無効の場合と同じであると仮定します。
サーバー側から見ると、トランザクション 1 件あたりの CPU 時間は 2 秒になります。CPU がアクティブな時間は 2 倍となり、スレッドごとに 2 秒となります。全体的な平均スループットは変わらず、1 秒あたり 1 トランザクションのままです (同時に 2 つのトランザクションが実行され、2 秒で完了します)。作業プロセスの逗留時間は 2 秒に増え、平均キュー時間は 2 秒になります。常に 2 人のユーザーが 2 つの作業プロセスで何らかの処理を行っており、別の 2 人のユーザーがキューで待機していることになります。
これこそが混乱の原因です。HT が無効な場合の CPU 時間は 1 秒であるのに対し、HT が有効な場合の CPU 時間は 2 秒になります。作業プロセスの逗留時間は、HT が無効な場合は 1 秒、HT が有効な場合は 2 秒になります。
どうしてこのようになったのでしょうか? 基本的には、クライアント側から見ると何の違いもありません。クライアントから見たサーバーの応答時間、サーバーのスループット、サポートされるクライアント数などに変更はありません。HT を有効にすることで得られる利点はないと考えられたため、これは我々の想定どおりの結果です。サーバー側では、キューでの待機時間が減り、その分 CPU での実行時間が増えました。
サーバーの作業プロセスにあるプログラムで、作業プロセスがそれぞれのジョブを開始し、完了したときに、ウォールクロック・タイマーを開始し、停止する場合 (つまり、作業プロセスの逗留時間を測定する場合)、この “応答時間” は (最大で 2 倍に) 増加する可能性が高いでしょう。ただし、この応答時間はエンドユーザーから見た応答時間ではありません。
HT が有効なサーバーはそれぞれ半分のスループットで動作する 2 つのサーバーのようなもの
HT を有効にすることは影響を別の観点から見ると、1 つのサーバーシステムが 2 つのサーバーになると考えられます。HT を有効にすることで得られる利点がなくても、サーバーが 2 つになり、それぞれのスループットが元のサーバーの半分になります。ただし、これは極端に単純化した見方です。HT が有効なシステムは、与えられる負荷に適応します。
HT を有効にすることで、サーバーの CPU 時間や作業プロセスの逗留時間が必ずしも増加するとは限りません。サーバーシステムに対して同時に複数の要求があった場合のみ、HT は両方の論理プロセッサーに別々の要求を処理させます。
テストシステムでは、CPU が 100% ビジー状態を維持し、サーバーでキューイングが発生しないように負荷を調整してみます (ユーザー数を 14 から 11 に減らします)。利用可能なジョブは常に 1 つのみになるので、HT は常に 1 つの論理プロセッサー上の 1 つの作業プロセスだけを使用します。CPU 時間、作業プロセスの逗留時間、エンドユーザーの応答時間は、HT が無効な場合と同じで 1 秒になります。
HT はシステムのスループットを向上してエンドユーザーの応答時間を短縮する
HT を有効にすることで、プロセッサー・コアは、同じ OS タイムスライス内で同時に 2 つのオペレーティング・システム (OS) スレッドの命令を処理することができます。これにより、同じシステムのスループット (1 秒あたりのトランザクション件数) が向上します。前述の負荷方程式によると、スループットが向上することでエンドユーザーの応答時間が短縮されます。
前述の例では HT を有効にしても利点が得られませんでしたが、仮に HT を有効にしたら、各論理プロセッサーで 1 件のトランザクションの処理にかかる時間がベースラインの 2 秒ではなく 1.66=5/3 CPU 秒になったとします。
その場合、システムをビジー状態にするのに必要なユーザー数を 14 と仮定すると、システムは 1 秒あたり 2/1.66 = 6/5 トランザクションを処理できます。負荷方程式を使用して確認したところ、R = 5/3 となり (つまり、Q=0 であり)、妥当なトランザクション･レートであることが分かりました。
HT を有効にすることで、スループットが 1 秒あたり 1 トランザクションから 6/5 トランザクションになり、1.2 倍向上します。これは、実際に多くのアプリケーションで測定された HT により見込まれる向上の範囲内です。— ここで使用した例では、応答時間が 4 秒から 1.66 秒に短縮されました。
しかし、作業プロセスの逗留時間により「応答時間」を測定すると、HT を有効にすることで「応答時間」が 1.0 秒から 1.66 秒に増えたことになってしまいます。
まとめ
応答時間を測定する場合は、サーバーの作業プロセスではなく、次の観点から測定する必要があります。
- クライアントの実際の応答時間の平均
- キューでの待機時間を含む、各トランザクションがサーバーで実際に費やした時間
- 負荷方程式を使用して計算された応答時間
実際には、テスト結果を確認するためにも、これら 3 つをそれぞれ測定すると良いでしょう。
ここでは、皆さんに注意を促すために ISV から寄せられた問題を紹介しました。適切でない測定方法のせいで、「HT はエンドユーザーに利益をもたらさない」と誤解しないようにしてください。
著者紹介
Stephen P. Smith 博士は、インテル製ハードウェア上で業界の各種ソフトウェアが最適に実行されるように、インテルで ISV エコシステムに取り組んでいるコンピューター科学者です。過去には、インテルの工場でプラニングおよびスケジューリングのオートメーション・グループを指揮したり、Northrop 社の研究技術センターの主任研究員としての経歴があります。趣味は、SF および推理小説の読書とバレーボールです。
参考文献
[1] Hyper-Threading Technology Architecture and Microarchitecture, D. Marr et al., Intel Technology Journal, Volume 06, Issue 01 2002/02/14.http://www.intel.com/technology/itj/archive/2002.htm [2] P.J. Denning and J.P. Buzen, “The operational analysis of queueing network models,” ACM Computing Surveys, 10:225–262, 1978.
http://cne.gmu.edu/pjd/PUBS/csurv-opanal.pdf
コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。
