Comments
Transcript
HP-UX Integrity サーバへの移行に伴うメモリ使用量の変化 White paper
HP-UX Integrity サーバへの移行に伴うメモリ使用量の変化 White paper 目次 はじめに ...................................................................................................................................................2 要約.........................................................................................................................................................2 1. コード サイズの増加 ...............................................................................................................................2 2. データ サイズの増加...............................................................................................................................3 Oracle サーバに関する留意事項..............................................................................................................4 3. オブジェクト ファイルのサイズ増加 ............................................................................................................4 1 はじめに 本書では、Integrity サーバにおける HP-UX アプリケーションのメモリ使用方法を PA-RISC や他のアーキテクチャ のメモリ使用方法と対比して説明します。対象読者は、HP-UX Integrity サーバにエンタプライズ アプリケーションを 移行するソリューション設計者を想定しています。 要約 他のプラットフォーム向けに開発したアプリケーションをインテル® Itanium® アーキテクチャ ベースの HP Integrity サーバに移行すると、アプリケーションのサイズが多少大きくなります。 一般的な RISC アーキテクチャに比べ、Itanium 上ではいくつかの要因により、アプリケーション コードが 1.5～2 倍のサイズになることがあります。アプリケーション コードは通常、サーバで使用中のメモリの 5% 相当を占有する に過ぎないため、移行によりコード サイズが増加しても、必要な物理メモリの合計量は実質的に影響を受けません。 本書では、最初の項でコード サイズを増加させる各種の要因に触れ、全般的なパフォーマンスの向上に、このコー ド サイズの増加がどのように関連しているかを説明します。 アプリケーションのデータ サイズは、PA-RISC、Itanium のどちらでも基本的に同じです。ただし、2 つ例外があるこ とに留意してください。1 つは C++ アプリケーションの場合で、コンパイラは従来より大きな仮想テーブルを割り当 てます。もう 1 つは定数ポインタ配列を使用するアプリケーションの場合です。HP-UX C/C++ コンパイラの初期の リリースでは、定数ポインタ配列はデータ セグメントに配置されていました。このホワイトペーパーの第 2 項では、 これらの例外の詳細と、その他関連する留意事項について説明します。 オブジェクト ファイルのサイズは、再配置可能ファイル、実行可能ファイルのどちらも、他のシステムに比べると多 少増加します。ただし、それにより必要な物理メモリ量が増えたり、パフォーマンスに悪影響が及ぶことはありませ ん。本書の第 3 項では、これらのオブジェクト ファイル関連の要因について説明します。 PA-RISC や Alpha ベースのシステムから Itanium システムへのアップグレードを検討する際には、Itanium システ ムのメモリ構成に関する、いくつかの要因を考慮する必要があります。まず、既存システムの通常的なワークロード で、メモリ構成におけるコンパイル済みコードサイズを調べ、その値がアップグレード後におよそ 80% 大きくなるも のと想定します。さらに、Integrity サーバで Oracle 9i または Oracle 10gR1 を動作させる場合は、ユーザあたり 3 MB ずつ想定値に上乗せしてください (Oracle 10gR2 に切り替え可能であれば、値の上乗せは不要です)。 Oracle 以外にも、同様の影響を与えるアプリケーションがあるかもしれません。基本的には、アプリケーション バイ ナリのデータ セグメントのサイズを移行前後のシステム間で比較し、その差分を見積り基準にすべきです。スレッド ベースで動作するサーバ アプリケーションの場合は、プロセス ベースのアプリケーションに比べ、移行による影響 は限定的です。 1. コード サイズの増加 Itanium アーキテクチャは、ソース コードに内在するすべての並列処理を、コンパイラで表現できるように設計され ています。この設計による影響の 1 つが、コンパイル済みコードのサイズの増加です。通常、Itanium 向けにコンパ イルされたコード サイズは、同じコードを PA-RISC アーキテクチャ向けにコンパイルした場合より 1.5 ～2 倍、x86 アーキテクチャ向けにコンパイルした場合より 2～2.5 倍、それぞれ大きくなります。このコード サイズの増加には、 次の各要因が関係しています。 • 厳密なバンドルとテンプレート：Itanium アーキテクチャでは、厳密なバンドルとテンプレートのセットが採用され、 マイクロアーキテクチャの簡易化と、より多くの処理を一定時間内に実行できる実装が可能になっています。これ らのテンプレートによって、コンパイラで表現できる並列処理数はほぼ無制限になり、より多くの命令を並列処理 できる大規模アーキテクチャに、より容易に対応できるコードが生成されます。その反面、厳密なテンプレートの 採用によって、生成されるコードの 20～25% は no-op になりますが、最適化の水準とオプィマイザの性能が向 上するにつれて、この値は小さくなります。 • 簡易アドレス指定モード：ベース アドレスからのオフセットに基づくアドレス指定が使用されなくなったことも、基本 サイクル時間の高速化に貢献しています。この簡易アドレス指定モードと仮想キャッシュの組み合わせにより、プ ロセッサが仮想アドレス変換とキャッシュ内検索を並行して実行できるようになり、メモリ レイテンシが短縮されま す。命令セットはポストインクリメント型のアドレス指定をサポートしていますが、それを活用できない場合、コンパ イラで生成される命令数が増加することがあります。 2 • レジスタ ファイルのサイズ拡張：128 個の汎用レジスタと 128 個の浮動小数点レジスタを使用でき、コンパイラ は多数の計算シーケンスを重複させ、複雑な順序不定の命令実行を行うことなくメモリ レイテンシを短縮させま す。さらに、レジスタに格納できるデータ量が増加したことで、データをメモリ間で移動する時間も大幅に削減され ます。ただし、より大きなレジスタ ファイルを処理する必要があるため、命令サイズも平均して数ビット長くなりま す。 • プレディケーション：Itanium のほとんどの命令では、63 個の 1 ビット プレディケート レジスタの値に基づくプレ ディケーションを実行できるため、分岐によるオーバーヘッドが削減されるとともに、より多くの並列処理を表現で きます。Itanium アーキテクチャでは、この機能をサポートするため、命令ごとに 6 ビットのメモリ領域が予約され ます。 • 積極的な最適化：インライン化、ループのアンロール、複製、および投機的実行により、ロード レイテンシを減少 させ、一段と多くの並列処理を表現できます。その一方で、これらの最適化処理は、コンパイル済みコードのサイ ズを増加させる場合があります。 コード サイズを増加させる要因の一部は、Itanium アーキテクチャのいくつかの機能によって緩和されます。たとえ ば、整数演算の比重が高いコードでは、レジスタ スタックによってプロシージャのエントリ ポイントとイグジット ポイ ントでのオーバーヘッドが大幅に緩和されます。レジスタの保存と復元の長いシーケンスを、1 つの alloc 命令で置 き換え、キャッシュ帯域の使用効率を一段と向上させます。 C++ アプリケーションの場合は、上記以外にも留意すべき点があります。PA-RISC のデフォルトの実行時環境は ｢クラシック｣な C++ 実行時環境 (aCC の -AP オプションの説明を参照) ですが、Itanium の実行時環境は｢標準｣ の実行時環境 (aCC の -AA オプション) です。｢標準｣の実行時環境、特に実行時ライブラリの iostream 部分はテ ンプレートを頻繁に使用するため、コード サイズが平均で 20% 大きくなります (具体的な増加量は、アプリケーショ ンによって異なります)。 通常、アプリケーションのコード サイズは、データ サイズに比べると小さく、コード サイズの増加がシステムによる メモリの扱いに与える影響はわずかに過ぎません。標準的なプログラミング モデルでは、コンパイル済みコードは プロセス間で共有できるため、1 台のサーバ上の 1000 個のプロセスで同じアプリケーションが実行されている場 合、メモリにロードすべきコードは 1 つだけです。一方、データは、1000 個のコピーをロードする必要があります。 サーバの通常的なワークロードで、メモリのアクティブな全ページに占めるコードの割合は、5% 前後に過ぎません。 コード サイズが 80% 増加したと仮定しても、それによるメモリ占有率の増加は 4% 未満です。 2. データ サイズの増加 Itanium のデータ レイアウト規約は基本的に PA-RISC と同じであり、PA-RISC のデータ レイアウト規約はその他の RISC アーキテクチャと同様です。したがって、アプリケーションを Itanium システムに移行しても、全般的には、デ ータ サイズが大幅に増加することはありません。 ただし、Itanium は x86 アーキテクチャに比べ、構造体フィールドの配置制約が厳しいため、各フィールドの構造体 内部でのオフセットを均等化するためにコンパイラでパディングが行われ、結果的に構造体のサイズが大きくなるこ とがあります。現在の x86 システムでは、配置制約を満たさないフィールドを含む構造体はパフォーマンスの低下 要因になりますが、通常はパフォーマンスへの影響を回避するために、x86 コンパイラによってパディングが行わ れます。 32 ビット アプリケーションを 64 ビット プログラミング モデルに移行する場合も、データ サイズが増加することが あります。64 ビット プログラミング モデルで再コンパイルするとき、ロング整数型とポインタ型のデータは、すべて 32 ビットから 64 ビットにサイズが増加します。32 ビットの HP-UX アプリケーションについては、Itanium システム への移行で 64 ビット モデルに移行する必要はありません。32 ビット アドレス空間がパフォーマンスや性能の制 約要因になっている場合を除き、64 ビット モデルへの移行を行わないことが推奨されます。64 ビット モデルへの 移行による最終的な影響は、ロング整数型とポインタ型の使用状況に依存するため、アプリケーションごとに異なり ます。基本的には、アプリケーションのデータに必要なメモリ量は およそ 50% 増加するものと考えることができま す。 C++ アプリケーションの場合は、仮想メンバ関数へのアクセスに使用される仮想テーブルのサイズが増加します。 各仮想テーブルの仮想メンバ関数へのポインタ サイズは、PA-RISC では (プログラミング モデルにより) 32 ビット または 64 ビットですが、Itanium では 128 ビットです。Itanium で追加されたスペースは、仮想関数の呼び出しの 高速化に使用されます。この仮想テーブルのサイズ変更による最終的な影響は、クラス数と各クラスに含まれる仮 想メンバ関数の数に左右されますが、通常は限定的です。 3 リテラルや定数などの読み取り専用データと、書き込み可能なデータの扱いには、明確な違いが存在します。読み 取り専用データはプロセス間で共有できるため、アプリケーション コードとして配置可能であり、それを多数のプロ セス間で共有することでアプリケーションのデータ サイズが効果的に抑制されます。 定数ポインタ配列の扱いには留意すべきです。1 つのプログラム ファイルをコンパイルするとき、同じファイル内の 他の場所を参照しているポインタはリンク時に決定され、事実上の定数になります。一方、共有ライブラリをコンパ イルする場合や、ポインタが共有ライブラリ内を参照している場合には、ポインタの参照先が実行時に動的に変化 するため、そのようなポインタを読み取り専用データとして扱ったり、プロセス間で共有することはできません。 Itanium システム版 HP-UX C/C++ コンパイラの A.06.10 以降のリリースでは、プログラム ファイル内で読み取り 専用として扱われる可能性があるポインタを含むすべてのデータが、条件付きの読み取り専用データ セクションに 配置され、リンク時に読み取り専用データの一部として配置するか、書き込み可能なデータの一部として共有ライブ ラリに配置するかが決定されます。 同リリースより前の Itanium システム版 HP-UX コンパイラでは、-exec オプションまたは -minshared オプション付き でコンパイルする場合のみ、定数データが読み取り専用セクションに配置されます。その結果、PA-RISC で共有可 能な読み取り専用データの一部が Itanium では共有不能になり、アプリケーションの実際のデータ サイズが PARISC に比べ大きくなります。最新のコンパイラで再コンパイルすれば、この問題は解消されます。 Oracle サーバに関する留意事項 Oracle サーバ ソフトウェアに必要なメモリ量は、特に読み取り専用データの扱いによって影響されます。現在まで に確認された物理メモリ構成への最も大きな影響は、Oracle サーバのバージョン 9i および 10gR1 でのデータ サ イズの増加に起因しています。Oracle サーバは大きな (約 3 MB) 定数配列を使用します。このテーブルは、PARISC では共有可能なテキスト セグメントに配置されますが、Itanium ではビルド環境の違いにより、プロセス別の データ セグメントに配置されます。Oracle など、同じアプリケーションのインスタンスを多数動作させるアプリケーシ ョンでは、このようなテーブルの複製が、メモリ内にいくつも存在することになります。Oracle のリリース 10gR2 で は、このテーブルはテキスト セグメントに配置され、1 つのテーブルがすべてのプロセスによって共有されます。 Oracle サーバをトランザクション モニタを使用するように設定している場合、あるいは典型的なサーバとユーザの 1 対 1 モデルの代わりにサーバ プールや共有サーバを使用するように設定している場合は、この影響はさほど大 きくありません。 ユーザやトランザクションごとに別プロセスを動作させる他のアプリケーションも、同様の影響を受ける可能性があ ります。必要なメモリの増加量は、PA-RISC アプリケーション バイナリのデータ セグメントのサイズを Itanium 版バ イナリの場合と比較し、その差分に予想されるプロセス数を掛け合わせることによって見積もることが可能です。そ れぞれのプロセスの代わりにカーネル スレッドを使用するアプリケーションの場合は、定数データがすべてのスレ ッド間で共有されるため、移行による影響は限られています。 3. オブジェクト ファイルのサイズ増加 HP は、C++ のテンプレートにコンパイル時インスタンス化モデルを採用しています。このモデルでは、インスタンス 化された関数のコピーが、それを使用するすべてのオブジェクト モジュール内で 1 つずつ生成されます。冗長イン スタンスはリンク時にすべて削除されますが、生成される .o ファイルや .a ファイルの数は、リポジトリ モデルを使 用するコンパイラに比べ、かなり多くなります。これらの要因に関わらず、リンク後に生成される実行可能ファイルの サイズは (前述したコード サイズとデータ サイズの増加を考慮しても)、移行前とさほど変わりません。 Itanium 版の HP コンパイラは、-g (シンボリック デバッグ) オプションの有無に関係なく、最小限の行テーブル情報 を生成します。行テーブルにはフィードバック最適化に必要な情報が格納され、オブジェクト ファイルや実行可能プ ログラムのサイズを 50% 前後、増加させる可能性があります。このテーブルはロードされるプログラム イメージに は含まれず、アプリケーションに必要なメモリ量にも影響しません。 4 お問い合わせはカスタマ インフォメーション センタへ 03-6416-6660 月～金9:00～19:00 土10:00～18:00 (日、祝祭日、年末年始および5/1を除く) HP-UX 製品に関する情報は HP-UX に関する技術情報は http://www.hp.com/jp/hpux http://www.hp.com/jp/developer Intel、インテル、Intel Insideロゴ、Itaniumは、米国におけるIntel Corporationまたはその子会社の 商標または登録商標です。 記載されている会社名および商品名は、各社の商標または登録商標です。 記載事項は2006年4月現在のものです。 本書に記載された内容は、予告なく変更されることがあります。 本書中の技術的あるいは校正上の誤り、省略に対して、 いかなる責任も負いかねますのでご了承ください。 本書は、『Memory Usage on HP-UX Integrity Servers (Version 1.1 (February 15, 2006))』 (英語) をもとに加筆・修正 して日本語で提供するものです。 © Copyright 2006 Hewlett-Packard Development Company,L.P. 日本ヒューレット・パッカード株式会社 〒102-0076 東京都千代田区五番町七番地 PDFHS06031-01