SQL Server 2000 オフィシャル マニュアル

第 6 章 ‐ キャパシティ計画

「Microsoft SQL Server 2000 オフィシャルマニュアル 上」 (発行 : 日経 BP 社) より抜粋

キャパシティ計画では、システムに必要なリソースを調べ、それらのリソースの生産性を最大化する方法を決定します。また、将来のハードウェアとソフトウェアの追加をスムーズに行えるようにし、そのコストを下げるために、ネットワークの成長を考慮に入れた計画を行います。この章では、システムを作成するうえでのこの重要な作業の基本事項について説明します。

目次

6.1 キャパシティ計画の種類
6.2 キャパシティ計画の歴史
6.3 トランザクション処理
6.4 キャパシティ計画の原則
6.5 メモリのキャパシティ計画
6.6 プロセッサのキャパシティ計画
6.7 ディスクサブシステムのキャパシティ計画
6.8 ネットワークのキャパシティ計画
6.9 収集するデータの選択
6.10 まとめ

6.1 キャパシティ計画の種類

キャパシティ計画には、事前キャパシティ計画と事後キャパシティ計画の 2 つの形式があります。「事前キャパシティ計画」、または「サイジング」では、指定された期間内に、サービスレベル契約 (SLA) に定められている作業負荷を処理するために必要なハードウェア要件を予測します。SLA は、特定の機能の応答時間 (活動またはトランザクションが完了するまでにかかる時間) が維持されることを保証するために作られます。

注意 :
SLA とは、対象のシステムに関与しているすべての組織が合意した、システムの高いパフォーマンスとスムーズな運用を保証するために作られる動作条件です。たとえば、SLA は、システムがクエリに対して一定の応答時間を達成できることを保証するために作成されます。この応答時間は、ユーザー、運用グループ、アプリケーショングループ、およびパフォーマンスグループによって合意されます。

また、これらの活動の応答時間を、平常時と負荷のピーク時の両方で維持するために、一定量の予約キャパシティ (余剰分の CPU 処理パワー、ディスクドライブの空き領域、または使用可能なメモリ) を確保する必要があります。事前キャパシティ計画では、システムがまだ動いていないため、実際のパフォーマンスデータを使用することはできません。したがって、ほかの情報を利用する必要があります。結果は、この情報の精度に依存します。たとえば、システムを設計しているデータベースグループは、データベースのレイアウトと初期サイズに関する詳細を提供することができます。アプリケーションと、アプリケーションに関連する各種のクエリを設計しているアプリケーショングループは、これらのクエリがシステムリソースをどのように使用するかという点に関する情報を提供することができます。管理グループは、同時ユーザーの数と、これらのユーザーがシステムに対して発行するクエリの数に関する情報を持っています。これらすべての情報から、作業負荷やデータベースサイズなどの詳細を知り、そこから必要な CPU の数やディスクドライブの数を推測することができます。

「事後キャパシティ計画」、または「予測分析」は、既にセットアップされ、実行されているシステム上での、ハードウェアおよびソフトウェアリソースの消費量を継続的に調査する複雑な作業です。事後キャパシティ計画により、システムリソースの観点から、作業負荷の増大に対して適切な準備を行うことができます。これらの調査は、主にデータベース管理者 (DBA) のためのデータを提供するために行われます。データベース管理者は、このデータを、SLA に定義されているシステムパフォーマンスのレベルを維持するためのシステム変更の裏づけとして使用します。この章では、事後キャパシティ計画と事前キャパシティ計画の2種類のキャパシティ計画について説明し、それらの類似点と違いを示します。

典型的な事後キャパシティ計画のシナリオでは、データベースに格納されているパフォーマンスデータの履歴を使って分析を行います。この分析により、CPU の使用量 (CPU が観察期間中にビジーだった時間) 、ディスクの使用量、メモリの使用量、およびネットワークの使用量の正常な成長における傾向を予測することができます。また、システムに新しいユーザーが追加されたことから生じる、CPU、ディスク、およびメモリの使用量の急激な増加を予測することもできます。これらの調査はきわめて細かいレベルで行うことができ、特定のユーザーの活動のプロファイリングを行って、ユーザーの追加から引き起こされるシステムの使用量の増大を予測するために使うことができます。

事後キャパシティ計画の調査は、予測分析に加えて、作業負荷の「what if」シナリオを予測する能力を含む、その他のきわめて有用な機能を提供します。各種のユーザーがどのようにリソースを使用するかという点に関するデータを基に、システムの作業負荷のシナリオに特定の種類のユーザー (たとえば経理部員) を追加して、どのような種類のリソース消費が行われるかを細かく予測することができます。この予測分析により、システム管理者は、システムに新しいユーザーが追加される前に、十分な余裕を見て必要なハードウェアを入手し、システムのパフォーマンスや応答時間の低下を避けることができます。

事後キャパシティ計画の調査では、チューニング情報も得ることができます。パフォーマンスデータの履歴から、クエリを処理するディスクアレイに対するディスク I/O 情報などのチューニング情報を導き出し、パフォーマンスを高めるために必要なシステム設定の変更を決定することができます。この情報から、ある特定のディスクアレイの活動がほかのアレイと比べて多すぎるというような、パフォーマンスのボトルネックを知ることができます。たとえば、ユーザーを追加すると、データベーステーブルへのアクセスが増えます。この場合には、ユーザーがアクセスするテーブルの数とアクセス頻度を監視し、追跡することができます。この情報は、これらのテーブルの一部を再配置することで、ディスクサブシステムにボトルネックが生じるのを防げるかどうかを判断するために使えます。

6.2 キャパシティ計画の歴史

マルチユーザーコンピュータの初期のころには、キャパシティ計画とパフォーマンスの概念は広く理解も開発もされていませんでした。1970 年代初頭までのサイジングプロジェクトでは、単にターゲットのアプリケーションと「似ている」アプリケーションを実行している顧客を探すということしか行われませんでした。そのような顧客を見つけるのは難しく、異なる企業または組織とそのアプリケーションの使い方を一致させるのはさらに困難でした。

1970 年代中ごろになると、顧客とアプリケーション開発者は、特定のベンチマークまたは作業負荷テストを実行して、マシンの最適な初期サイズを推測するという分析方法を開発しました。彼らは、対象となるアプリケーションに似たアプリケーションを構築し、それを似たようなハードウェア上で実行して、パフォーマンスの統計データを収集しました。その後、これらの統計データを使って、顧客のニーズを満たす最適なサイズのマシンを決定しました。また、この方法では、ベンチマークで「what if」シナリオを実行し、システムにユーザー、アプリケーションプロセス、またはデータが追加された場合に、どのようなサイズのマシンが必要となるかを決定することも可能になりました。この方法には、高いコストがかかるという欠点がありました。これらの初期のベンチマークは、もともとは顧客の作業パターンをシミュレートするために開発されたものですが、やがてシステムベンダによって、システムを販売し、競合するハードウェア製品の相対的なパフォーマンスを比較するためのマーケティングツールとして使われることが多くなりました。

この時期、アナリストたちは既存のシステムの使用量を予測するための手法を開発しようとしていました。一見、この手法はそれほど困難なものには思えなかったのですが、実際には、テスト済みの方法論が存在せず、必要なデータを収集するためのツールもないために、かなり難しいことが判明しました。キャパシティ計画の父である Jeffrey Buzen 博士らのコンピュータ科学者たちは、依然として使用量に関する理論を開発し、これらの計算を実行する方法を研究しているところでした。

1980 年代には、初期のベンチマークシミュレーションが進化して、ST1 ベンチマーク、TP1 ベンチマーク、および Debit/Credit ベンチマークなどの標準ベンチマークが作られましたが、システムのサイジングと保守に使用できる標準的なアプリケーション作業負荷を生成することよりも、宣伝用に、最高のパフォーマンスを持つハードウェアを探すことに重点が置かれていました。それぞれ異なる状況に置かれている顧客たちは、依然としてこれらのベンチマーク結果をシステムハードウェアの比較には使用できませんでした。その後、顧客からの要請を受けて、トランザクション処理性能評議会 (Transaction Processing Performance Council:TPC) というコンピュータ業界団体が創設されました。この評議会は、45 社以上のハードウェアおよびソフトウェアメーカーのための標準化されたトランザクション負荷を定めました。これらのベンチマークは、ハードウェアとデータベースソフトウェアの相対的な能力を示すために使われることがありましたが、残念なことにアプリケーションの作業負荷のサイジングには有効ではありませんでした。

注意 :
TPC のベンチマークがサイジングに有効でなかったのは、現実の作業負荷を反映していなかったためです。一般にこれらのベンチマークは、特定の瞬間にどれだけのトランザクションがシステムを通っているかといったパフォーマンスを示すことを目的に設計されていました。これらのトランザクションは短時間で完了し、実際の作業をほとんど実行しないものだったため、きわめて大量のトランザクションを処理することが可能でした。この処理済みトランザクションの数の大きな値は、ベンチマークが実行されているシステムがきわめて強力であるという印象を与えますが、実際には作業負荷の設計のされ方のせいでそう見えただけだったのです。

この時期、クライアント/サーバーコンピューティングとリレーショナルデータベーステクノロジの使用が成熟期を迎えつつあり、システムの初期サイズの予測とキャパシティ計画の必要性が高まってきていました。今日のアプリケーションの大部分は、クライアント/サーバーアーキテクチャに基づいて作られています。サーバーは通常は中央のデータ記憶装置として使用され、ユーザーインターフェイスは通常はデスクトップマシン上でローカルに、またはリモート Web サイト上で実行されます。このように、高価なサーバーの処理パワーを効率的に使うための戦略では、顧客が既に慣れ親しんでいる GUI が使用されます。データベースアプリケーションを実行するサーバーの使用率が高くなった現在では、これらのサーバーは大部分のサイジングプロジェクトやキャパシティ計画の焦点となっています。

今日に至っても、アプリケーションの作業負荷シミュレーションベンチマークは、サーバーのサイジングに使われる最も一般的な手法であり続けています。また、パフォーマンスデータの履歴の収集と、このデータに対するキャパシティ計画テクニックの使用は、依然としてマシンの将来のキャパシティを予測するための最も精度の高い手段です。この方法は高価で時間のかかるものですが、サーバーの使用量を正確にシミュレートすれば、かなりの精度を得ることができます。ただし、大規模なプロジェクトでは、顧客またはベンダが数 100 万ドルの投資をしなければならないため、テストのためにこの種のシステムを構築できるのは、通常は大規模な顧客に限られます。このため、小規模から平均サイズのシステムで、詳細かつ高精度なシステムのサイジングとキャパシティ計画を実行できるような手法が必要となります。さいわいなことに、この種のシステムについては、いくつかの簡単な計算式とシステムの使用量に関する一般的な知識を使うだけで、サイジングと使用量を 90 % の精度で予測することができます。

6.3 トランザクション処理

この節では、データベースサーバーの CPU、メモリ、およびディスクの使用量の傾向を分析して、特定のアプリケーションに適したシステムを選択する方法について説明します。データベースサーバーはデータベース機能のみを実行します。したがって、作業負荷という点では、サーバーはトランザクションしか実行しません。SELECT または UPDATE ステートメントが実行されると、データベースサーバーはステートメントを一連の読み取りおよび書き込み操作として解釈します。実際、任意のトランザクションは、データベース読み取りと書き込みに分けることができます。この原子的なレベルでは、データベースサーバーは I/O を処理しています。したがって、トランザクションの種類および量と、これらのトランザクションが生成する I/O の両方に対応できるシステムを選択する必要があります。トランザクションの主な種類には、オンライントランザクション処理 (OLTP) と意思決定支援システム (DSS) の 2 つがあります。

6.3.1 OLTP トランザクション

OLTP トランザクションは、データベースをリアルタイムで、またはオンラインモードで使用し、通常は短時間で実行されることが予想される作業負荷の単位です。言い換えると、これらのトランザクションは、最新の情報を基に、

次のユーザーが最新の情報を得られるようにデータベースを更新し続けます。たとえば、商品発注システムでは、在庫に関するすべての情報がディスクシステム内に分散されており、そのデータベースはオンライン状態にあります。任意のユーザーがデータベース情報にアクセスできます。Item_Table や Stock_Level_Table などのデータベーステーブルは、販売されている品目の種類と数量に関する最新の情報を含んでいます。このため、特定の品目を特定の数量だけ注文する発注があった場合には、データベーステーブルにアクセスして、その品目が販売中かどうか、また必要な数量があるかどうかを確認して、在庫数を上回る数量を販売してしまうのを防ぐことができます。

このようなトランザクション処理システムの典型的なサイジングシナリオでは、インタビューによって具体的な情報を収集します。このインタビューは、データベース設計者、アプリケーション設計者、および経営陣の代表者などを対象に行います。これらの人々は、処理しなければならないトランザクションの数の予想値、トランザクションの処理が行われる 1 日のうちの時間帯 (たとえば、営業日の 8 時間の間に 25,000 件のトランザクションを処理しなければならない、など) 、同時ユーザーの数、そしてピーク使用時間 (ピーク時) 、すなわち処理が行われる日のうちの、システムに最も負荷がかかる時間帯などに関する意見とフィードバックを提供することができます。このインタビューは、おそらくサイジングにおける最も重要な要素です。

注意 :
OLTP システムを設計するときには、ピーク時に対応できるだけのトランザクション処理のキャパシティを持つハードウェアを選択してください。これにより、自動的に最悪のケースのシナリオに対応することができます。

ワンポイント　現金自動預払機 (ATM)
現金自動預払機 (ATM) システムの例を考えてみましょう。全国に支店を持つ銀行に、シカゴ支店のための ATM システムを設計するために雇われたとします。インタビューの過程で、ATM ネットワークのピーク時は、午前 11 時から午後 2 時までであることがわかりました。これは、ほとんどの人が昼食をとる時間帯と合致しています。この情報を基に、このピーク時に対応できるキャパシティを持つトランザクション処理システムを選択することができます。

6.3.2 DSS トランザクション

もう 1 種類のトランザクションシステムは DSS です。DSS トランザクションでは、大量の情報が返され、OLTP トランザクションよりもはるかに長い処理時間がかかります。DSS トランザクションは、処理に数時間、あるいは数日かかることがあります。DSS システムの例としては、更新が行われるときを除けば、データベースへの書き込みがほとんど行われない在庫管理システムが考えられます。この種のシステムは、通常は経営陣に対して、重要な意思決定の基盤となる情報を提供します。たとえば、事業の成長や、手持ち在庫レベルなどに関する意思決定です。別の例として、米国空軍は、ジェット戦闘機、爆撃機、および隊員の最新の状態、位置、および装備に関する情報を上級将校に知らせるために、DSS システムを使用しています。

前に述べたように、DSS トランザクションは、通常は OLTP トランザクションと同程度の時間では完了しません。DSS トランザクションは、収集されるデータの量が多いので、処理には非常に長い時間を必要とします。OLTP トランザクションは、一般に一意なキー (顧客番号など) を使ってデータを収集し、そのキーに関連する情報だけを返します。一方、DSS では、一意なキーを使ったクエリは行われず、データベーステーブルの先頭から開始して、テーブルの終わりまでのすべてのデータを処理します。また、DSS トランザクションは、ほかのテーブルへのリンクを行うテーブル結合を使って、さらに詳しい情報を収集することもあります。

注意 :
DSS システムを設計するときには、1 回の I/O 転送で多数のレコードを転送し、I/O 活動を減らすために、大きなデータブロックサイズを選択するようにします。

この種のシステムでは、パフォーマンスアナリストは、CPU とその他のシステムリソースの使用率が 100 % 近くになるものと想定します。このため、関心の対象は、システムの使用率がどうなるかではなく、システムがクエリを処理するためにどれだけの時間を要するかということになります。DSS システムを設計する際の原則は、妥当な範囲で、できるだけ多くのハードウェアを投入するというものです。言い換えると、データベース用のディスク領域を確保するだけでなく、I/O 活動を分散させるために、データベースを複数のボリュームに分散させるレイアウトを計画する必要があります。キャッシュ活動はそれほど多くないので、メモリはあまり問題にはなりません (DSS トランザクションでは、テーブルの先頭から開始し、最後まで処理を続けるというフルテーブルスキャンが行われます) 。

ワンポイント　四半期の売上
企業の報告書のために、四半期の売上高の集計を行っているとします。その販売部門がカバーしているすべての地域内の、その四半期での各種品目の売上に関する情報を収集する必要があります。この検索では、まず region (地域) テーブルの先頭行にリンクしている、最初の customer (顧客) テーブルのデータを取得します。最初の顧客名を取得したら、customer_order (顧客発注) テーブルへのリンクをたどって、期間内にどのような品目の注文があったかを調べます。検索は、第 2、第 3 の顧客名というように続けられます。その地域の顧客のすべてのデータがスキャンされたら、次の (地域ごとの) customer テーブルが取得され、処理が続行されます。通常、この処理が完了するまでには何時間もかかります。

6.4 キャパシティ計画の原則

ピーク時を定義できない場合、事前キャパシティ計画は、通常は安定状態 (平常時) での処理中に予想されるトランザクション活動を推測することによって行われます。

注意 :
ここでの「平常時」とは、営業日における CPU の予想される平均使用量のことを指します。たとえば、1 日を通して平均 55 % のCPU使用量が予想される場合には、これが平常時です。1 日のうち、システムが 1 時間だけ 90 % の使用量を経験した場合には、これがピーク時です。

処理日に完了することが予想されるトランザクション数の最大値と、処理時間がわかったら、時間単位あたりのトランザクション数の平均値を計算することができます。ただし、トランザクションが発生する実際の速度はわからないので、システムのサイジングを行うときには、予約キャパシティを組み込んでおく必要があります。「予約キャパシティ」とは、システムの処理パワーの一部を、より負荷の大きい作業負荷がかかるときのために予約しておくことを指します。

商品発注システムの事後キャパシティ計画では、主要なパフォーマンスカウンタを常に監視して、システムが過去に何を行ったのか、現在何を行っているのかを記録します。この情報は、通常はデータベースに格納され、パフォーマンス、キャパシティの消費量、および空き予約キャパシティの一般的な報告の際に使用されます。Microsoft Excel などのデータベースアプリケーションを使うと、マシンのリソースの使用量を予測するために使えるグラフ、スプレッドシート、およびトランザクション活動レポートを生成することができます。

6.4.1 CPU の使用量

予約キャパシティを持ったマシンを構築し、維持するもう 1 つの理由は、「曲線の屈曲部」理論に関連しています。簡単に述べると、この理論は、使用量がキューに直接の影響を与え、キューの長さは応答時間に直接に関連しているので (実際、キューの長さは応答時間の計算式の一部です) 、使用量は応答時間に直接の影響を与えるということを想定しています。曲線の屈曲部とは、応答時間やキューの長さなどの要因が、線形の増大率から指数関数的な増大率に変わる地点、または無限大に向かう漸近線に変わる地点のことを指します。

ワンポイント
スーパーマーケットでの使用量と応答時間
たとえば、午前 3 時にスーパーマーケットに行き、必要な商品を選び、それらをレジに持っていったとします。この朝早い時間帯には、人は並んでいないので、レジの使用量は 0 % で、キューの長さ (前に並んでいる人の数) もやはり 0 です。応答時間はサービス時間と等しくなります。サービス時間、この例では、買い物の金額を算出し、その分のお金を払うというトランザクションを完了するためにかかる時間が、この処理を完了するために必要なすべての時間となります。
今度は、同じシナリオで、スーパーマーケットがはるかに忙しい午後 5 時の場合を考えてみましょう。レジに着くと、前には 8 人並んでいます (キューの長さは 8 になります) 。応答時間は、前に並んでいる 8 人全員のサービス時間の和 (その人々が買おうとしている商品の数や、支払いに現金とカードのどちらを使うかなどに依存します) に、本人のサービス時間を加えた値になります。レジの使用量も、午後 5 時には午前 3 時よりもはるかに高く、キューの長さ、ひいては全体的な応答時間に直接の影響を与えます。

線形の増大と指数関数的な増大

通常、われわれはシステムに線形の動作を続けさせるよう試みます。これにより、キューの増大率も線形になります。図 6-1 に示すように、「線形の増大」とは、使用量の増大に応じて、キューが一定の長さずつ増大するという意味です。基本原則として、CPU の使用量が 75 % 未満である限り、キューの増大は線形性を保ちます。

図 6-1: CPU の使用量の線形の増大

しかし、ときには、平常時でも CPU が 75 % よりも高い値で使用されることがあります。このシナリオにはいくつかの欠点があります。特に、このように高い使用量だと、キューの長さが指数関数的に増大します。「指数関数的な増大」とは、図 6-2 に示すような幾何級数的な増大のことを指します。

注意 :
この章では、トランザクションのサービス時間が 0.52 秒で、すべてのトランザクションが同じサービス時間を持つと仮定した数値を使用しています。

図 6-2: CPU の使用量の指数関数的な増大

CPU の使用量が約 75 % の地点で、キューの長さの曲線が線形の増大から指数関数的な増大に切り替わることに注目してください (曲線はほとんど垂直の線になります) 。

応答時間

図 6-3 のグラフは、CPU の使用量が応答時間に直接影響を与えることを示しています。似たような曲線が、応答時間のグラフとキューの長さのグラフにも現れることに注意してください。両方のグラフに示している、応答時間の劇的な増大は、CPU の使用量が 75 % 以上の状態を平常時として稼働すべきではないことを示唆しています。これは、CPU を決して 75 % 以上で稼働してはならないという意味ではありませんが、このような状態が長時間続くと、キューの長さと応答時間に大きな悪影響を与えます。曲線の屈曲部、この例では 75 % の使用量を超えないようにすることが、サイジングの最も重要な原則の 1 つであり、システムに必要な CPU の数を決定するときには必ず考慮に入れる必要があります。たとえば、合計のプロセッサ使用量が 180 % になることが予想されるシステムをサイジングしているとしましょう。ひどいパフォーマンスに耐えながらシステムを使うという選択肢も、たとえば 2 つの CPU をそれぞれ 90 % の使用量、つまり曲線の屈曲部よりも 15 % 上の地点で実行するという選択肢もあります。しかし、3 つの CPU を約 60 % で実行し、使用量を曲線の屈曲部よりも 15 % 低い値に保つ方が良い結果が得られます。

この原則は、システムのほかの要素、たとえばディスクにも適用できます。ディスクの曲線の屈曲部は、プロセッサと同じではありません。一般に、ディスクの曲線の屈曲部は 85 % の地点に現れます。この 85 % のしきい値は、ディスクドライブの領域と I/O 処理能力の両方に当てはまります。たとえば、9 GB のディスクは、どの瞬間にも、7.65 GB を超えるデータを含んでいるべきではありません。このデータの制限は、将来の成長に対応するためのものでもありますが、より重要なのは、応答時間を小さく抑えるということです。キャパシティいっぱいのディスクではシーク時間が増大し、全体的な応答時間が悪化します。同じ原理から、ディスクドライブの I/O 処理能力が 1 秒あたり 70 I/O である場合には、平常時で 1 秒あたり 60 I/O を超える速度で I/O が発生しないようにする必要があります。この原則に従えば、プロセッサとディスクが最大限の使用量で使用されるのを防ぐことによって、全体的な応答時間を最小限に抑え、システムを最大限に活用することができます。また、システムにはピーク時のために予約キャパシティを持たせておかなくてはなりません。

図 6-3: 応答時間と CPU の使用量

注意 :
最適なパフォーマンスを得るためには、CPU の使用量を 75 % 未満、ディスクの使用量を 85 % 未満に抑えます。

6.4.2 ページフォールト

プロセッサとディスクのサイジングについては、曲線の屈曲部を超えないことが重要な原則となりますが、メモリについてはどうなのでしょうか ? メモリのサイジングの際には、ページフォールトの原則を使用します。ページフォールトは、ディスクからデータを取り出すために一般的に使用されているシステム機能です。システムが特定のコードまたはデータページを必要としているとき、そのページがメモリ内に存在する場合には、論理 I/O イベントが発生します。つまり、そのコードまたはデータがメモリから読み取られた後に、そのコードまたはデータを必要としていたトランザクションが処理されます。

しかし、必要なコードまたはデータページがメモリ内になかった場合には、どうなるのでしょうか ? この場合には、物理 I/O を実行して、必要なページをディスクから読み取る必要があります。この処理は、ページフォールトによって行われます。システムは、必要なコードまたはデータページがメインメモリ内のワーキングセットに含まれていなければ、ページフォールト割り込みを発行します。ページフォールトは、システムの別の部分に対し、物理ディスクからコードまたはデータを取り出すように指示します。言い換えると、システムが探しているコードまたはデータページがメモリ内になければ、システムはページフォールトを発行して、システムのほかの部分に対し、物理 I/O を実行してそのページを取り出すように指示します。ページフォールトが起こっても、そのページが既にスタンバイリストに含まれている、つまりメインメモリ内に存在している場合、またはページを共有しているほかのプロセスが既に使用している場合には、ディスクからのページの取り出しは起こりません。

物理 I/O には、ユーザー物理 I/O とシステム物理 I/O の 2 種類があります。「ユーザー物理 I/O」は、ユーザートランザクションがメモリ内にないデータを読み取るように要求したときに発生します。この場合、ディスクからメモリへの単純なデータ転送が発生します。通常、この転送は、いずれかのデータフローマネージャとディスクコントローラの組み合わせによって実行されます。「システム物理 I/O」は、システムが、自分が実行しているプロセスのコードページを必要としており、そのコードページがメモリ内にないときに発生します。システムはページフォールト割り込みを発行し、これによって必要なデータがディスクから取り出されるまで処理が中断します。取り出しが終了すると、処理が再開されます。どちらの物理 I/O も、メモリ内にあるデータを取り出す時間がマイクロ秒 (100 万分の 1 秒) 単位であるのに対し、物理 I/O はミリ秒 (1000 分の 1 秒) 単位であることから、応答時間を増大させます。ページフォールトは、応答時間を増大させる物理 I/O を引き起こす場合があるので、ページフォールトを最小限に抑えることで、システムのパフォーマンスを向上させることができます。

システム内では、3 種類のページフォールトが発生する可能性があります。

オペレーティングシステムページフォールト
システムがオペレーティングシステムコードを実行しており、次のコードアドレスがメモリ内になかった場合、システムはオペレーティングシステムページフォールト割り込みを発行して、ディスクから次のコードアドレスを取り出します。コードアドレスフォールトでは、コードデータがディスクからメモリへと転送され、1 回の物理 I/O で完了します。

アプリケーションコードページフォールト
システムがシステムコード以外のコードを実行しており、次のコードアドレスがメモリ内になかった場合、システムはページフォールト割り込みを発行して、ディスクから次のコードアドレスを取り出します。これらのページフォールトでは、コードデータがディスクからメモリへと転送され、1 回の物理 I/O で完了します。

ページフォールトスワップ
変更されたデータページ (「ダーティ」ページと呼ばれます) が存在する場合には、「ページフォールトスワップ」と呼ばれる 2 段階のページフォールトが使用されます。このとき、システムは新しいデータをディスクから取り出すだけでなく、メモリ内の現在のデータをディスクに書き出します。この 2 段階のページフォールトでは 2 回の物理 I/O が必要になりますが、これによって変更されたデータは確実に保存されます。スワップが頻繁に起こると、応答時間に大きな影響を与えかねません。ページフォールトのデータ転送は、実際に必要なのが数バイトであっても、ページ全体に対して起こることに注意してください。ページフォールトスワップは、物理 I/O の回数が 2 倍なので、ほかのページフォールトよりも長い時間がかかります。このため、システム内のページフォールトスワップの回数は最小限に抑える必要があります。

新しいシステムの最小メモリ要件を推測するときには、システム上で実行されるすべてのプロセス (オペレーティングシステムとデータベースエンジンを含む) のメモリの使用量を調べて、作業負荷を処理するために必要な総メモリ容量を算出するように心がけてください。また、ページフォールトも忘れてはなりません。システムのメモリの保守にあたっては、ページフォールトに関する情報を収集し、パフォーマンスデータベースの一部として格納しておく必要があります。このデータに対して予測分析を行って、メモリをいつ追加しなくてはならなくなるかを推測します。ピーク時の使用量を考慮に入れて、十分な空きメモリを確保してください。システムの計画を立てるときには、実行するプロセスに必要なメモリに加えて、5～10 % の余裕を見てください。

注意 :
システムのページフォールトをすべてなくすことはできませんが、最小限に抑えることは可能です。ページフォールトが 1 秒に 2 回以上発生している場合には、メモリを追加してください。システムモニタについては、次の節で説明します (1 秒あたりのページフォールト回数を調べるためのカウンタなど) 。

6.5 メモリのキャパシティ計画

メモリの適切なキャパシティ計画を行うためには、システムを使用する同時ユーザーの数、トランザクションの作業負荷の種類、そしてもちろんオペレーティングシステムの種類を含めて、いくつかの情報を入手する必要があります。サイジングは、一般にインタビューを実施することから開始します。ここではデータベースサーバーのサイジングを行っているので、メモリの使用量とクライアントアプリケーションの使用量に関する情報は、データベースサーバーのサイズには影響を与えません。アプリケーション設計者へのインタビューは不要だと思うかもしれませんが、それは間違いです。

データベースサーバープロセスは、ユーザーに対して、トランザクションを完了するために必要な情報を要求します。データベースサーバーのメモリのサイジングを行うためには、同時ユーザー接続の数と、それらのユーザーが生成する

トランザクション I/O の数を知る必要があります。これらの I/O は読み取り操作と書き込み操作の形を取ります。アプリケーション設計者は、各種のトランザクションとそれらが生成する I/O に関する情報を持っているため、必ずインタビューを行う必要があります。

また、システムの適切なメモリ容量を計算するためには、目標とするキャッシュヒット率とページフォールトの数などの要素も考慮に入れる必要があります。典型的なシナリオを例にとって考えてみましょう。OLTP 商品発注システムに使用するデータベースサーバーのためのシステムのサイジングを行っており、作業負荷を生成する同時ユーザーの数を知る必要があるとします。この情報は、必要なメモリ容量を決定するのに役立ちます。たとえば、どの瞬間にも 50 人の同時ユーザーがシステム上に存在することがわかったとしましょう。このシステムでは、50 人のユーザー用に 25 MB のメモリが必要となります。

注意 :
一般に、ユーザー 1 人について 500 KB のメモリを確保する必要があります。この 500 KB は、シャドウプロセスが必要とする量です。「シャドウプロセス」は、システム上の個々のユーザーごとに存在するユーザープロセスです。

次に、どのオペレーティングシステムを使用するのかを知る必要があります。この例では、オペレーティングシステムは Windows 2000 で、約 20 MB のメモリを必要とします。ここまでで、合計のメモリ容量は 45 MB になりました。さらに、使用するデータベースの実行可能ファイルのサイズも知る必要があります。この例で使用する SQL Server は 5.5 MB を使用します。必要な合計メモリは 50.5 MB になりました。

最後に必要な情報は、データベースの処理領域です。この領域は、ログ領域とデータベースキャッシュの 2 つの要素から構成されます。ログ領域は、実行されている書き込み操作に関する情報を保持しています。トランザクションの処理中にシステム障害が発生した場合には、ログ領域に保持されている情報が、障害の発生前のデータベースイメージである「直前」のイメージの復元に使用されるので、このログ領域はきわめて重要です。ログ領域は監査記録とも呼ばれます。

データベースキャッシュはシステムの特殊な領域です。システムによって処理されるすべてのデータは、この領域を通ります。データベースキャッシュが大きいほど、キャッシュヒット率も高くなります。キャッシュヒット率は、システムが探しているデータがキャッシュメモリ内に見つかる比率のことで、可能な限り高い値であるべきです。目的のデータがキャッシュメモリ内に存在しない場合は、キャッシュフォールトが発生します。キャッシュフォールトは、システムが目的のデータを取り出し、キャッシュメモリに入れなくてはならないという点で、ページフォールトに似ています。キャッシュ領域が小さすぎると、システムはキャッシュ内に存在しないデータを取り出すためにディスクに頻繁にアクセスしなくてはならないので、物理 I/O が増大します。もちろん、これらの物理 I/O はトランザクションの応答時間を増大させます。

キャッシュサイズを計算するには、次の計算式を使用します。

キャッシュサイズ = (キャッシュブロックサイズ) * (キャッシュ内のブロックの数)

キャッシュブロックサイズは、1 回の I/O で転送されるデータの量です。SQL Server では、初期値としてキャッシュブロックサイズが 8 KB に設定されています。キャッシュ内のブロックの数は、キャッシュにどれだけのブロックを保持させるかということです。OLTP では転送するデータ量が少なく、ブロックサイズが小さいほど転送にかかる時間も短くなるので、ブロックサイズとして小さい値を選択するようにしてください。DSS では、転送するデータ量がはるかに多く、ブロックサイズが大きいほど I/O の回数が減るので、ブロックサイズとしてより大きい値を選択するようにしてください。

注意 :
90 % 以上のキャッシュヒット率を確実に保証できる特定のキャッシュサイズなどというものは存在しません。基本的な規則としては、小さなシステムでは約 25 MB、中規模のシステムでは 70 MB、大規模なシステムでは 215 MB をキャッシュサイズとして設定することをお勧めします。巨大なデータベース (約 300 GB) を持つシステムでは、望ましいキャッシュヒット率を達成するために 3 GB ものキャッシュが必要となることもあります。

これまで収集した情報を基に、必要なメモリの最低限の量を計算することができます。システムに必要な最小メモリの計算には、一般に次の計算式を使用します。

最小メモリ = (システムメモリ) + (ユーザーメモリ) + (データベースプロセスメモリ) 

システムメモリはオペレーティングシステムと SQL Server が必要とするメモリの量、ユーザーメモリは個々の同時ユーザーに割り当てられる 500 KB、データベースプロセスメモリはログとキャッシュに必要なメモリです。

この比較的単純な数式は、OLTP アプリケーションと DSS アプリケーションの両方の通常の運用に必要な最小メモリの計算に使用することができます。DSS システムでは、DSS アプリケーションはシーケンシャル読み取りモードでフルテーブルスキャンを実行するので、大きなブロックサイズを選択します。これにより、1 回の物理 I/O でより多くのレコードを読み取ることができます。また、DSS システムでは、すべての I/O が物理 I/O になるので、キャッシュは使用されません。

OLTP アプリケーションシステムでは、システムのインストール時にキャッシュヒット率をチェックするように設定します。キャッシュヒット率を高くすることで、システムの応答時間とパフォーマンスを最大限に高めることができます。

注意 :
システムの目標キャッシュヒット率は、可能な限り 100 % に近い値で、少なくとも 90 % 以上にします。

6.5.1 メモリの使用量データの収集

サイジングを行ったシステムの設定とチューニングを終えたら、メモリの使用量に関するパフォーマンスデータを定期的に収集するようにしてください。このデータを基に、作成したシステムが、応答時間やメモリと CPU の使用量に関する SLA の要件を満たしていることを確認することができます。データ収集は、Windows 2000 のシステムモニタを使って行うことができます。

注意 :
システムモニタは、Windows NT ではパフォーマンスモニタと呼ばれていました。

このデータ収集は、キャパシティ計画の調査のためであり、報告を作成する間隔が大きいことに注意してください。測定の期間は時間単位 (ほとんどのケースでは 24 時間) で、報告の間隔も 24 時間に設定すべきです。キャパシティ計画の調査のためには、パフォーマンスデータとして 1 日に 1 レコードが書き込まれる程度で十分です。監視対象のパフォーマンス条件 (「カウンタ」と呼ばれます) は、報告間隔の期間にわたる平均値を算出します。キャパシティ計画の調査で使用するメモリ監視用のカウンタは、すべて Memory オブジェクトに含まれています (システムモニタにおけるオブジェクトは、複数のカウンタの集まりです) 。

注意 :
システムモニタを起動するには、 [スタート] をクリックします。その後、 [プログラム] - [管理ツール] - [パフォーマンス] をクリックします。システムモニタの詳細表示ウィンドウ領域で、 [追加] ボタンをクリックします。 [カウンタの追加] ダイアログボックスでは、監視するオブジェクトとカウンタを選択することができます。システムモニタの詳細については、システムモニタの [ヘルプ] ボタンをクリックしてください。

メモリ監視用のカウンタには次のものがあります。

• Page Faults/sec カウンタ
  このカウンタは、システム内で発生した 1 秒あたりのページフォールトの数の平均値を示している。ページフォールトは、要求されたコードまたはデータページがワーキングセットにもスタンバイリスト (スタンバイメモリ) にも含まれていないときに発生する。

• Cache Faults/sec カウンタ
  このカウンタは、システム内で発生した 1 秒あたりのキャッシュフォールトの数の平均値を示している。キャッシュフォールトは、キャッシュマネージャが、ファイルシステムキャッシュの中に目的のページを検出できなかったときに発生する。

• Pages/sec カウンタ
  このカウンタは、システムがディスクとの間で読み書きした 1 秒あたりのページの数の平均値を示している。この値は、Pages Input/sec と Pages Output/sec という 2 つのカウンタの和である。この回数には、アプリケーションとページのファイルデータにアクセスする目的で、非キャッシュのメモリマップトファイルやファイルシステムキャッシュに対して行われた読み書きから発生したページングトラフィックが含まれている。このカウンタは、メモリに対する過度の負荷 (「スラッシング」とも呼ばれる) と、そのせいで生じる過度のページングを調査したいときに使用する。

• メモリの空き容量
  この情報は、システム内に残っている未使用メモリの量を示している。このメモリは、データベースまたはシステムのための追加のメモリとして使用できる。メモリの空き容量は、メモリのキャパシティ計画のための最も重要な情報である。

注意 :
メモリの空き容量は、システムモニタでは監視できません。これは、タスクマネージャで [パフォーマンス] タブをクリックし、ピーク時の空きメモリを観察することで知ることができます (タスクマネージャを起動するには、タスクバーを右クリックし、ショートカットメニューから [タスクマネージャ] をクリックします) 。

全体的なキャパシティ計画のデータ収集では、少なくともメモリの空き容量と Page Faults/sec カウンタを監視するようにしてください。

6.5.2 メモリデータの分析

データを収集したら、情報をグラフ化して将来の予測に使用することができます。図 6-4 のグラフは、予測分析の例を示しています。この例では、1999 年 10 月 22 日から 2000 年 1 月 14 日にかけての空きメモリのデータが収集されています。このデータを Excel でグラフ化し、傾向を計算しています。ジグザグの線は実際の使用量の履歴を示しており、直線はこの使用量の線形の傾向を示しています。この図からわかるように、この分析では、2000 年 2 月 18 日までにシステムの空きメモリが 6 % を切ることが予測されます。

図 6-4: メモリの線形の予測分析

図 6-5 のグラフは、同じ期間のページフォールトの増大と、空きメモリが減ることによって生じる可能性のある増大を示しています。ここでは、空きメモリと同じ期間に、1 秒あたりのページフォールトの回数のデータが収集されています。やはり Excel を使って記録したデータをグラフ化しています。この例でも、ジグザグの線は実際の使用量の履歴を、直線はこの使用量の線形の傾向を示しています。この例のグラフでは、2000 年 2 月 18 日までにシステムの 1 秒あたりのページフォールトの回数が 6 回を超えることが予測されています。この値は、この日までに、全体的な応答時間が増大し、応答時間に関する SLA の違反が生じる可能性があることを示唆しています。この種の予測分析は、メモリリソースを追跡するための単純で効果的な手段として利用できます。

図 6-5: ページフォールトの線形の予測分析

6.6 プロセッサのキャパシティ計画

メモリのサイジングと分析を終えたので、次に同じことをプロセッサに対して行います。この時点では、システムに関して次の事柄を仮定することができます。

• アプリケーションとデータベースの設計スキーマは完成している。

• 平常時の CPU 使用量の目標は 75 % 未満。

• 予想されるキャッシュヒット率は 90 % 以上。

• どのディスクドライブでも、使用済み領域と I/O 活動は 85 % 未満。

• サーバーが実行するのはデータベースのみ。

• ディスク I/O はすべてのドライブに均等に分散される。

これらの仮定は、メモリのサイジングのためのガイドラインとしきい値として使用したものですが、CPU のキャパシティを予測するためには、これ以上の情報が必要となります。この情報はデータベース設計者とアプリケーション設計者から得ることができます。

データベースサーバー上の CPU のキャパシティの予測は、それほど複雑ではありません。データベースサーバーはトランザクションのみを処理することを思い出してください。アプリケーションはクライアントマシン上で実行されるので、アプリケーションのサイジングは考慮しなくて済みます。サーバーは、読み取り操作と書き込み操作の形で送られてくるユーザーからの要求を処理します。つまり、I/O の処理を行います。アプリケーション設計者は、トランザクションの性質に関する情報を提供することができます。データベース設計者は、これらのトランザクションの影響を受ける、テーブルとインデックスに関する情報を提供することができます。したがって、調べなくてはならないのは、トランザクションによってどれだけの I/O が生成され、それらがどの程度の時間で完了するのかということです。また、システムが処理しなければならないトランザクションの数と、このシステムの 1 日の処理時間およびピーク時を知る必要があります。

前に述べたように、サイジングはピーク時を考慮して行う方が望ましいと言えます。ピーク時は、最悪のケースのシナリオを表しており、それに対応してシステムを構築することができるからです。残念ながら、ほとんどのケースではこの情報は入手できないため、平常時の情報を使わざるを得ません。処理の対象となるトランザクションを深く理解するためには、トランザクションのプロファイルを基に、生成される読み取りと書き込み I/O の数を決定し、予想される CPU 使用量を計算しなくてはなりません。この情報は、データベース設計者とアプリケーション設計者に対するインタビューから得ることができます。まず、個々のトランザクションがどれだけシステム上で実行されるのかを知り、次に生成される I/O の数を決定する必要があります。この計算結果は、CPU 作業負荷の推定値を提供します。

既存のシステムでは、ユーザーはトランザクションを一度に 1 つずつ実行し、システムモニタを使って追跡して、生成される I/O の数を決定することによって、トランザクションのプロファイリングを行うことができます。この「実際」の情報により、CPU の速度、種類、および数を調整することができます。

ここまでは、ユーザートランザクションによって生成される I/O という観点からの CPU のサイジングについて説明してきました。I/O は、使用しているフォールトトレランスコンポーネントによって生成されることもあります。CPU のサイジングを行う際には、これらの追加の I/O も考慮に入れる必要があります。

6.6.1 フォールトトレランス

今日のほとんどのコンピュータ関連企業は、RAID (Redundant Array of Independent Disks) テクノロジのサポートを通してフォールトトレランスを提供しています (RAID テクノロジの詳しい説明については、第5章を参照してください) 。次に、一般に使われる RAID レベルを示します。

• RAID 0 - 1 台の論理ディスクドライブ

• RAID 1 - ミラー化されたディスクドライブ

• RAID 5 - 複数のディスクドライブとパリティ付きディスクストライピング

RAID 0 は、単に複数のディスクドライブを 1 台の論理ディスクとして使用しているため、単一の障害ポイントが生じます。つまり、ディスクドライブが障害を起こすと、そのディスクドライブ上のデータが失われ、ひいてはデータベース全体が失われます。RAID 0 アレイは図 5-9 に示しています。RAID 1 は、データベースディスクドライブのミラーイメージを提供します。ディスクドライブが障害を起こしても、障害を起こしたディスクドライブ上に存在していたすべてのデータを含んでいるバックアップデータドライブが残っています。RAID 1を使用すると、ユーザーはスプリットシークの恩恵も受けることができます (第 5 章に説明があります) 。これにより、システムは両方のドライブを同時に検索できるようになるので、検索速度が大幅に高速化され、トランザクションの応答時間が減少します。RAID 1 アレイは図 5-10 に示しています。

RAID レベルごとにディスクへの書き込みの回数が異なるので、RAID レベルの選択はディスク I/O の回数に直接影響を与えます。たとえば、RAID 1 では RAID 0 の 2 倍の書き込みが必要となります。ユーザーが 50 回の読み取りと 10 回の書き込みを行うトランザクションを使用する場合、RAID 1 を使用すると、書き込みの回数は 20 回に増えます。

2 台のディスクドライブを使用する RAID 0 構成があった場合、それに相当する RAID 5 構成では 3 台のディスクドライブが使用されます。RAID 5 構成では、各ディスクドライブはほかの 2 台のドライブ上のデータに関する情報 (パリティストライプ) を含んでおり、障害を起こしたディスクのデータの再構築に使用できます。RAID 5 アレイは図 5-11 に示しています。このデータベース保護方式には、費用の面だけでなく、パフォーマンスの面でもコストがかかります。RAID 5 では、各トランザクションについて、1 回の書き込みにつき 2 回の読み取りと 2 回の書き込みが発生します。これは、パリティの整合性を保つために、個々のトランザクションでデータとパリティの 2 台のディスクに書き込む必要があるからです。つまり、データストライプとパリティストライプを読み取って新しいデータに変更し、再び書き込まなくてはならないからです。この冗長性のために、トランザクションの応答時間が若干増大します。

各 RAID レベルの I/O の回数を計算するためには、次の数式を使用します。

RAID 0 の場合。

I/O の回数 
= (1トランザクションあたりの読み取りの回数) + (1 トランザクション
あたりの書き込みの回数) 

トランザクションの読み取りが 50 回で、書き込みが 10 回だった場合、RAID 0 での合計の I/O の数は 60 になります。

RAID 1 の場合。

I/O の回数 
= (1 トランザクションあたりの読み取りの回数) + (2 * (1 トランザクション
あたりの書き込みの回数) ) 

トランザクションの読み取りが 50 回で、書き込みが 10 回だった場合、RAID 1 での合計の I/O の数は 70 になります。

RAID 5 の場合。

I/O の回数 
= (1 トランザクションあたりの読み取りの回数) + (4 * (1 トランザクション
あたりの書き込みの回数) ) 

トランザクションの読み取りが 50 回で、書き込みが 10 回だった場合、合計の読み取りは 50 回、合計の書き込みは 40 回になります。したがって、RAID 5 での合計の I/O の数は 90 になります。

I/O の増加はディスクコントローラの処理範囲であり、ユーザーに対しては透過的です。したがって、アプリケーションに調整を加える必要はありません。RAID の選択は、処理する I/O の数に直接影響を与えることに注意してください。

この読み取りと書き込みの増加は、CPU の使用量と、サイジングの際に選択するディスクの数に影響を与えるので、考慮に入れる必要があります。

ユーザートランザクションによって生じる読み取りと書き込みの合計の数を計算し、選択した RAID レベルによる追加の I/O を加えたら、CPU の使用量を計算するために必要なすべての情報が手に入ったことになります。次の計算式は、提案されたシステムの CPU の使用量を決定するために使用します。

CPU の使用量 = (スループット) * (サービス時間) * 100

スループットは 1 秒間に処理する I/O の回数、サービス時間は典型的な I/O トランザクションの処理に費やされる時間です。この計算式は、CPU の使用量が、単にシステムが 1 秒間に処理する I/O の数の合計に、各トランザクションを実行するためにかかる時間を掛け、パーセンテージに変換するために 100 を掛けた値であるということを述べているに過ぎません。

システムに必要な CPU の数を決定するには、この作業負荷の一部として処理される個々のトランザクションに対して、次の手順を実行してください。

1. 次の計算式を使って、システム上で実行される読み取りの合計を計算する。

読み取りの合計 = (1 トランザクションあたりの読み取りの数) * (トランザクションの総数)

2. 次の計算式を使って、これらの読み取りのうちのどれだけが物理 I/O で、どれだけが論理 I/O になるかを決定する。

   論理読み取りの合計 = (読み取りの合計) * (キャッシュヒット率)
   物理読み取りの合計 = (読み取りの合計) - (論理読み取りの合計)

3. 各読み取りの合計を、次の計算式を使って 1 秒あたりの読み取りの数に変換する。

   論理読み取り / 秒 = (論理読み取りの合計) / (稼動時間)
   物理読み取り / 秒 = (物理読み取りの合計) / (稼動時間)

   稼動時間は、1 日のうち処理が実行される時間の長さである (単位秒)。

4. 次の計算式を使って、個々の読み取り操作に使用された CPU 時間の合計を計算する。

   論理読み取り時間 = (論理読み取り / 秒) * (論理読み取り時間)
   物理読み取り時間 = (物理読み取り / 秒) * (物理読み取り時間)

   論理読み取り時間は、論理読み取りを処理するためにかかる時間である。物理読み取り時間は、物理読み取りを処理するためにかかる時間である。これらの読み取り時間はシステムモニタを使って得ることができる (ワンポイント「ディスクの読み取り時間を調べるには」を参照)。

   注意 :
   読み取り時間の典型的な値は、物理読み取り時間では 0.002 秒、論理読み取り時間では 0.001 秒です。

5. 次の数式を使って、各種の読み取り操作の CPU 使用量を計算する。

読み取り使用量 = (スループット) * (サービス時間) * 100

これは、次のように論理読み取り使用量と物理読み取り使用量に分割できる。

<pre IsFakePre="true" xmlns="http://www.w3.org/1999/xhtml">

論理読み取り使用量 = (論理読み取り / 秒) * (論理読み取り時間) * 100 物理読み取り使用量 = (物理読み取り / 秒) * (物理読み取り時間) * 100

この情報を使って、物理読み取り使用量が多すぎるかどうかを判断することができる。その結果に応じて、論理読み取りの数が増えるようにキャッシュサイズを調整する。

6. 次の計算式を使用して、システム上で実行される書き込みの合計を計算する。RAID 係数は、作業負荷が処理時間中に実行することが予想される書き込みの合計数である。

書き込みの合計 = (1 トランザクションあたりの書き込み) * (トランザクションの 総数) * (RAID係数の増分)

7. 次の計算を行って、システム上で実行される 1 秒あたりの書き込みの数を決定する。

書き込み / 秒 = (書き込みの合計) / (稼動時間)

この稼動時間も、処理が実行される時間の長さである (単位秒)。

8. 次の計算を行って、書き込みの処理に使用された CPU 時間の合計を決定する。

CPU 書き込み時間= (書き込み / 秒) * (CPU 書き込み時間)

9. 次の計算式を使用して、書き込み使用量を計算する。

書き込み使用量 = (書き込み / 秒) * (CPU 書き込み時間) * 100

10. 次の計算式を使用して、トランザクションの合計の CPU 使用量を計算する。

CPU 使用量 = (論理読み取り使用量) + (物理読み取り使用量) + (書き込み使用量)

この計算は、システム上で実行可能なすべての種類のトランザクションについて行わなくてはならない。たとえば、銀行システムでは、出金、入金、および残高計算の 3 種類のトランザクションが必要となる。システムの CPU のサイジングを正確に行うためには、この 3 種類のトランザクションそれぞれについて、使用量の計算を行う必要がある。

11. 最後に、次の計算式を使用して、合計のプロセッサ使用量を計算する。

合計の CPU 使用量 = すべてのトランザクション使用量の和

合計の CPU 使用量が 75 % のしきい値を超えている場合には、システムに CPU を追加する必要がある。CPU を追加することで、次の計算式のように、合計の CPU 使用量を減らすことができる。

<pre IsFakePre="true" xmlns="http://www.w3.org/1999/xhtml">

1 CPU あたりの合計の CPU 使用量 = (合計の CPU 使用量) / (CPU の数)

1 CPU あたりの合計の CPU 使用量が 75 % 未満になるように、十分な数の CPU を追加する。たとえば、合計の CPU 使用量が 180 % ならば、CPU を 3 つ使用する。3 CPU システムでは、1 CPU あたりの合計の CPU 使用量は 60 % となる。

注意 :
どの計算式でもプロセッサ速度を使用していないことを不思議に思った方もいるかもしれません。実際には、プロセッサ速度は間接的に使用されているのです。プロセッサ速度はサービス時間、つまりトランザクションを処理するのに必要な時間に含まれています。

ワンポイント　ディスクの読み取り時間を調べるには
ディスクの読み取り時間は、システムモニタを通して知ることができます。コマンドプロンプトで次のコマンドを入力して Enter キーを押し、Diskperf を起動します。

diskperf -y

6.6.2 1 つの CPU の使用量データの収集

システムを構築したら、メモリ使用量と同じように、CPU 使用量を追跡する必要があります。システムモニタには、CPU 使用量に関するカウンタが多数用意されています。これらのカウンタは Processor オブジェクトに含まれています。次に、サイジングに役立つカウンタを紹介します。

• % Processor Time カウンタ
  プロセッサが命令の実行に費やした時間の比率である。「命令」とは、コンピュータ内の基本的な実行単位であり、「スレッド」は命令を実行するオブジェクトで、「プロセス」はプログラムの実行時に作成されるオブジェクトである。このカウンタは、アクティブな処理の実行に費やされた時間の比率と考えることができる。

• % Privileged Time カウンタ
  プロセッサが特権 (カーネル) モードで費やした時間の比率である。Windows 2000 のサービスレイヤ、Executiveルーチン、およびカーネルはいずれもカーネルモードで動作する。グラフィックスアダプタとプリンタを除くほとんどのデバイスのデバイスドライバも、カーネルモードで動作する。

• % User Time カウンタ
  プロセッサがユーザーモードで費やした時間の比率である。すべてのアプリケーションコードとサブシステムコードは、ユーザーモードで実行される。グラフィックスエンジン、グラフィックスデバイスドライバ、プリンタデバイスドライバ、および Window Manager も、ユーザーモードで実行される。ユーザーモードで実行されているコードは、Windows 2000 Executive、カーネル、およびその他のデバイスドライバのデータにアクセスすることはできない。

• % Interrupt Time カウンタ
  プロセッサがハードウェア割り込みの処理に費やした時間の比率である。割り込みはカーネルモードで実行されるので、このカウンタは % Privileged Time の構成要素の 1 つということになる。このカウンタを使うと、カーネルモードで長時間費やされている場合に、その原因を調べることができる。

• Interrupts/sec カウンタ
  このカウンタは、プロセッサの 1 秒あたりのハードウェア割り込みの数の平均値を示している。デバイスは、処理を完了したとき、またはその他の理由で対処が必要となったときに、プロセッサに対して割り込みを発行する。割り込みを生成する可能性のあるデバイスには、システムタイマー、マウス、データ通信回線、ネットワークインターフェイスカード、およびその他の周辺機器がある。割り込みが発生すると、通常のスレッドの実行は中断される。また割り込みのために、プロセッサはより優先度の高いスレッドへの切り替えを行うことがある。システムタイマーのクロック割り込みは、定期的かつ頻繁に生成され、割り込み活動の基準となる。

キャパシティ計画の調査には、これらのカウンタすべてが必要になるとは限りません。どのカウンタを選択するかは、実施しようとしている調査の細かさによって決まります。ただし、少なくとも % Processor Time カウンタは使用する必要があります。

6.6.3 複数の CPU の使用量データの収集

また、システムモニタを通して、複数の CPU のシステム全体で平均化されたデータを入手することができます。このためには、先ほど紹介した Processor オブジェクトの各カウンタのインスタンスとして、 [_Total] を選択します。

• (_Total) \% Processor Time カウンタ
  各プロセッサの % Processor Times カウンタの合計を、システム内のプロセッサの数で割った値。

• (_Total) \% Privileged Time カウンタ
  各プロセッサの % Privileged Times カウンタの合計を、システム内のプロセッサの数で割った値。

• (_Total) \% User Time カウンタ
  各プロセッサの % User Timesカウンタの合計を、システム内のプロセッサの数で割った値。

• (_Total) \% Interrupt Time カウンタ
  各プロセッサの % Interrupt Times カウンタの合計を、システム内のプロセッサの数で割った値。

• (_Total) \ Interrupts/sec カウンタ
  プロセッサの 1 秒あたりのハードウェア割り込みの数の平均値である。この値は、コンピュータ全体で、システムデバイスがどれほどビジー状態になっているかを示す。

CPU データの分析

これらのカウンタを使って入手したデータは、特定の CPU の使用量の増加、つまりその CPU の応答時間の増大を予測するために使用することができます。図 6-6 は、長期間にわたる CPU 使用量の変化を示しています。CPU の使用量が上昇傾向にあることに注目してください。2000 年 2 月 18 日までには 75 % のしきい値を超えることになります。

図 6-6: CPU 使用量の線形の予測分析

注意 :
より多くの時点のデータを収集するほど、予測の精度が高まります。

6.7 ディスクサブシステムのキャパシティ計画

これでメモリとプロセッサのサイジングが終わったので、次にディスク (I/O) サブシステムのサイジングを行います。システムのこの部分のサイジングは、既に必要な情報の大部分を計算してしまっているので簡単です。まず、システム上で処理される I/O の合計数が必要です。この情報はプロセッサのサイジングで既に入手しています。次に、データベースのサイズが必要です。この情報はデータベース設計者が持っています。ディスクサブシステムのサイジングを行うときには、データベースのサイズと、1 秒あたりの I/O の数のサイジングを行い、必要なディスクドライブの数が多い方の結果を採用しなくてはなりません。

多くの人は、データベースに必要なディスクドライブの数を知って驚きます。しかし、ドライブを追加すれば、データへのアクセスポイントがそれだけ増えることになります。データへのアクセスポイントが1つしか存在しないと、そこがボトルネックになります。すべてのトランザクションがこのボトルネックを通らなくてはならないので、応答時間が増大します。基本的な規則として、データへのアクセスポイントをできるだけ多く用意する必要があります。データへのアクセスポイントが多いほど、ドライブの数が少ないときに生じるボトルネックを避けることができます。また、1 秒あたりの I/O の数が多いときには、I/O 負荷に対処するために、データベースサイズに必要な数以上のディスクが必要になる場合もあります。

たとえば、サイズが 10 GB で、1 秒あたり 140 回の I/O を生成しているデータベースシステムがあったとします。ディスク領域の使用量を 85 % 以下に抑えるという規則に従うと、データベースのサイズに対応するために約 12 GB のドライブが 1 台必要となります。一方、I/O の観点からドライブの要件を考えると、ディスクドライブの処理速度が 1 秒あたり 70 回の I/O だとすれば、各ドライブの I/O キャパシティの 85 % 以下に抑えるためには、3 台のディスクドライブが必要となります。I/O のキャパシティ分析の方が必要な台数が多かった (ディスクドライブ 3 台) ので、それぞれ 1 秒あたり 70 I/O の速度のディスクドライブを3台使用する必要があります (データ領域の合計が、前に計算した 12 GB になるようにします) 。

これは最低限の構成であることに注意してください。必要に応じて、これよりも大きいキャパシティのディスクサブシステムを使用することができます。また、この分析では RAID 構成を原因とする影響は無視していることに注意してください。

注意 :
ディスクサブシステムのサイジングを行うときには、必ずデータベースのサイズと、ユーザーが生成する 1 秒あたりの I/O の回数の両方に、85 % の使用量規則を適用するようにしてください。その後、ドライブの数が多くなった方の計算結果を採用します。また、85 % は、ディスクの使用量としては絶対的な上限であることに注意してください。実際には85 % よりも低い数値に抑える必要があります。また、ディスクドライブの 1 秒あたりの I/O の回数が多くなりすぎると、ボトルネックが発生し、応答時間が増大することも忘れてはなりません。

次に、RAID 構成を考慮に入れて、システムに必要なディスクドライブの適切な数を決定する方法を詳しく説明します。ディスクドライブには、Windows 2000 オペレーティングシステムと SQL Server の実行可能ファイル、ログファイル、そしてデータベースそのものの 3 つの主要コンポーネントを格納する必要があります。各コンポーネントに必要なドライブの数を計算し、3 つの値を合計すると、システムに必要なドライブの総数を得ることができます。

6.7.1 Windows 2000 と SQL Server のためのディスクドライブ数

まず、第 1 のコンポーネントである Windows 2000 Server オペレーティングシステムと SQL Server データベースシステムの実行可能ファイルを格納するために必要なディスクドライブの数を計算する必要があります。通常、これらのディスクドライブは、復旧を可能な限り迅速に行えるように、RAID 1 (ミラー化されたディスクドライブ) を設定した独立したボリュームにすることをお勧めします。ディスクドライブの数はサイズに依存しますが、通常、Windows 2000 Server オペレーティングシステムと SQL Server データベースシステムは 1 台のディスクに収まります。計算は次のような単純なものです。

オペレーティングシステムと SQL Server のためのディスク数 
= (Windows 2000 Server と SQL Server のためのディスク数) * (RAID 係数) 

この例では、データ用とミラー化されたディスクドライブの 2 台ということになります (Windows 2000 Server と SQL Server が 1 台のディスクに格納され、そのディスクが RAID 1 ボリュームでミラー化されます) 。オペレーティングシステムボリュームを RAID 5 または RAID 0 に設定することは勧められません。RAID 5 を使用するためには、少なくとも 2 台以上のディスクドライブが必要になりますし、オペレーティングシステムとデータベースシステムの実行可能ファイルは可能な限り迅速に復旧できるようにしておくべきだからです。

6.7.2 ログファイルのためのディスクドライブ数

第 2 に、システムのログファイルを格納するために必要なディスクドライブの数を計算する必要があります。この数は、主にトランザクションが引き起こす 1 秒あたりの書き込みの数の合計に依存します。これらのディスクに含まれている情報は、最も重要な種類の情報であることに注意してください。これらのディスクは、データベースに何かが生じたときに必要となる監査記録、つまり「直前」のイメージを提供します。監査記録により、ディスク障害によって不完全にしか実行されなかったトランザクションを取り消すことができます。発生する書き込みの数の計算は、プロセッサのサイジングの際に行いました。例として、あるトランザクションが、データファイル用の RAID 0 ボリュームで、8 時間の間に 150 万回の書き込みを生成したとしましょう。ログディスクドライブには RAID 1 を使用すべきなので、RAID 1 構成を使用したとすると、8 時間で 300 万回の書き込みが発生します。これは 1 秒あたり 104.16 回の書き込みに相当します (RAID 1 を使用すると、RAID 0 の 2 倍のトランザクションが生じることを思い出してください) 。必要なドライブの数を計算するには、次の計算式を使用します。

ログディスク数 = (書き込み/秒) / (ディスク I/O 能力) 

「ディスク I/O 能力」の値は、最大値の 85 % 以下でなくてはなりません。また、「書き込み/秒」を「ディスク I/O 能力の上限値」で割った後に、整数に切り上げる必要があります。最後に、「書き込み/秒」の値を、RAID レベルによる書き込み活動の増加に合わせて調整することを忘れてはなりません。1 秒あたり 70 I/O のキャパシティを持つディスクドライブ上で、書き込み数の上限として 85 % の値を使用した場合、1 秒間に 104.16 回の書き込みを処理するために必要なディスクドライブの数は約 1.7 で、これを切り上げるとディスクドライブ 2 台ということになります。

6.7.3 データベースのためのディスクドライブ数

最後は、データベースのために必要なディスクドライブの数の計算です。必要なドライブの数の計算には、データベースのサイズと 1 秒あたりの I/O の回数の両方を検討し、ドライブの数が多い方の結果を採用するようにしてください。

データベースのサイズ

データベースを格納するために必要なディスクドライブの数を決定するには、次の数式を使用します。

データベースディスク数 = (データベースサイズ) / (ディスクサイズ) + (RAID 係数) 

「ディスクサイズ」は、最大値の 85 % 以下でなくてはなりません。また、「データベースサイズ」と「ディスクサイズ」には同じ単位 (KB や MB) を使用するようにしてください。「RAID 係数」は、フォールトトレランスをサポートするために必要な追加のドライブの数です。RAID 1 では、この値は、データベースを格納するために必要なディスクの数と等しくなります。RAID 5 では、追加のドライブが 1 台必要です。10 GB のデータベースで RAID 5 を使用する場合には、12 GB のディスクドライブが 2 台必要となります。

注意 :
データベースドライブには RAID 5 を使用することをお勧めします。

データベース I/O

I/O に対応するために必要なディスクドライブの数は、前の単純な例で見たように、データベースディスクの推奨構成に大きな影響を与えます。この値を計算するには、次の手順に従ってください。

1. 次の計算式を使用して、システム上の読み取り I/O の数の合計を計算する。

読み取りの合計 = (1 トランザクションあたりの読み取りの数) * (トランザクションの総数)

1 トランザクションにつき 500 回の読み取りで、5 万件のトランザクションがあった場合、読み取りの合計は 2,500 万回になる。

2. 次の計算式を使用して、これらの読み取り I/O のうちのどれだけが物理読み取りで、どれだけが論理読み取りになるかを決定する。

   論理読み取りの合計 = (読み取りの合計) * (キャッシュヒット率)
   物理読み取りの合計 = (読み取りの合計) - (論理読み取りの合計)

   目標のキャッシュヒット率が 90 % だとすると、論理読み取りが 2250 万回、物理読み取りが 250 万回になる。

3. 次の計算式を使用して、物理読み取りの合計を 1 秒あたりの読み取りの回数に変換する。

物理読み取り / 秒 = (物理読み取りの合計) / (稼動時間)

稼動時間は、1 日に処理が実行される時間の長さ (単位秒) である。この値は、後で CPU 使用量の計算に必要となる。この例では、稼動時間を 8 時間として、物理読み取り/秒は 86.8 となる。

4. 次の計算式を使用して、システム上の書き込み I/O の回数の合計を計算する。

書き込みの合計 = (1 トランザクションあたりの書き込みの回数) * (トランザクションの 総数) * (RAID 係数)

RAID 5 システムで、1 トランザクションあたり 10 回の書き込みを行う場合、書き込みの合計は (10) \* (50,000) \* (4) 、つまり 200 万回となる。

5. 次の計算式を使用して、物理書き込みの合計を 1 秒あたりの書き込みの回数に変換する。

物理書き込み / 秒 = (書き込みの合計) / (稼働時間)

この例では、200 万回の物理書き込みと 8 時間の稼働時間 (28,800 秒) なので、物理書き込み/秒は 69.4 となる。

6. 次の計算式を使用して、1 秒あたりの物理 I/O の合計を計算する。

1 秒あたりの物理 I/O の合計 = (物理読み取り / 秒) + (物理書き込み / 秒)

この例では、物理読み取り/秒は 86.8、物理書き込み/秒は 69.4 なので、1 秒あたりの物理 I/O の合計は 156.2 となる。次の計算式を使用して、データベースディスクドライブの総数を計算する。

<pre IsFakePre="true" xmlns="http://www.w3.org/1999/xhtml">

データベースディスク数 = (1 秒あたりの物理 I/O の合計) / (ディスク I/O 能力) + (RAID 係数)

「ディスク I/O 能力」を決定するときには 85 % の規則を適用すること、また「RAID 係数」はフォールトトレランスをサポートするために必要なディスクの数であることに注意してください。合計の物理 I/O の値を 156.2、ディスクの処理速度を 1 秒あたり 70 I/O とし、RAID 5 を使用するとすると、合計で 4 台のディスクドライブが必要であることがわかります。1 秒あたりの I/O (2.63) を処理するために 3 台で、RAID 5 のフォールトトレランスをサポートするために 1 台です。

このように、10 GB のデータベースサイズを基準にすると少なくとも 2 台のディスクが必要になり、I/O 活動を基準にすると 4 台のディスクが必要になります。このため、データベースを格納するためには、この 2 つの計算結果のうちの多い方、つまり 4 台のディスクが必要です。

6.7.4 システムのために必要なディスクドライブ数

システムのために必要なドライブの総数を知るためには、個々の結果を合計します。Windows 2000 Server と SQL Server にはディスクドライブ 2 台、ログファイルにはディスクドライブ 2 台、データベースにはディスクドライブ 4 台が必要なので、システム全体では 8 台のドライブが必要となります。

ワンポイント　ある程度の余裕を見る
大部分の設計者は、しきい値 (75 % の CPU 使用量、85 % のディスク使用量など) を最大使用量として使用します。しかし、ほとんどのケースでは、これよりも低い値を使用することを推奨します。もちろん、その選択は必ずしも設計者だけに任されているわけではありません。システム全体のハードウェア予算などの外部要因が、設計上の決定に影響を与えることがあります。システムの目標としては、65 % の最大 CPU 使用量と 70 % のディスク使用量が適しています。ただし、設計しているシステムの種類に応じて、最適だと思われる比率を使用するようにしてください。

6.7.5 ディスク使用量データの収集

システムがセットアップされ、運用が開始されたら、変更の必要が生じた場合に備えて、ディスク使用量のデータを収集すべきです。システムのユーザー数が、つまりトランザクションの数が増える、あるいはデータベースの要件が変更される (より大きなデータベースサイズが必要になる) などの事態が生じる可能性があります。

ディスク使用量の事後キャパシティ計画の調査を行うときには、システムモニタや各種管理ツールで、次のカウンタやディスク情報を追跡します。これらのカウンタは PhysicalDisk オブジェクトに含まれています。

• % Disk Time カウンタ
  選択したディスクドライブが、読み取りまたは書き込み要求の処理を行っていた (ビジー状態) 時間の比率である。

• % Disk Read Time カウンタ
  選択したディスクが、読み取り要求の処理を行っていた時間の比率である。

• % Disk Write Time カウンタ
  選択したディスクが、書き込み要求の処理を行っていた時間の比率である。

• Avg. Disk Read Queue Length カウンタ
  サンプル間隔中に、選択したディスクのキューに入れられた読み取り要求の数の平均値である。

• Avg. Disk Write Queue Length カウンタ
  サンプル間隔中での、選択したディスクのキューに入れられた書き込み要求の数の平均値である。

• Avg. Disk Queue Length カウンタ
  サンプル間隔中での、選択したディスクのキューに入れられた読み取り要求と書き込み要求の数の平均値である。これは前の 2 つのカウンタの和である。

• 1 秒あたりのディスク I/O
  ディスクアレイに対する 1 秒あたりの I/O 活動の、計測期間内での平均値である。この値は、システムモニタで直接得ることはできない。この値を得るには、Disk Reads/sec と Disk Writes/sec の 2 つのカウンタ値を合計する。

• ディスクの使用領域
  現在、データベースまたはオペレーティングシステムが使用しているディスク領域の量である。この値はシステムモニタで調べることはできない。この情報を得るには、ディスクの管理 (Windows NT の場合はディスクアドミニストレータ) を使用する。

• ディスクの空き領域
  現在のディスクの空き領域。この値はシステムモニタで調べることはできない。この情報を得るには、ディスクの管理を使用する。

ディスクの管理を実行するには、 [スタート] をクリックし、 [プログラム] - [管理ツール] - [コンピュータの管理] をクリックします。 [コンピュータの管理] のコンソールツリーで [ディスクの管理] をクリックします。ディスクの管理の詳細については、 [コンピュータの管理] ウィンドウの [ヘルプ] ボタンをクリックしてください。

6.7.6 ディスク使用量データの分析

ディスク使用量データの分析は単純な作業です。たとえば、システムを分析するときには、ディスクの空き領域に関するデータを収集して、どれだけの領域が空いているかを決定します。図 6-7 は、空き領域という観点から見たデータベースの使用量を示しています。

図 6-7: ディスクの空き領域の予測分析

この図では、分析の開始時には 6.15 MB のうち約 2.05 MB が空き領域でした。ディスクの使用量は約 67 % です。2000 年 1 月 14 日までには、空き領域が約 1.5 MB に減り、ディスクの使用量は約 75 % になります。Excel を使って傾向を予測すると、2000 年 2 月 18 日までには、空き領域が約1.3 MB になり、ディスクの使用量が約 83 % になることがわかります。この時点までに、データベース管理者は追加のディスク領域を購入するべきでしょう。

6.8 ネットワークのキャパシティ計画

キャパシティ計画のネットワークの部分を最後まで残しておいたのは、システムの内部からはキャパシティ計画に関する情報をほとんど得られないからです。システムモニタは、ネットワークのパフォーマンスデータを得るために必要なカウンタをあまり持っていないので、ネットワークのサイジングは困難な作業になることがあります。ネットワークは、システムの中の最大の弱点になることが多いので、推測は厳しい姿勢で行わなくてはなりません。

ネットワークのサイジングを行うためには、システム上の同時ユーザーの数、1 秒あたりに処理するメッセージの数、およびこれらのメッセージが含んでいる1 秒あたりのバイト数の平均値を考慮に入れる必要があります。この情報を基に、ネットワークの必要な最小ビットキャパシティに関する推定値を算出することができます。たとえば、あるシステムが転送するデータが、次のような内容だったとしましょう。10 人のユーザーが、それぞれ1分あたり 25 のメッセージを送信します。個々のメッセージの長さは 259 バイトです。この場合、250 のメッセージは、1 分あたり 64,750 バイト、ビットに換算すると 1 分あたり 518,000 ビット、つまり1秒あたり 8633.33 ビットを生成すると推測することができます。この作業負荷は、小さなネットワークでも処理できます。ネットワークサイズの推測には、次の計算式を使用することができます。

ネットワークサイズ = (メッセージ / 秒) * (メッセージ長) * (1バイトあたりのビット数) 

この計算により、帯域幅 (bps) がどれほどの大きさでなくてはならないかを把握することができます。

ネットワークに関連する作業は、ネットワーク使用量を監視することを除けば、これでほぼすべてです。また、ほとんどの状況では、使用できるネットワークが最初から決められており、そのネットワークではシステムをどうしてもサポートできないというようなことがない限り、ほかのネットワークを選ぶことはできません。

6.8.1 ネットワーク使用量データの収集

ネットワークの事後キャパシティ計画の調査を行うときには、ネットワークモニタでネットワーク上を転送されたデータの 1 秒あたりのバイト数を追跡します。この情報は、データ回線がビジーになっている時間の比率を表しています。

注意 :
ネットワークモニタのインストール方法については、Windows 2000 Server ヘルプの「ネットワークモニタをインストールする」トピックを参照してください。

6.8.2 ネットワーク使用量データの分析

ネットワークデータを分析するには、まず上の説明に従って回線キャパシティ (「ネットワークサイズ」) を計算し、次に Bytes/Sec Through Network Interface カウンタの値を確認します。次の計算式でこの 2 つの値を使用すると、合計のネットワーク使用量を得ることができます。

ネットワーク使用量 = (ネットワークを通るバイト数/秒) / (ネットワークサイズ) * 100

図 6-8 は、ネットワーク使用量と日付の関係をグラフ化することで、ネットワークの線形な成長を示しています。

図 6-8: ネットワーク使用量の予測分析

このグラフは、この特定のネットワークセグメントが、2000 年 9 月 2 日にキャパシティの上限に達することを示しています。この例でも、グラフ上にデータ観測点の数が多いほど、精度の高い予測を行うことができます。

6.9 収集するデータの選択

事後キャパシティ計画のために収集すべき一定のカウンタの組み合わせは存在しません。どのカウンタを使用するかは、分析するデータと、求めている詳細さのレベルに依存します。これまでに説明したカウンタに加えて、システムモニタは個々の状況で有用なパフォーマンスカウンタをいくつも持っています。ここでは、プロセスに関する情報を収集するという状況を例にとって説明します。

6.9.1 プロセスデータの収集

プロセス情報は、作業負荷活動のプロファイリングを行うときに有用となります。作業負荷のプロファイリングとは、個々のユーザーが実際にどのような作業を行っているかを調べることです。システムモニタは、この目的に使用できるさまざまなカウンタを用意しています。これらのカウンタは Processor オブジェクトに含まれているカウンタに似ていますが、ここの例ではプロセスデータの収集に使用されます。これらのカウンタは Process オブジェクトに含まれており、次のようなものがあります。

• % Processor Time カウンタ
  選択したプロセス内のすべてのスレッドが、プロセッサを使って命令を実行していた時間の比率である。特定のハードウェア割り込みやトラップ条件を処理するために実行されたコードの実行時間も含まれる。

• % User Time カウンタ
  選択したプロセスのスレッドが、ユーザーモードでのコードの実行に費やした時間の比率である。

• % Privileged Time カウンタ
  選択したプロセスのスレッドが、カーネルモードでのコードの実行に費やした時間の比率である。

• Page Faults/sec カウンタ
  選択したプロセス内で実行されているスレッドが起こすページフォールトの発生率である。

• Elapsed Time カウンタ
  選択したプロセスが実行された合計時間 (単位秒) である。

6.9.2 プロセスデータの分析

この情報の分析は、見かけほど複雑ではありません。たとえば、どのような種類の作業が行われたのかを知るために、システムのプロセスを分析したい場合には、% Processor Time などのカウンタを使ってプロセスデータを収集します。このカウンタは、特定の機能の処理にどれだけの時間が費やされているかを示します。図 6-9 は、経理部門が使用する CalProc クエリというユーザープロセスの成長のようすを示しています。

この情報は、経理部門のユーザーを増やしたときに何が起こるかを予測するのに役立ちます。グラフでは、使用量が増大しつつあり、2000 年 2 月 18 日までに 30 % に達することがわかります。経理部門のユーザーが 10 人いたとすると、2 月には各ユーザーが使用量の 3 % に相当していると推定することができます。したがって、2 月に 3 人のユーザーを追加すれば、CalProc クエリの使用量は約 39 % になると考えられます。

何を計測するかを決定する際には、何を分析するのかを決めることが重要です。これによって、どのような計測構成を使用すべきかが決まるからです。事後キャパシティ計画を継続的に行う場合には、パフォーマンス上の問題を引き起こさないように注意する必要があります。つまり、あらゆる要素を計測し、計測間隔を短く設定してしまうと、既に存在するパフォーマンス上の問題を悪化させかねません。計測間隔が短いほど、より多くのレコードがディスクに書き込まれることになり、多数のカウンタを計測している場合には、このレコードのサイズはきわめて大きくなります。パフォーマンス分析で、パフォーマンスの問題を捕捉するために短い間隔で計測を行わなくてはならない場合には、複数のレコードを使用するようにしてください。ただし、キャパシティ計画では、1 日に 1 つのレコードを書き込むだけで十分です。

図 6-9: ユーザープロセスの予測分析

表 6-1 は、基本的なキャパシティ計画の調査に使用するのに適したカウンタと情報のリストです。これらの項目の中には、システムモニタでは監視できないものもあります。たとえば、メモリの空き容量はタスクマネージャを使って知ることができます。ディスクの使用領域とディスクの空き領域はディスクの管理を使って知ることができます。

表 6-1 キャパシティ計画の調査に役立つカウンタと情報

オブジェクト (項目)	カウンタ
Processor	% Processor Time (個々の CPU 統計データ) (_Total) \% Processor Time (すべての CPU の平均値)
PhysicalDisk	% Disk Time (構成されているすべてのディスクアレイ) Avg. Disk Queue Length
ディスクの空き領域
ディスクの使用領域
Memory	Page Faults/sec
メモリの空き容量
ネットワークを転送されるデータの 1 秒あたりのバイト数

この設定は、システム上で予測分析を行うための出発点となります。システムに過度な負荷を掛けず、データベースを小さく保ちながら、CPU 使用量と、ディスク、メモリ、およびネットワークの使用量に関する情報を得るために必要なすべての要素が含まれています。調査を進めていくにつれ、ほかのカウンタを追加して、情報の幅を広げることができます。

6.10 まとめ

この業界には、キャパシティ計画を行える人が、計画を必要とするシステムの数と比べてごくわずかしかいません。パフォーマンス上の問題は、解消可能なものです。ある程度の常識、適切な情報、そしてこの章で説明したいくつかの計算を使うことで、リソースのキャパシティを簡単に追跡し、予測することが可能です。