ホワイトペーパー「HP-UX 11i v3メモリ管理サブシステム 」

HP-UX 11i v3 メモリ管理サブシステム

テクニカルホワイトペーパー

目次

はじめに .......................................................................................................................................... 3 メモリ管理サブシステム .................................................................................................................. 3 メモリ管理サブシステムの分析ツール ............................................................................................... 3 top .............................................................................................................................................. 4 swapinfo ...................................................................................................................................... 5 HP GlancePlus .............................................................................................................................. 5 sar .............................................................................................................................................. 8 locinfo: pstat_getlocality() コールの使用例 ....................................................................................... 9 ipcs ............................................................................................................................................ 10 ツールの出力の解釈 ..................................................................................................................... 11

システムに十分なメモリがあるか ................................................................................................. 11 システムに十分なスワップスペースがあるか .................................................................................. 11 サンプルシステム ...................................................................................................................... 11

構成およびチューニングの手引き ........................................................................................................ 14 ローカルメモリとインターリーブメモリ ................................................................................................ 14 イジェクタブル (フローティング) メモリ .............................................................................................. 14 システムベースページサイズ .......................................................................................................... 15 スワップスペースの構成 ................................................................................................................ 15 ファイルキャッシュのサイズ調整 ...................................................................................................... 15 JFS (VxFS) のチューニング ............................................................................................................. 16

アプリケーション開発者が考慮すべき事項 ............................................................................................ 17 アドレッシングモデル ..................................................................................................................... 17 ローカルメモリ .............................................................................................................................. 17 ラージ仮想ページ ......................................................................................................................... 18

詳細情報 ........................................................................................................................................ 18

付録 1 - OS リリースによる相違点 ....................................................................................................... 19 HP-UX 11i v3 の初回リリース以降のメモリ管理機能の強化点 .............................................................. 19 HP-UX 11i v2 と HP-UX 11i v3 の相違点 ........................................................................................... 19

ファイルキャッシュの統一 ........................................................................................................... 19 疑似スワップの無条件使用 ........................................................................................................ 19

付録 2 - プラットフォームアーキテクチャーによる相違点 ......................................................................... 19

付録 3 - ページャー (vhand) の動作 ................................................................................................. 20

付録 4 - スワップスペースの管理 ........................................................................................................ 21 擬似スワップスペース .................................................................................................................... 21 物理スワップスペース .................................................................................................................... 21

デバイススワップスペース .......................................................................................................... 21 ファイルシステムスワップスペース ............................................................................................... 21

物理スワップスペースの予約 .......................................................................................................... 22 疑似スワップスペースの割り当て ..................................................................................................... 22

擬似スワップとカーネルメモリ ......................................................................................................... 23 擬似スワップとロック可能メモリ ....................................................................................................... 23 スワップスペースの優先順位 .......................................................................................................... 23

付録 5 - locinfo プログラムのソースコード ............................................................................................. 24

3

はじめに

本書は、コンピューティングエクスペリエンスを最適化するうえで重要な意味を持つ、HP-UX 11i v3 メモリ管理サブシステムの

特長を説明することを目的としています。「メモリ管理サブシステムの分析ツール」のセクションでは、メモリ管理サブシステム

の動作を詳細に分析できるツールとユーティリティについて述べます。「構成およびチューニングの手引き」のセクションでは、

システム管理者向けの構成およびチューニングのガイダンスを述べます。「アプリケーション開発者が考慮すべき事項」では、

アプリケーション開発者を対象として、メモリ管理の属性の概要を述べます。

本書では、本文において基本的なメモリ管理テクノロジーを取り上げ、高度な技術情報は、参考用として付録に記載していま

す。本書で取り上げるすべてのコマンドとインターフェイスには、使用方法や追加のオプションの詳細を確認できるマンページ

が用意されています。

メモリ管理サブシステムは、HP-UX のリリースに合わせて強化されてきました。本書は、HP-UX 11i v3 のメモリ管理サブシステ

ムに関するものです。HP-UX 11i v3 の初期リリース以降に搭載された機能については、付録 1 を参照してください。

メモリ管理機能の大部分は、ハードウェアプラットフォームアーキテクチャーに依存しません。本書では、プラットフォームアー

キテクチャーによって何らかの違いがある場合には、Integrityプラットフォーム上の動作について述べます。HP Integrityプラッ

トフォームと HP9000 PA-RISC プラットフォームのメモリ管理の違いについては、付録 2 を参照してください。

その他の付録では、ページャーの動作、スワップスペースの管理、および locinfo プログラムのソースコードを取り上げてい

ます。

メモリ管理サブシステム メモリ管理サブシステムの目的は、コンピューターシステム内のすべての物理メモリを制御し、オペレーティングシステムの他

の部分およびアプリケーションプログラムから物理メモリを使用できるようにすることにあります。RAM とも呼ばれる物理メモリ

は、DIMM というパッケージに格納されてコンピューターのマザーボード上に搭載される非永続な高速の記憶域です。アプリ

ケーションプログラムからのメモリの使用は、仮想メモリと呼ばれる抽象化された領域を通じてのみ可能です。アプリケーショ

ンプログラムの観点から見ると、仮想メモリには次のような特長があります。

ソースプログラミング言語のメモリモデルに従ってレイアウトされており、物理メモリのサイズに制限があったり、物理メモリ

が非連続的であったりしても、アプリケーションプログラムからはそのように見えないようになっています。 共有用のインターフェイスを通じて明示的に共有されている場合を除いて、各プログラムに専用のものであり、他のプログ

ラムによるアクセスから保護されています。

すべてのアプリケーションプログラムのメモリ使用量がコンピューターの物理メモリ容量を超える場合の対策として、メモリ管

理サブシステムでは、ほぼ例外なくディスク上で維持される、スワップスペースと呼ばれる特定の記憶域を制御する必要があ

り、その時点においてアクティブに使用されていないメモリ内のデータをスワップスペースにコピーすれば、メモリ領域を他の

用途に使用できるようになります。また、スワップスペース内のデータは、再び必要になった時点でスワップスペースからメモ

リに戻すことができます。

HP-UX では、以前のようにプロセス全体をスワップアウトしなければならないという制限がなく、ページングによってメモリ不足

を軽減できます。「スワップスペース」という従来の名称がそのまま使用されてはいるものの、より正確には「ページングスペー

ス」が採用されていると言えます。

ディスクへのアクセスには、メモリへのアクセスよりはるかに時間がかかるため、メモリ管理サブシステムの動作がシステム全

体のパフォーマンスを大きく左右しますが、本書には、このようなパフォーマンスの最適化に役立つ情報が記載されています。

メモリ管理サブシステムの分析ツール メモリ管理サブシステムの動作を詳細に分析できるツールとユーティリティの代表的なものとして、top、swapinfo、glance、および sar があります。ローカルメモリが構成されている NUMA システムでは、pstat_getlocality() システムコールによってメモ

リの割り当て状況を確認できます。サンプルプログラムの locinfo は、このコールがどのように役立つかを示し、ipcs コマンドで

は、共有メモリの使用率に関する情報が表示されます。これらのツール以外にも、HP テクニカルサポートチームでは、メモリ

管理サブシステムの内部動作を精査できる専用のツールを使用しています。これらの高度なツールについては本書で説明し

ませんが、サポートチームでは、より複雑な状況を分析する際にこれらのツールをインストールします。

4

top top(1) コマンドは、システム上のトッププロセス、システムメモリサイズおよび使用率に関する統計情報を返します。次の例

は、各 CPU の情報を非表示にするために、このコマンドを top -h として呼び出したものです。

メモリ管理に関連するデータは Memory行に示され、プロセス情報は SIZE列と RES列に表示されます。

Memory行には、次の 3 つの重要な情報が表示されます。

システム内のすべてのプロセスで消費されている実メモリ (物理メモリ) の量と、その中で「アクティブ」と検出されたメモリ

の量 (括弧内)。この例では、すべてのプロセスで消費されている物理メモリの合計が 100362036KB であり、そのうち

15489832KBがアクティブ、つまり、現在実行中のプロセスまたは直前の20秒以内に実行されたプロセスに属しています。

GB に換算すると、95.7GB のメモリが使用されており、うち 14.8GB がアクティブということになります。

仮想メモリの消費に関する情報。この例では、プロセスが 102756728KB (98GB) の仮想メモリを使用しており、うち

16389916KB (15.6GB) がアクティブです。

システム内の物理メモリの空き容量。この例では、127850076KB (121.9GB) の十分な空き容量があります。

また、以下の点にも注目してください。

SIZE 列は、プロセスの仮想サイズの合計を示しています。これには、テキスト、データ、スタック、mmap 領域、共有メモリ

領域、および I/O マッピング領域の仮想サイズが含まれます。 RES 列は、プロセスの常駐サイズ、つまり、プロセスのメモリのうち物理メモリを現在占有している部分を示しています。

ページングアクティビティは随時発生するため、この値は単なる概算値です。これらの列の合計を求めても、有意な値は

得られません。共有されている各メモリオブジェクトは、そのオブジェクトを共有するプロセスで1回ずつカウントされるため、

重複してカウントされることになります。

合計仮想サイズは、最近アクセスされていないか、1回もアクセスされていないために物理メモリ内に格納されていないものを

含め、プロセスで定義されているすべてのメモリを反映するものであるため、常に常駐サイズ以上になります。

5

swapinfo swapinfo(1M) コマンドは、スワップスペースのサイズと使用率に関する情報を返します。次の例は、このコマンドを

swapinfo -mt として起動して、値をキロバイト単位ではなくメガバイト単位で表示し、合計行を示したものです。

見出しの下の最初の行は、タイプdevのスワップスペース、つまり、物理ディスクデバイスまたは論理ボリューム全体 (この例

では/dev/vg00/lvol2) のスワップスペースを示しています。2 行目は、タイプ localfs のスワップスペース、つまり、

ローカルファイルシステムを保持しているデバイスまたは論理ボリュームのスワップスペースを示しています。この例では、

ファイルシステム/tmp上にスワップスペースを提供するためにpagingというディレクトリが作成されています。物理デバイス

へのページングは高速ですが、デバイス全体をスワップ専用にする必要があります。ファイルシステムへのページングは、デ

バイスへのページングよりオーバーヘッドが大きくなりますが、実際にスワップで使用されていないディスクスペースをファイル

の格納に使用できます。

HP-UX のデフォルトポリシーでは、プロセスが作成されるたびに、そのプロセスに十分な大きさのスワップスペースが予約され

ます。これにより、システム内のすべてのプロセスのデータを格納する場所が常に確保され、ページアウトが必要なときにス

ワップスペースに空きがないために、プロセスを抹消しなければならない、といった状況になることはありません。reserve 行は、

予約されているものの実際には割り当てられていないスワップスペースの量を示しています。合計値を正確に計算するため

に、このように予約されているスペースの量はマイナス符号付きで FREE列に表示されます。ここに示されるスペースは、随時

割り当てが必要になる可能性があります。

システムのすべてのプロセスで必要となるスペースの量には、プロセスデータを保持することになるメモリ領域が含まれます。

これに該当するスペースは、「疑似スワップ」と呼ばれ、memory行に示されます。疑似スワップは、カーネルまたはアプリケー

ションによってロックされるすべてのメモリで使用され、ディスクスワップがすべて消費されたときにも使用されます。疑似ス

ワップに使用するメモリの量は、オペレーティングシステムによって決定されます。物理メモリの全容量が疑似スワップに使用

されることはありません。FREE 列に示される値は、疑似スワップの空きスペースで、他のツールが報告する実際のメモリ空き

容量と一致するものではありません。

この例のシステムには、大量のスワップスペースがあります。total 行に示されているように、使用可能なスワップスペース

のうち実際に使用されているのは 48%のみです。使用率が 80%未満であれば、システムは快適に動作しており、十分な量の

スワップスペースが存在していることになりますが、スワップ使用率が 90%を超えている場合は、スワップスペースの追加を

検討した方が良いこともあります。

また、このシステムには十分なメモリがあるため、2 つのスワップデバイスのどちらに対しても、実際にはメモリのスワップが行

われておらず、デバイスとページングファイルシステムのどちらについても、使用中のスペースが 0 と報告されています。なお、

予約されているスペースの量は、これら 2つのスワップデバイス上の使用可能スペースと一致しており、プロセス仮想メモリの

残りの部分には、疑似スワップが割り当てられています。

HP GlancePlus HP GlancePlus 製品に含まれる glance(1M) は、メモリ使用率やページングアクティビティなど、システムパフォーマンス

のさまざまな側面を分析できる便利なユーティリティです。glance には、Motif 用のグラフィカルバージョンもありますが、本

書の例ではテキストベースのバージョンを取り上げています。glance では詳細な情報を取得でき、ここでは、メモリ管理に最

も深く関連する4つの画面について説明します。これらの例では、glanceコマンドを引数なしで起動した後、目的の画面を選

択するために特定のキーを押しています。特定のプロセスのメモリ特性を調べるには、プロセス ID (PID) を指定する必要があ

ります。

6

次の例は、mキーを押すと選択できる Memory Report 画面を示しています。

この画面に示されている統計情報は、top コマンドで表示されるものと完全に一致しています。この Memory Report には、

95.7GB のユーザーメモリに加えて、オペレーティングシステムが使用する 26GB のメモリ量が報告されています (Sys Mem)。ここでは総メモリ使用率 (Mem Util) が 52%と算出されていますが、これは快適な動作が可能なレベルです。

この画面の情報は、swapinfo コマンドの返す情報とも一致しており、総スワップ使用率が 48%と報告されています。また、現

在のページング率も低くなっています。KB Paged In行の High Rate列に示されているページインアクティビティのピーク

量は、アプリケーションの起動で発生するデマンドページングに相当します。KB Paged Out 行にはゼロ (0) が並んでいま

すが、これはページアウトアクティビティが一切発生していないことを示しています。KB Paged Out 行は、スワップスペース

へのページアウトとファイルキャッシュからのページアウトの合計を報告します。ファイルキャッシュには、12.2GBのメモリが使

用されています (ファイルキャッシュによる実際の消費が filecache_min カーネル調整パラメーターより低い場合、

glanceは filecache_min カーネル調整パラメーターの値を報告します)。

このメモリプロファイルを要約すると、255.7GB の物理メモリのうち、37%がユーザープロセス、10%がカーネル、5%がファイ

ルキャッシュによってそれぞれ占有されており、48%が空きスペースとなっています。

プロセスの非アクティブ化 (Deactivations) と再アクティブ化 (Reactivations) の値がすべてゼロ (0) であることにも注目して

ください。Reactivations行または Deactivations行にゼロ以外のエントリーがある場合は、ワークロードをサポートす

るために物理メモリを増設する必要があることを意味するため要注意です。

7

次の例は、wキーを押すと選択できる Swap Space 画面を示しています。

この画面には、swapinfo コマンドが返す情報と同じ情報が報告されています。すべてのデバイススワップを消費したときに

のみ使用される疑似スワップを例外として、Priority列に示されている数値が小さいほど優先度が高いことを意味します。

次の例は、tキーを押すと選択できる System Tables Report 画面を示しています。

オペレーティングシステムは、実際に使用されているオブジェクトのそれぞれに対して、特定量のカーネルメモリを割り当てる

必要があります。この例では、アプリケーションが使用する共有メモリセグメントが 111 個存在し、そのぞれぞれが管理用の少

量のカーネルメモリを必要とします。

8

次の例は、M キーを押すと選択できる Process Memory Regions 画面を示しています。この例では、PID 8121 を指定して

sqlplus プロセスを選択しています。

通常は、プロセスで使用される各メモリオブジェクトの情報が複数ページにわたって表示されますが、この例では 1 ページ目

のみを示しています。RefCt 列には、オブジェクトを使用するプロセスの総数が参照カウントとして示されます (このカウント

には、ファイルキャッシュによって追加された参照の数が含まれます)。共有プロセスである TEXTには合計で 3 つの参照があ

りますが、その下のプライベートオブジェクトにはそれぞれ参照が 1 つだけあります。RSS列には、常駐セットサイズ (つまり、

プロセスによって現在消費されている物理メモリの概算量) が示され、VSS列には、対応する仮想サイズが表示されます。

sar システムアクティビティレポートユーティリティである sar(1M) は、オペレーティングシステムのアクティビティに関する情報を

返します。このユーティリティには、さまざまなオプションが用意されていますが、その中でメモリ管理に関連するのは、プロ

セッサー実行キュー長を表示するオプションと、スワッピング/スイッチングアクティビティを表示するオプションです。

次の例は、このコマンドを sar -q 60 1 として実行し、プロセッサー実行キュー長の情報を示したものです。

このように、プロセッサー実行キュー長と占有率に関する情報からも、プロセッサーの使用率を調べることができ、この情報は、

他のツールが表示する情報と一致しています。

9

次の例は、このコマンドを sar -w 60 1 として実行し、スワッピング/スイッチングアクティビティの情報を示したものです。

この例の bswin/s 列には、スワップスペースからメモリへの毎秒 512 バイト単位の転送が行われていないことを意味する

0.0が示されています。また、bswot/s列にも、メモリからスワップスペースへの毎秒 512 バイト単位の転送が行われていな

いことを意味する 0.0が示されています。少量のページインが見られることは少なくありません。オブジェクトによっては、オン

デマンドでのみ、つまり実際に参照されたときにのみメモリに読み込まれることがあります。ただし、ページアウト量が多い場

合は、高パフォーマンスのプロセッサーが低速ディスクアクセスの完了を待機している可能性が高いため、注意が必要です。

ページングアクティビティは、システム上で稼働しているすべてのプロセスの総メモリフットプリントが、使用可能な物理メモリ

の量を超えていることを示します。これに対しては、Instant Capacityを通じたメモリの増設が可能であれば、あるいは vPars環境内に未割り当てのメモリがあれば、物理メモリを増設することで適切に対処できます。メモリ不足を緩和するもう 1 つの方法

としては、ユーザーを他のサーバーにリダイレクトするか、アプリケーションのメモリ要件を再構成する (たとえば、Oracle SGA のサイズを減らす) などして、システムに対するワークロードを削減することが考えられます。

locinfo: pstat_getlocality() コールの使用例 アプリケーションプログラムでは、pstat_getlocality(2) システムコールを呼び出すことにより、NUMA プラットフォー

ム内のメモリ割り当てに関する情報を取得できます。locinfo プログラムは、このシステムコールの使用例です。locinfoの完全なソースコードが本書の付録 5 に収録されています。NUMA プラットフォーム内のセルの属性については、『HP Superdome 2 Partitioning 管理者ガイド』を参照してください。

メモリローカリティのタイプは、インターリーブメモリ (ILM) か、または3つのタイプのローカルメモリのいずれかです。ここで、3つのタイプのローカルメモリとは、セルアーキテクチャーを採用しているハードウェア用のセルローカルメモリ (CLM)、ブレード

で構成されているハードウェアプラットフォーム用のソケットローカルメモリ (SLM) およびブレードローカルメモリ (BLM) を指

します。オペレーティングシステムの観点から見ると、CLMとSLMはともにローカルプロセッサーによるメモリアクセスを可能な

限り高速化するものであり、同等に扱われます。そのため、上記の出力例では、この両者を指す"C{S}LM"という表記が使

われています。ブレードローカルメモリは、ブレード上の 2 つのソケット間でインターリーブされていますが、複数のブレードに

またがってインターリーブされているわけではありません。

このシステムには、0～3 の番号が付いた 4 つのセルに対応する 4 つの CLM ローカリティがあります。-1 で識別されている

ローカリティドメインは、3つのベースセルから得られたメモリで構成される ILMです。セル3はフローティングセルであるため、

ローカルメモリのみを格納し、メモリインターリーブには関係していません。

この例のシステムは、4つのセルのそれぞれに 64GBの物理メモリを搭載しています。セル 0、1、および 2はベースセルであ

り、そのメモリの 7/8 (56GB) を CLM として使用し、残りの 1/8 (8GB) を ILM として使用するように構成されています (一部

のメモリが常にファームウェアで使用されるほか、エラーを示すメモリページが構成解除されていることがあるため、オペレー

ティングシステムで使用できるメモリ量は、公称の容量より若干少なくなります)。

セル 3 は、オンライン非アクティブ化を可能にするために、フローティングセルとして指定されています。カーネルがフローティ

ングメモリ内に何らかのデータ構造を格納することはありませんが、フローティングメモリはアプリケーションで多用されます。

インターリーブメモリは、プログラムテキストや共有カーネルデータなど、グローバルに参照されるオブジェクトに使用されます。

このサンプルシステムが必要とするインターリーブメモリは 16GB 強で、インターリーブメモリをこれより少なくすると、最適なパ

フォーマンスが得られなくなります。

10

次の例は、locinfoを-pオプション付きで実行し、前述の sqlplus プロセスのメモリ割り当てを示したものです。

このプロセスの総メモリフットプリントは約 23MB で、そのうち、最大部分の約 19MB が共有メモリになっています。インデック

ス 4 のローカリティ、つまりグローバルアクセスに適したインターリーブメモリローカリティから共有メモリの大部分が割り当てら

れていることに注目してください。さらに、このプロセスには 2MB 強のプライベートデータがあります。このプライベートデータ

は、セル 0 内のインデックス 0 のローカリティに集中して格納されています。カーネル内のスケジューラーはセル 0 内のプロ

セッサー上でこのプロセスを実行するようにスケジュールを設定するため、メモリアクセスのレイテンシが最小化されます。

weighted 列は、このプロセスの常駐メモリの量を、メモリを共有するプロセスの数で重み付けして示しています。プライベー

トページは 1 ページとしてカウントされ、各共有ページは、そのページを共有するプロセスの数で 1 ページを割ったものとして

カウントされます。この例の sqlplus プロセスの場合、ローカルメモリの大部分はプライベートになっています。共有メモリは主

にインターリーブローカリティから取得され、他の 3 つまたは 4 つのプロセスとの間で共有されています。

ipcs ipcs(1) コマンドは、共有メモリなどの、プロセス間の通信機構に関する情報を返します。次の例は、共有メモリに関するす

べての情報が表示されるように、このコマンドを ipcs -ma として呼び出したものです。

11

ツールの出力の解釈 システムに十分なメモリがあるか 前述の各ツールを使用すれば、システムが実行中のワークロードに対応できる十分なメモリを搭載しているかどうかを判断で

きます。glance の各画面の上部に示されるメモリ使用率をチェックするのが最も簡単な方法です。メモリ使用率の目標値と

しては 85%～90%が適切です。使用率が 50%を下回っている場合は、システムがオーバープロビジョニング状態であり、メモ

リに費やした投資の価値を十分に活かせていないことを意味します。メモリ容量には若干の余裕を持たせた方が良いため、メ

モリ使用率が 95%を超えるような運用はお勧めできません。使用率がそこまで高いと、メモリの可用性によってシステムのパ

フォーマンスが制約されてしまう可能性が高くなります。

メモリ使用率が 95%未満であれば、物理メモリの量によってシステムパフォーマンスが何らかの制限を受けることはありませ

ん。HP-UXでは一般に、メモリ内のファイルデータをかなり積極的にキャッシュするため、メモリ使用率が95%を超えていてもメ

モリボトルネックが生じないこともあります。ただし、メモリ使用率が高く、なおかつページアウトアクティビティが大量に発生し

ている場合は、メモリの可用性がシステムパフォーマンスを制約する可能性が高くなります (メモリ使用率が低い場合のペー

ジアウトアクティビティは、ファイルキャッシュからの不要なページの削除に伴うものと考えられ、その場合は正常な動作であり

問題はありません)。swapinfo コマンドの出力において、USED列にゼロ以外の値が示されているディスクデバイスがある場

合も、システムメモリが不足しています。

物理メモリの量がシステムのボトルネックになっているのであれば、ファイルキャッシュのサイズを縮小するか、アプリケーショ

ンワークロードを削減することで、メモリ不足を緩和できる可能性があります。このような処理が望ましくない場合は、RAM の

量を増やすことを検討してください。

システムに十分なスワップスペースがあるか システムに十分なメモリがあれば、スワッピングが頻繁に生じることはありません。それでも、プロセスの起動に必要なメモリ

予約をサポートするために十分なスワップスペースを確保しておくことは不可欠です。

システムに十分なスワップスペースがないと、現在のメモリとプロセッサーリソースで快適に維持できるだけのプロセスを起動

できなくなることがあります。さらには、実行中のプロセスが追加のメモリを割り当てられなくなり、クラッシュしてしまう可能性

すらあります。システムのスワップスペースが十分かどうかをチェックするには、swapinfo コマンドで「空き (free)」と報告さ

れるスペースの量を確認するのが最も確実です。空きスワップスペースの合計量が物理メモリのサイズの数パーセント未満

であれば、スワップスペースの追加を検討してください。新しい Oracle インスタンスの SGA サイズなど、今後起動されるプロ

セスで必要になる仮想メモリがわかっていれば、より正確な見積もりが可能になります。

サンプルシステム これまで示してきた例はサンプルシステム vmkona1 のものでしたが、このサンプルシステムでは約 100GB の SGA を持つ

Oracle データベース管理システムが稼働していました。Oracle システムでは常に、物理メモリが SGA 全体を十分収容できる

大きさになるようにプロビジョニングを行う必要があります。これにより、オペレーティングシステムが SGAのページングを実行

する必要がなくなり、データベースを最大のパフォーマンスで稼働させることが可能になります。Oracle アプリケーション自体

がメインメモリとディスクの間のデータ転送を管理しますが、これはシステムページアクティビティではありません。

サンプルシステムは、物理メモリの半分強が空きスペースになっていたことから明らかなように、メモリがオーバープロビジョニ

ングされていました。次の出力例は別のシステム vmkona2のものです。vmkona2でも同様のOracleワークロードを実行して

いますが、物理メモリが 32GB しかないためメモリ不足の兆候が出力に示されています。

12

top コマンドの出力には、vmkona1 と同じようなプロセッサー負荷が示されていますが、システム内の物理メモリがはるかに

少なく、空きメモリも非常に小さくなっています。

swapinfoコマンドの出力を見ると、2つの使用可能なディスクデバイスの両方でスワップスペースが使用されるほどメモリが

不足していることがわかります。

なお、この 2 つのスワップデバイスは優先度が同じで均等に使用されるため、使用中スペースはどちらについても 329MB と

報告されています。さらに 40316MB のスワップスペースが予約されていますが、1 番目に示されているスワップデバイスはサ

イズが小さすぎて、このスワップスペースの半分を格納できません。そのため、2 つのデバイス間で割り当てが不均等になり

ます。均等なバランスを維持するには、同じサイズのデバイスを使用することをお勧めします。

13

glanceの出力を見ると、メモリ使用率が 99%に達しています。

空きメモリの量が 319MB、つまり、このシステムで使用可能な 31.7GB の物理メモリ容量の約 1%であることに注目してくださ

い。これは、HP-UX の典型的な動作です。HP-UX では、積極的にメモリを使用してファイル内のオブジェクトをキャッシュし、空

きメモリの量が 1%のしきい値を下回ったときにのみメモリ内のオブジェクトをディスクにプッシュします (HP-UX のパッチレベル

によっては、システム管理者がこのしきい値を調整できる場合があります)。

ファイルキャッシュのサイズは、物理メモリの約 5%に相当する 1.5GB です。

最後に sar コマンドの出力について説明します。

測定期間中に報告されたページングアクティビティはありません。

14

構成およびチューニングの手引き HP-UX は、使いやすさを重視した設計になっています。標準の構成でも、大部分の用途に適した動作が得られ、手動での構

成やチューニングは不要です。ただし、HP-UX の導入シナリオは多岐にわたっており、ホストサーバーとワークロードの規模も

さまざまです。たとえば、システムメモリサイズは 1.5GB～8TB までの広範囲にわたります。アプリケーションは、容量の小さい

メッセージを処理する数千の一時プロセスを生成することもあれば、大規模なデータ構造にアクセスする長期的なプロセスを

少数維持することもあります。HP-UX ソリューションは、変更なしで多目的に対応できるデフォルト設定を提供する一方で、微

調整の手段も提供します。ここでは、チューニングが必要な場合のガイダンスを示します。

ローカルメモリとインターリーブメモリ

NUMA (Non-Uniform Memory Access) 対応の HP サーバーは、モジュラービルディングブロックの複合体として構成されて

おり、それぞれのビルディングブロックが物理コンポーネントにとってローカルとなるメモリを格納します。複数のコンポーネント

から nPartition (電気的な分離とオペレーティングシステムの分離の両方を実現するハードウェアパーティション) が形成され

ている場合は、パーティション内のメモリのすべてまたは任意の部分をインターリーブできます。インターリーブでは、関係する

すべてのローカリティに対して均等にメモリ参照を割り当てます (インターリーブは、parcreate(1M) コマンドまたは

parmodify(1M) コマンドを通じて適用されます)。インターリーブは、プロセッサーとメモリ間の通信におけるデータの量で

ある、キャッシュラインの粒度で確立されます。インターリーブの対象として選択されていないメモリは、同じローカリティ内に存

在するプロセッサーコアからはるかに高速でアクセスできるローカルメモリとして残されます。

大部分の商用アプリケーションでは、ローカルメモリとインターリーブメモリの比率が 7/8 対 1/8 のメモリ構成で最も良好なパ

フォーマンスが得られます。特定の技術アプリケーションなど、メモリ参照のローカリティを伴わないワークロードであれば、イ

ンターリーブメモリを 100%にした方がパフォーマンスが向上することもありますが、商用アプリケーションの場合は、推奨され

る 7/8 対 1/8 の比率を開始点とするのが妥当です。

locinfo などのプログラムを使用すれば、さまざまなメモリローカリティの相対的な使用率を調査できます。インターリーブ

ローカリティの使用率が顕著に高いか、または顕著に低いのであれば、parmodify コマンドによるインターリーブメモリ比率

の変更が適切となることがあります。新しい設定を有効にするにはリブートが必要となるため、この変更は nPartition のリブー

トが許容される場合にのみ実施してください。

vPars 環境では、vPars インスタンスをローカルメモリから構築できます (ただし、基盤となる nPartition がそのように構成されて

いる必要があります)。複数のローカリティのメモリが格納されている仮想パーティションには、インターリーブメモリも含める必

要があります。この場合もやはり、インターリーブメモリをメモリ全体の1/8にすることが推奨されます。1つのローカリティのリ

ソースのみが格納されている仮想パーティションの場合は、インターリーブメモリを含めなくても構いません。

イジェクタブル (フローティング) メモリ

HP-UX では、プラットフォームの動的再構成をサポートしており、アプリケーションワークロードを中断させることなく、セルボー

ド全体やメモリ範囲などの物理リソースをオンラインでアクティブ化、または非アクティブ化できます。オンラインでの非アクティ

ブ化が可能なセルボードをフローティングセルと呼び、リブートなしでは非アクティブ化が行えないセルボードをベースセルと

呼びます。vPars に関しては、オンラインでの非アクティブ化が可能なメモリ範囲をイジェクタブルメモリまたはフローティングメ

モリと呼び、リブートなしでは非アクティブ化が行えないメモリ範囲を非イジェクタブルメモリまたはベースメモリと呼びます。

セルをベースまたはフローティングとして指定するには、parcreate コマンドまたは parmodify コマンドを使用します。

vPars メモリをベースまたはフローティングとして指定するには、vparcreate コマンドまたは vparmodify コマンドを使用し

ます。HP Superdome 2 プラットフォームでは、Onboard Administrator を通じてこれらの操作を実行することもできます。

HP-UX メモリ管理サブシステムでは、フローティングメモリ内に特定のカーネルデータ構造が置かれることがなく、このような最

適化設計によって、プラットフォームの動的再構成イベント中でもスムーズなカーネル動作が実現します。ただし、ベースメモリ

が少なすぎる構成のプラットフォームでは、これが原因となってカーネルのメモリが不足することがあります。

少なくとも 25%のメモリをベースメモリとして残しておくことが最小要件となります。メモリ容量の小さいシステム (2GB 程度) の場合は、ベースメモリを 25%より多くしなければならないことがあり、メモリ容量の大きいシステムは、一般に 25%で快適に

動作します。locinfo プログラムを使用すれば、ベースメモリとフローティングメモリの相対的な使用率を確認できます。シス

テムのフローティングメモリが多すぎてベースメモリが不足している場合は、フローティングメモリの一部を非アクティブ化し、

ベースメモリとして再アクティブ化することが可能です。この場合、システムのリブートは不要です。

『HP-UX Virtual Partitions Administrator's Guide』には、vPars のシナリオにおけるベースメモリとフローティングメモリの構成に

関する、より詳細な推奨事項が記載されています。

15

システムベースページサイズ

ベースページは、HP-UX カーネル内の物理メモリの管理単位です。これは、データおよびコードの格納用として割り当て可能

な物理メモリの最小ブロックであると同時に、メモリ保護の最小単位でもあります。

Integrity プラットフォームでは、HP-UX 11i v3 の 2008年 9 月版アップデート以降、ベースページのサイズが調整可能パラメー

ターとなりました。このパラメーターは値を変更できますが、変更を適用するにはリブートが必要です。

getconf(1) コマンドを使用すれば、システムのベースページサイズを取得できます。ベースページサイズを調整するには、

kctune(1M) コマンドを起動してカーネル調整パラメーターbase_pagesize を変更します。このページサイズの有効値は、

4KB (デフォルト値)、8KB、および 16KB です (64KB のページサイズもサポートされていますが、Integrity Virtual Machines ホスト専用の設定であり、他の用途には大きすぎます)。

ベースページサイズを大きく設定すると、常にカーネルメモリメモリフットプリントが少なくなり、一部のメモリ管理操作の効率が

向上します。一般に、メモリ割り当て量はベースページサイズの倍数に切り上げられるため、多数の小さいオブジェクトがアプ

リケーションによって生成される場合は無駄が生じることがあります。HP で測定したアプリケーションワークロードの大部分で

は、ページサイズをデフォルトの 4KB から 16KB に変更するとパフォーマンスが若干 (1%～4%) 向上します。ただし、本書で

取り上げている分析ツールのどれを使用しても、ページサイズを増やすことでメリットが得られるワークロードを予測すること

はできません。最適なページサイズを決定するには、制御された環境内で実験を行うのが最も確実な方法です。

カーネルメモリフットプリントが最重要事項であれば、ベースページサイズを増やすことにより、メモリオーバーヘッドを減らすこ

とができます。ページごとの固定オーバーヘッドでは、デフォルトの 4KB のページサイズを使用している場合、メモリの 7%強

が消費されます。ページサイズを 8KB に設定するとこれが約 3.6%まで減り、16KB に設定すると約 1.8%になります。

スワップスペースの構成 スワップスペースの構成で使用する主なコマンドは、ページングアクティビティをサポートするために記憶域をスワップスペー

スとして使用できるように指示する swapon(1M) コマンドです。HP-UX では、プロセスが生成されるたびに、そのプロセスに

十分な量のスワップスペースが予約されるようになっています。システムのスワップスペースが不足していて新しいプロセスを

維持できない場合は、プロセスの生成が失敗します。同様に、スワップスペースが使い尽くされるほど、既存のプロセスが大

量のメモリを割り当てようとした場合も、その割り当ては失敗します。swapinfoコマンドによってスワップスペースの空きが少

ないことが報告された場合は、これらの問題を回避するためにスワップスペースの追加を検討してください。通常より大きいプ

ロセスアドレス空間をサポートする目的でのみ追加のスワップスペースが必要になった場合は、スワップスペースが実際に使

用されない限り、パフォーマンスが低くても影響が生じないため、ファイルシステムの一部にスワップスペースを追加した方が

良いこともあります。

未使用のスワップスペースが大量に存在する場合は、swapon と反対の働きをする swapoff(1M) コマンドを使用して、ス

ワップにおけるデバイスの使用を停止し、そのデバイスを他の用途に活用できます。

ファイルキャッシュのサイズ調整 ファイルデータのキャッシュ用に割り当てるメモリの最小量と最大量を調整するには、カーネル調整パラメーター

filecache_min(5) および filecache_max(5) をそれぞれ使用します。パラメーターfilecache_minで指定した割

合のメモリは、I/O アクティビティの高速化のみを目的に割り当てられ、ファイルデータをキャッシュする必要がない場合でも、

他の用途には使用できません。パラメーターfilecache_max では、ファイルキャッシュの最大サイズを指定します。

filecache_max の値を超えるメモリ領域は、プロセスの動的データやカーネルデータのキャッシュなど、他の目的に使用さ

れます。

ファイルキャッシュは、最大サイズに達するまで、追加のファイルデータへのアクセスに応じてサイズが増えます。

filecache_max で設定された上限に達すると、キャッシュされているファイルデータがメモリからファイルシステムへプッ

シュされ、新たに参照されたファイルデータをキャッシュするスペースが確保されます。

これらのファイルキャッシュパラメーターでは、ファイル I/Oアクティビティのパフォーマンスの向上と、メモリのその他の用途の

バランスを調整できます。これらのパラメーターのデフォルト設定では、物理メモリの約 5%がファイルキャッシュ用に予約され

ますが、ファイルキャッシュのサイズは物理メモリの 50%未満に制限されます。HP-UX の顧客ベースを広範に調査したところ、

導入済みのシステムのほぼ 60%で最小ファイルキャッシュサイズがデフォルトの 5%から変更されていないことが判明しまし

た。filecache_min パラメーターの値を 1%～3%の範囲内まで減らしたシステムは、全体の約 34%で、値を増やしたシス

テムはわずか 6%でした。さらに、最大ファイルキャッシュサイズについては、全体のほぼ 3 分の 1 のシステムでデフォルト値

の 50%がそのまま使用されていることがわかりました。filecache_maxパラメーターの値を物理メモリの 5%～10%の範囲

内まで減らしたシステムは、全体のほぼ3分の2を占めており、ファイルキャッシュのサイズがメモリの半分以上に設定されて

いたシステムは、ごく少数でした。

16

JFS (VxFS) のチューニング (HP OnlineJFS、JFS、または VxFS とも呼ばれる) ジャーナルファイルシステムは、システムメモリを大量に消費する傾向があり

ます。これは、特に i ノードキャッシュの使用に関連して顕著です。JFS キャッシュに使用されるメモリの量は、調整パラメーター

vx_ninodeおよび vxfs_ifree_timelagによって制御されます。

JFS i ノードキャッシュには、ディスクから読み込んだ i ノードが保持されます。メモリ内の各 i ノードは、ディスク上の i ノードの

スーパーセットです。ディスク上の iノードには、ファイルごとにファイルタイプ、パーミッション、タイムスタンプ、ファイルサイズ、

ブロック数、エクステントマップなどの情報が格納されます。メモリ内の i ノードには、ディスク上の i ノードの情報とともに、他の

構造体へのポインター、リンクされたリストの維持に使用されるポインター、メモリ内の i ノードの管理に使用されるロックプリミ

ティブなどの情報が格納されます。ファイルデータ自体は i ノードに格納されず、ファイルキャッシュに置かれます。

i ノードがメモリに読み込まれると、その i ノードへの以降のアクセスはメモリを通じて行われ、ディスクに対する読み書きが不

要になります。

JFS 3.5 以降では、次の例のように vxfsstat コマンドを使用することで、i ノードキャッシュ内の現在の i ノード数を表示でき

ます。

この例では、キャッシュ内の現在の iノード数が93566と報告されていますが、このカウントには、現在アクティブに使用されて

いる i ノードと、キャッシュ内にまだ格納されている非アクティブな i ノードの両方が含まれます。

JFS 3.5 以降では、次の例のように vxfsstat コマンドを使用することで、現在アクティブに使用されている i ノードの実際の

数を確認できます。

この例では、i ノードキャッシュに 93566 個の i ノードが格納されていますが、そのうち使用中の i ノードは 1096 個のみです。

残りの i ノードは非アクティブで、i ノードの非アクティブ状態が一定時間継続すると、vxfsd デーモンスレッドのいずれかに

よって、それらの i ノードを解放する処理が開始されます。

各 iノードは約 2KBのメモリを消費します。iノードキャッシュのサイズがシステムワークロードに必要なサイズを超えていると、

メモリリソースが無駄になります。これに該当する場合は、キャッシュのサイズを縮小するのが妥当です。JFS i ノードキャッシュ

の最大サイズは、vx_ninode調整パラメーターでチューニングできます。JFS 4.1 では、kctuneを使用して vx_ninode を

動的にチューニングできます。

システム上で随時開かれるファイルのそれぞれについて、少なくとも 1つの JFS iノードキャッシュエントリーが必要となります。

JFS が占有する可能性のあるメモリの量が心配な場合は、キャッシュで消費されるメモリが全体の 1%または 2%に収まるよう

に vx_ninode の値を減らしてください。大部分のシステムは、vx_ninode の値が 20,000～50,000 の範囲内にチューニ

ングされていれば良好に動作しますが、システム上で実際に稼働しているプロセスの数と、各プロセスが開くファイルの数の

平均値を考慮する必要があります。ファイルサーバーや Web サーバーとして使用されているシステムでは、JFS i ノードキャッ

シュのサイズが大きいほどパフォーマンスが向上することがあり、その場合はデフォルト値からの変更は不要です。

vx_ninodeのデフォルト値は0ですが、これは JFS iノードキャッシュのサイズが自動調整されることを意味します。自動調整

の値は、vx_ninode(5) マンページに示されるスライドスケールに従って、物理メモリサイズから計算されます。たとえば、

8GBのメモリを搭載したシステムでは、物理メモリの約6%が iノードキャッシュ用に割り当てられます。メモリ容量がさらに大き

いシステムでは i ノードキャッシュのサイズが大きくなりますが、128GB 以上のメモリを搭載したシステムの場合、物理メモリに

占める割合は 1.5%付近まで小さくなります。

JFS i ノードキャッシュは HFS i ノードキャッシュから独立して維持されているため、ninode をチューニングしても JFS i ノード

キャッシュは影響を受けません。/stand以外のHFSファイルシステムが存在しない場合は、通常、ninodeを400などの低

い値に設定できます。

17

デフォルトでは、JFS i ノードキャッシュのサイズは動的に調整され、必要に応じて拡張または縮小されるようになっています。

ただし、i ノードはカーネルメモリアロケーターの空きオブジェクトチェーンに解放されるため、そのメモリを他の目的 (その他の

同じサイズのメモリ割り当て以外の目的) に使用できない場合があります。オブジェクトの空きリスト上にある解放済みの iノードは、まだ「使用中」のシステムメモリとみなされます。さらに、カーネルメモリ割り当てとその後の解放処理に伴って、カー

ネルに追加のオーバーヘッドが生じます。

現時点のカーネルメモリアロケーターでは、JFS i ノードキャッシュの動的な性質のメリットをあまり活かすことができません。

キャッシュ内に i ノードを維持する時間を長くして、継続的なカーネルメモリ割り当てと解放処理に伴うオーバーヘッドを軽減す

るには、静的なサイズの JFS i ノードキャッシュを使用する方が有利です。この場合、使用されていない i ノードが解放されずに、

JFS i ノードキャッシュの空きリストチェーン上に維持されます。新しい JFS i ノードをディスクから読み込む必要がある場合、JFSは非アクティブな iノードのうち最も古いものを使用します。さらに、静的な JFS iノードキャッシュを使用すれば、各プロセッサー

で長いカーネルメモリオブジェクト空きチェーンが生じるのを回避できます。また、メモリ容量の大きいシステムでは、vxfsdデーモンが JFS i ノードキャッシュのサイズを縮小するときに消費されるプロセッサー時間がかなり長くなる傾向がありますが、

静的な JFS i ノードキャッシュを使用すれば、このプロセッサー時間の消費を抑えることができます。

HP-UX 11i v2 以降 (JFS 3.5 以降) では、キャッシュ内の i ノードが削除対象とみなされるまでの時間を調整できる、システム

ワイドの調整パラメーターvxfs_ifree_timelag がサポートされています。vxfs_ifree_timelag を-1 に設定すると、

JFS i ノードキャッシュを静的なキャッシュにできます。メモリ容量の大きいシステムでは、vxfs_ifree_timelagを設定する

ことで、vxfsd デーモンによるプロセッサー時間の消費を抑えることができるため、特にメリットがあります。次の例では、

kctuneを使用して、リブートなしで vxfs_ifree_timelagを変更しています。

アプリケーション開発者が考慮すべき事項 このセクションでは、メモリ管理サブシステムと連携可能なアプリケーションプログラムの作成方法について述べます。

アドレッシングモデル アプリケーションに対しては、フラットで連続した仮想アドレス空間が提供されます。そのサイズは、32 ビットアプリケーション

の場合は4ギガバイト、64ビットアプリケーションの場合は16エクサバイトです。仮想メモリサブシステムは、コンパイラおよ

びリンカーと連動し、アドレス空間の特定の部分の使用を管理するためのアドレッシングモデルを提供します。特に、プロセ

ス間で共有されるメモリオブジェクトに使用できる仮想アドレスの範囲は、アドレッシングモデルによって制限されることがあ

ります。

サイズの大きいメモリオブジェクトにアクセスする 32 ビットアプリケーションでは、アドレス空間を柔軟に使用できることが非常

に重要となりますが、その柔軟性を最大限に実現しているのが MPAS (Mostly Private Address Space) モデルです。柔軟性を

向上するにはパフォーマンスが犠牲になりますが、2010 年 3 月版アップデートではこの点が大幅に改善されています。

MPAS モデルを使用できるようにアプリケーションをビルドするには、リンカーld(1) を+as mpas オプション付きで実行しま

す。ビルド後に同じオプションを渡して chatr(1) コマンドを実行すると、アプリケーションを MPAS に変換できます。

ローカルメモリ NUMA構造を持つハードウェアプラットフォームは、ローカルメモリとインターリーブメモリを組み合わせた構成が可能です。ア

プリケーションプログラムでは、メモリオブジェクトをインターリーブローカリティ、現在のローカリティ、またはメモリに最初にア

クセスしたプロセッサーのローカリティのいずれかに格納するように要求するヒントを提供できます。共有メモリオブジェクトの

場合は、shmget(2) コールによって、flags フィールドにメモリヒントを指定できます。メモリマップファイルの場合は、これに

相当するインターフェイスとして mmap(2) が用意されています。

18

アプリケーションプログラムでは、mpctl(2) インターフェイスで提供されるプロセッサーバインディング機能と組み合わせる

などして、メモリヒントを使用することにより、NUMA プラットフォーム上で望ましいプロセッサーとメモリのアライメントの取得を

試行できます。ただし、これには次のような複雑性が付随します。

プラットフォームの動的再構成が行われると、プロセッサー、メモリ範囲、またはローカリティ全体の構成が変化するか、も

しくはこれらが完全に認識されなくなる可能性があります。 同じサーバー上で稼働している他のアプリケーションもメモリ配置やプロセッサーバインディングを試行する可能性がある

ため、リソース使用率のバランスが失われることがあります。

LORA モードでは、HP-UX が自動的かつ継続的に、最善のプロセッサーとメモリのアライメントを各アプリケーションに割り

当てようとします。

上記のような理由から、アプリケーションでメモリ配置ヒントを一切使用せず、オペレーティングシステムに配置を任せた方が

良い結果が得られることがあります。また、もう 1 つの方法として、システム管理者が numa_policy(5) 調整パラメーター

を使用して、アプリケーションメモリの配置をシステムワイドに制御することもできます。

ラージ仮想ページ 基本的なレベルにおいて、HP-UX メモリ管理サブシステムは、常にシステムベースページサイズを単位としてメモリを管理しま

す。アプリケーションで扱うオブジェクトのサイズは、このベースページサイズを大幅に上回っていることがあります。これに該

当する場合は、ベースページの範囲を「スーパーページ」 (「ラージページ」とも呼ばれます) に統合した方が効率的になること

があります。この効率が最も重要となるのは、変換索引バッファー (TLB) と呼ばれるハードウェアリソースを使用する場合で

す。

HP-UX では、ラージページが有利となる状況を自動的に認識して、ラージページを操作します。これに関するカーネルの動作

をシステム管理者が制御するには、vps_ceiling(5)、vps_chatr_ceiling(5)、vps_pagesize(5) の各調整パ

ラメーターを使用します。

たとえば、サイズの大きいメモリオブジェクトがわずかにアクセスされる場合がそうであるように、サイズが非常に大きい可変

ページを使用すると効率が低下する可能性があります。個々のアプリケーションは、最善のページサイズに関するヒントを

chatr(1) コマンド経由でカーネルに渡すことができます。特に、+pi オプションと+pd オプションを使用すれば、それぞれ

コードとデータのページサイズに関するヒントを渡すことが可能です。

詳細情報 『vPars Administrator’s Guide』

http://www.hp.com/go/hpux-vpars-docs (英語/日本語)

『Tunable Base Page Size』ホワイトペーパー

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01916157/c01916157.pdf (英語)

『LORA』ホワイトペーパー

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02070810/c02070810.pdf (英語)

HP GlancePlus 製品情報 http://www.hp.com/go/glance (英語) https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-15-28^9637_4000_306__ (日本語)

『Adaptive Address Space』ホワイトペーパー http://h21007.www2.hp.com/portal/download/files/unprot/Itanium/aas_white_paper.pdf

『HP-UX Performance Cookbook』 http://h21007.www2.hp.com/portal/download/files/unprot/devresource/Docs/TechPapers/UXPerfCookBook.pdf

『HP Superdome 2 Partitioning 管理者ガイド』 http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02585367/c02585367.pdf (日本語)

19

付録 1 - OS リリースによる相違点

HP-UX 11i v3 の初回リリース以降のメモリ管理機能の強化点

2007 年 9 月版アップデートでは、フローティングセルが初めてサポートされました。

2008 年 3 月版アップデートでは、カーネル内にユーザー仮想アドレスをマッピングできる Kernel Access Infrastructure 機

能が導入されました。

2008 年 3 月版アップデートでは、アプリケーションのメモリオブジェクトのデフォルト配置を制御する numa_policy カー

ネル調整パラメーターが導入されました。

2008 年 9 月版アップデートでは、システム管理者がシステムベースページサイズを調整できるようになりました。これより

前のリリースでは、システムベースページサイズが 4KB に固定されていました。

2008年 9月版アップデートでは、システムリブートを行わずにスワップデバイスを即時に削除できる swapoffコマンドが

導入されました。

2009 年 9 月版アップデートでは、初回リリースからパラメーターが用意されていなかったページャーの動作を制御する、

カーネル調整パラメーターが再導入されました。具体的には、これらのパラメーターには、ページャーが使用されていない

ページをメモリからスワップデバイスに移動し始めるタイミングを制御する lotsfree_pct(5) パラメーターが含まれて

います。システム内の空きメモリの割合が lotsfree_pct(5) で設定されたしきい値を下回ると、ページャーがページ

をスワップスペースに移動しますが、このしきい値を下回らない限り、可能な限り多数のページがメモリ内に維持されます。

さらに、ページャーがページをスワップスペースに移動してメモリをより積極的に解放し始めるタイミングを設定する

desfree_pct(5) パラメーターもあり、ここでは、空きメモリの割合がdesfree_pct(5) の値を下回ると、ページャー

が、優先度の低いプロセスをスリープ状態にするなど、より積極的な方法でメモリを解放し始めます。

2010 年 3 月版アップデートでは、MPAS (Mostly Private Address Space) モデルの実装が強化されており、パフォーマン

スが大幅に向上しています。さらに、イジェクタブルメモリを使用する vPars インスタンス内で、さらに大きいスーパーページ

が使用されるようになっています。

HP-UX 11i v2 と HP-UX 11i v3 の相違点 ファイルキャッシュの統一 HP-UX 11i v3 より前のバージョンの HP-UX では、ディスクファイル上のデータへの繰り返しアクセスを高速化する目的で、メモ

リマップファイル用のページキャッシュと、読み込み/書き込みインターフェイス経由でアクセスされるファイル用のバッファー

キャッシュという、2 つのメモリキャッシュが個別に維持されていました。そしてこれら 2 つのキャッシュのサイズ調整のために

余分な管理オーバーヘッドが生じ、メモリ領域の使用効率が低くなっていました。さらに、オペレーティングシステムが 2 つの

キャッシュ間の一貫性を維持していなかったため、アプリケーションでmmap(2) インターフェイスとread(2)/write(2) インターフェイスの両方を使用して同じファイルにアクセスする場合は、明示的な同期処理を行わなければ正常な動作が行わ

れませんでした。

HP-UX 11i v3 では、アプリケーションがアクセスに使用するインターフェイスに関係なく、統一されたファイルキャッシュにファイ

ルデータのメモリイメージが保持されるようになっています。この方式は管理が容易で、メモリの使用効率にも優れており、一

般にパフォーマンスが高くなります。

疑似スワップの無条件使用 HP-UX 11i v3 より前のバージョンでは、メモリを疑似スワップスペースとして使用できるようにするかどうかを、カーネル調整パ

ラメーターswapmem_on(5) で制御していました。疑似スワップを使用することで生じる悪影響はなく、むしろ大きなメリットが

あるため、HP-UX 11i v3 では、この機能が無条件で有効化されています。

付録 2 - プラットフォームアーキテクチャーによる相違点 Integrity プラットフォームでは、システム管理者がシステムベースページサイズを調整できるようになりましたが、HP9000

PA-RISC では、システムベースページサイズが 4KB に固定されています。

MPAS (Mostly Private Address Space) モデルは、Integrity プラットフォーム上でのみ提供されており、PA-RISC プラット

フォームには、MGAS (Mostly Global Address Space) モデルのみが実装されています。

20

付録 3 - ページャー (vhand) の動作 top コマンドの出力を調べることでわかる重要な点として、次の 2 つがあります。

システム上で稼働しているすべてのプロセスで使用される仮想メモリの合計量は、システムで使用可能な物理メモリの合

計量を大幅に上回ることがあります。 どのプロセスも、対応する仮想アドレス空間の一部がメモリにロードされているだけで快適に稼働します。仮想アドレス空

間には、プログラムで定義されているすべてのコードとデータが格納され、実メモリは、プログラムによってアクティブに使

用されているオブジェクトのみで使われます。ただし、プログラムの実行中は常に、仮想アドレス空間のあらゆる部分にア

クセス可能です。

仮想メモリサブシステムは、物理メモリとスワップスペースの間でオブジェクトを移動し、物理メモリとスワップスペースを適切

に使用することで、すべてのプロセスの効率的な稼働を維持します。ページアウトアクティビティを実行するプロセスは vhandと呼ばれます。

vhand の機能は、最後に参照されてから最も長い時間が経過しているページを解放してメモリの可用性を維持することにあ

ります。さらに vhand は、カーネルメモリアロケーターの空きリストのガベージコレクションなど、メモリ可用性の維持に関連す

る他の機能も担います。

vhandでは、2針時計アルゴリズムによって、解放するページを決定します。概念的には、このアルゴリズムには、すべてのメ

モリを通過する 2 つの針 (「エージ針 (age hand) 」と「スチール針 (steal hand) 」) が存在します。エージ針は、各ページに

「最近参照されていない」というマークを付けます。スチール針は遅れて進み、参照されたビットをエージ針がクリアして以降、

各ページがアクセスされたかどうか (「最近参照された」というマークが付いているかどうか) をチェックします。アクセスされて

いないページは、スチールする (ページアウトし、そのメモリを別のユーザーが使用できるようにする) ことができます。

実際には、vhand は二重にリンクされた pregion のリストを順に追ってメモリ内をスキャンするように実装されています。

pregion は、アドレス空間内における仮想メモリの範囲を表します。vhand は呼び出されるたびにすべての pregion をス

キャンするのではなく、通常は各 pregion内のページの一部のみを参照します。

(物理ページデータベースを使用するなどして) すべてのページを単純にスキャンするのではなく pregion を使用すれば、

カーネルメモリや解放済みのメモリを自動的にスキップできるというメリットがあります。ただし、取得したすべてのメモリが単

一のプロセスに属するというデメリットがあります。つまり、スチール針がそのプロセスの pregion に到達すると、スチールさ

れるすべてのページが 1 つのプロセスから取得され、そのプロセスのワーキングセットでページバックが頻繁に発生します。

対話型のプログラムの場合、これは応答性が大幅に低下する原因になります。このような理由から、各 pregion の一部の

みが、通過のたびにエージングまたはスチールされ、vhandはアクティブな pregionリストを複数回通過して、ページング可

能なすべてのメモリを参照する必要があります。

両針間の適切な距離を維持することが重要です。針と針の距離が近すぎると、実際には定期的に使用されているページがス

チールされます。距離が遠すぎると、両針を速く動かして同じスチール率を維持する必要がありますが、これは、vhand がよ

り多くのプロセッサー時間を消費することを意味します。使用可能なページング帯域幅、スチールする必要があるページ数、

すでに解放のスケジュールが設定されているページ数、および vhand の実行頻度に基づいて、カーネルが両針間の適切な

距離を自動的に維持します。

最近参照されていないメモリページを検索し、それらのページをスワップスペースに移動するために、2 つの針が物理メモリの

アクティブな pregion リンクリストを巡回します。エージ針が通過した時点からスチール針が通過する時点までに参照されな

かったページは、メモリから除外されます。両針は、メモリの必要量に応じて決まる可変速度で回転します。

vhand デーモンは、使用可能な空きメモリ量を判断してページングを開始するタイミングを決めます。空きメモリが所定のしき

い値を下回ると、ページングが行われます。vhand は、供給できるメモリ量をそのしきい値まで戻すために、十分なページを

解放しようとします。このページデーモンは、ページをスチールする必要がないほど十分なメモリがあるときに起動された場合

でも、ページのエージング (つまり、参照ビットのクリア) を続けます。ただし、このような状況で頻繁に起動されることはありま

せん。

エージ針が pregion に達すると、次の pregion に移動する前にページの一定の部分 (デフォルトでは、pregion の総

ページの 1/16) をエージングします。p_agescanタグにより、エージ針は、前回の通過中に停止した pregion内の位置に

移動できます。p_ageremain は、次の pregion に移動する前に 1/16 の部分を満たすためにエージングする必要のある

ページ数を示します。

21

エージングとスチールの頻度は、次のようなさまざまな要因に依存します。

vhandの実行頻度 (デフォルトでは 1 秒間に 8 回)

(一定期間内に完了するページアウトのグローバルな発生率と比較して決められる) 使用可能なページング帯域幅 システムの空きメモリがゼロになる回数 ページングしきい値のレベル すでに解放のスケジュールが設定されているページの数

特性が優れているスレッドに対しては、vhand に偏りが生じます。スレッドが優れているほど、vhand がページをスチールす

る頻度が高くなります。

vhand がアプリケーションのページをメモリ内からスワップスペースに移動しないようにするには、いくつかの方法があります。

mlock(2) または plock(2) コールをアプリケーションから使用すれば、メモリ内のページをロックできます。また、アプリ

ケーションをリアルタイムプロセスとして指定する方法もあります。これらの機能は慎重に使用する必要があります。メモリを

ロックすると、ページング可能なメモリの量が減少してリソースの競合が増え、メモリ不足の原因になることもあります。

付録 4 - スワップスペースの管理 スワップスペースとは高速記憶装置 (ほとんどの場合ディスクドライブ) 上の領域であり、仮想メモリサブシステムでプロセス

のページングと非アクティブ化を行うために予約されます。システムには、少なくとも 1 つのスワップデバイス (一次スワップ) が必要です。スワップは、カーネルをリブートしなくても、システムの実行中に必要に応じて (つまり動的に) 追加できます。

スワッパーはプロセスの作成時にスワップスペースを予約しますが、ページがディスクに移る必要があるまでディスクからス

ワップスペースを割り当てません。プロセスの作成時にスワップが予約されるため、スワッパーがスワップスペースを使い果た

すことを防止できます。

HP-UX では、物理スワップと擬似スワップの両方を使用して効率的なプログラム実行を実現しています。

擬似スワップスペース スワップスペースに使用されるシステムメモリを擬似スワップスペースと呼びます。このスペースにより、物理スワップを割り当

てなくてもメモリ内でプロセスを実行できます。通常は、ページアウトしなければならない場合に備えて、システムによるプロセ

スの実行時にスワップスペースがプロセス全体用に予約されます。このモデルにおいて 1GB のプロセスを実行するには、シ

ステムに構成済みの 1GBのスワップスペースが必要です。これによりシステムがスワップスペースを使い果たすことを防止で

きますが、最低限のスワッピングが生じた場合やスワッピングが生じなかった場合は、スワップ用に予約されたディスクスペー

スが十分に活用されません。

このようなリソースの無駄を回避するために、HP-UX は擬似スワップとしてシステムメモリ容量の最大 7/8 までを使用するよう

に構成されています。これは、システムメモリが 2 つの機能 (プロセス実行スペースとスワップスペース) を果たすことを意味

しています。擬似スワップスペースを使用すれば、2GB のスワップを備える 2GB のメモリシステムで、最大 3.75GB (2GB の

物理スワップスペース + 1.75GB の疑似スワップ) のプロセスを実行できます。ただし以前と同様に、プロセスがこの拡張しき

い値を超えて拡大したり、この値を超えるプロセスが作成されたりすると、そのプロセスは失敗します。

スワップに擬似スワップを使用するとページがロックされるため、擬似スワップの量が増えるとロック可能メモリの量が減ります。

アプリケーション全体がメモリに常駐している場合に最良のパフォーマンスが得られるシステム (生産ラインのコントローラー

など) では、擬似スワップスペースを使用することでパフォーマンスが向上します。そのためには、アプリケーションをメモリ内

にロックするか、プロセスで使用される容量がシステムメモリの 7/8 を超えないようにします。

作成されるプロセスの数が許容数に近づくと、スラッシングが生じ、システムの応答速度が低下することがあります。

物理スワップスペース 物理スワップスペースには、デバイススワップスペースとファイルシステムスワップスペースの 2 種類があります。

デバイススワップスペース デバイススワップスペースは固有の予約済み領域 (ディスク全体またはディスクの論理ボリューム) に存在し、一般にファイ

ルシステムスワップスペースよりも高速です。

ファイルシステムスワップスペース ファイルシステムスワップスペースはマウントされたファイルシステム上に配置され、サイズはシステムのスワッピングアクティ

ビティによって変わります。ただし、未使用のファイルシステムブロックが必ずしも連続していないことがあるために余分な読み

込み/書き込み要求が生じることと、コードの追加階層の余分なオーバーヘッドが原因で、スループットはデバイススワップよ

りも遅くなります。

22

物理スワップスペースの予約 スワップの予約は、数値によって行われます。システムの物理スワップスペースのページ数には制限があります。HP-UX では、

適切なカウンターを減分することでプロセス用のスペースが予約されます。

UNIX®システムや UNIX に類似したシステムの大部分では、必要に応じてスワップが割り当てられます。ただし、スワップス

ペースが使い果たされているにもかかわらず、プロセスのページをスワップデバイスに書き込む必要がある場合は、プロセス

を抹消するしかありません。HP-UXでは、この問題を軽減するために、プロセスが forkまたは execされる時点でスワップが

予約されます。新しいプロセスが fork または exec される際、予約済みの使用可能なスワップスペースがプロセス全体を処理

するには不十分な場合、プロセスが実行されないことがあります。

この一般規則の例外として、「遅延スワップ」があります。chatr(1) +z オプションを使用すると、プログラム全体を遅延ス

ワップの対象として指定できます。さらに、mmap(2) MAP_NORESERVE フラグを使用すると、任意のプライベートメモリマップ

オブジェクトを遅延スワップの対象として指定できます。遅延スワップの対象として指定されたオブジェクトについては、スワッ

プスペースの事前予約が行われません。このように設定されたオブジェクトに対してページアウトが必要になったときに使用

可能なスワップスペースがなければ、そのオブジェクトを受け持っているプロセスにSIGBUSシグナルが渡され、通常はプロセ

スが終了します。

デバイススワップまたはファイルシステムスワップを追加するために swapon() が呼び出されると、新たに使用可能になった

スワップ量がページ単位に変換され、swapspc_max (使用可能になったスワップ総量) と swapspc_cnt (使用可能なス

ワップスペース) という 2 つのグローバルスワップ予約カウンターに追加されます。

プロセス用にスワップスペースが予約されるたびに (つまり、プロセスの作成または拡大時に)、必要なページ数だけ

swapspc_cntが減分されます。カーネルは、必要になるまでディスクブロックを実際には割り当てません。

スワップスペースが使い果たされると (swapspc_cnt == 0)、スワップ予約の要求によって、ファイルシステムスワップス

ペースが割り当てられます。この割り当てが正常に行われると、swapspc_max と swapspc_cnt の両方が更新され、要求

を満たすことができます。ファイルシステムスペースを割り当てることができなければ、擬似スワップが使用可能でない限り要

求は失敗します。

(プロセスの終了または縮小が原因で) スワップスペースが不要になると、解放されたページ数だけ swapspc_cnt が増分さ

れます。swapspc_cntは swapspc_maxを上回ることがなく、常にゼロ以上です。ファイルシステムスワップは、不要になる

とファイルシステムに対して再び解放され、swapspc_max と swapspc_cntが更新されます。

デバイススワップスペースまたはファイルシステムスワップスペースが使用できない場合、擬似スワップが最後の手段として

使用されます。これにより、swapmem_cnt が減分され、ページがメモリにロックされます。擬似スワップは解放されるか、また

は割り当てられますが、予約されることはありません。

疑似スワップスペースの割り当て 使用可能なシステムメモリの約7/8は、擬似スワップスペースとして使用できます。擬似スワップは、グローバル擬似スワップ

予約カウンターswapmem_max (使用可能な擬似スワップ) と swapmem_cnt (現在使用可能な擬似スワップ) で追跡されま

す。物理スワップスペースが使い果たされ、追加のファイルシステムスワップを取得できない場合、swapmem_cnt が減分さ

れ、プロセス用の擬似スワップスペースが予約されます。

たとえば、4GB のメモリを搭載するシステムでは、swapmem_max と swapmem_cntで約 3.5GB の擬似スワップスペースが

追跡され、残りのスペースは、システム使用のためにのみ予約されたページ数を示すグローバル sys_memで追跡されます。

デバイススワップと擬似スワップの両方が使い果たされると (swapspc_cnt==0かつ swapmem_cnt==0になると)、プロセ

スの作成または拡大時の試行が失敗します。

プロセスは、領域ごとのカウンターr_swapmem を増分することで、プロセスに割り当てられた擬似スワップページの数を追跡

します。割り当てられた擬似スワップスペースがプロセスで必要なくなると、解放されたスペース量だけ swapmem_cnt が増

分され、r_swapmemが更新されます。

擬似スワップが消費するメモリは本来、他の目的に使用できるメモリであるため、控えめに使用されます。物理スワップスペー

スが最近解放されたかどうかは、オペレーティングシステムによって定期的にチェックされます。最近解放された場合、システ

ムは擬似スワップの使用から、使用可能な物理スワップのみの使用にプロセスを移行しようとします。swapspc_cnt がゼロ

に低下するか、別の領域で擬似スワップが使用されなくなるまで、リスト上の各領域について swapspc_cntが r_swapmem値だけ減分されます。次に swapmem_cntが、この移行に成功した擬似スワップ量だけ増分されます。

23

擬似スワップとカーネルメモリ 擬似スワップは、システムメモリの使用をめぐってカーネルと競合します。最初に、使用可能メモリの 1/8 (sys_mem ページ

数) が擬似スワップに使用できないように設定されますが、これで、カーネル動的メモリとバッファーキャッシュスペースの両方

の処理に十分なメモリが確保できるわけではありません。カーネルは、これらの目的のために擬似スワップからメモリを借用し、

ページの借用時に swapmem_cnt を減分します。そして swapmem_cnt がゼロになると、sys_mem がゼロになるまで

sys_memからのページの取得が開始されます。

借用された擬似スワップが返されると、解放される量が最初に sys_mem に追加されます。sys_mem が最大値 (maxmem - swapmem_max) に達すると、返された追加ページが使用され、swapmem_cntが増えます。

擬似スワップとロック可能メモリ 擬似スワップはシステムメモリの使用量と関係があるため、スワップ予約方式にロック可能メモリのポリシーが反映されます。

プロセスがそれ自体をメモリ内にロックする際に、追加メモリが割り当てられるとは限りませんが、ロックされたページは汎用

目的で使用できなくなります。そのため、これらのページを考慮して swapmem_cnt が減分されます。プロセスがメモリ内に

plockでロックされる場合、swapmem_cnt もプロセス全体のサイズだけ減分されます。

スワップスペースの優先順位 スワップに使用可能なすべてのスワップデバイスとファイルシステムに 0 (最高優先度) ～10 (最低優先度) の優先順位が付

けられます。この優先順位は、デバイスまたはファイルシステムからスワップスペースが使用される順序を示します。システム

管理者は、swapon(1M) コマンドのパラメーターを使用してスワップスペースの優先順位を指定できます。

スワッピングは、優先順位が同じデバイスとファイルの両方に対して交互に行われますが、デバイスの方がプロセッサー時間

をより効率的に使用できるため、オペレーティングシステムによって、ファイルシステムの前にデバイスがスワップされます。

特定のデバイスが他のデバイスよりも大幅に遅い場合を除いて、大部分のスワップデバイスに同じ優先順位を割り当てること

をお勧めします。同じ優先順位を割り当てるとディスクヘッドの動きが制限されるため、ページングのパフォーマンスが向上し

ます。

24

付録 5 - locinfo プログラムのソースコード NUMA サーバー上のメモリ割り当ての分析に役立つ、locinfo プログラムのソースコードを以下に示します。このコードは、

pstat_getlocality(2) マンページに記載されている例に基づいています。

25

© Copyright 2010 Hewlett-Packard Development Company, L.P. 本書の内容は、将来予告なく 変更されることがあります。HP 製品およびサービスに対する保証については、当該製品および サービスの保証規定書に記載されています。本書のいかなる内容も、新たな保証を追加する ものではありません。本書の内容につきましては万全を期しておりますが、本書中の技術的 あるいは校正上の誤り、脱落に対しては責任を負いかねますのでご了承ください。

Oracle は、Oracle Corporation の商標です。 UNIX は、the Open Group の商標です。

5900-0908、2010 年 8 月