システム・リソースの計画と管理

システムのニーズに対応するために共有メモリを適切に割り当てる方法については、以下のガイドラインを参照してください。

並列デジャーナリングを構成して、複数のアップデータ・ジョブが並列でレコードを適用できるようにすることができます。並列デジャーナリングを有効にすると、アップデータ、リーダ、プリフェッチャのジョブを含む、多くのプロセスを同時に実行することができます。アップデータ・ジョブの既定の数は、パフォーマンスを最適化するように、システム・リソースに基づいて決定されます。この機能はスループットを向上させ、ミラーリング ("並列デジャーナリングの構成" を参照) やジャーナルのリストア ("^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照) で使用されます。

次の表を使用して、最大 16 までの任意の数のアップデータに必要なリソースを見積もることができます。

アップデータを追加で有効にする場合、より多くのメモリを gmheap に割り当てる必要が生じる可能性が非常に高くなります。既定では、gmheap は、グローバル・バッファに割り当てられるメモリの 3% に構成されます。アップデータの追加ごとに、追加で 200 MB を割り当てる必要があります。

システムに割り当てる必要のあるヒュージ・ページまたはラージ・ページの量を決定するには、以下の手順を実行します。注 ： Windows では、ラージ・ページの量は自動的にスケーリングされるため、この手順を実行する必要はありません。詳細は、"Windows でのラージ・ページの構成" を参照してください。

1. ヒュージ/ラージ・ページを適切に割り当てずに、InterSystems IRIS を導入します。

2. ヒュージ/ラージ・ページに関するメッセージを messages.log で確認します。messages.log で該当する行を見つけるには、以下のようなコマンドを使用できます。最新のエントリを確認するようにしてください。

   grep "Huge Pages" messages.log | tail -5
   

   

   messages.log のエントリは以下のようになります。

   ヒュージ/ラージ・ページの割り当てが失敗した場合 ：

   Failed to allocate 19216MB shared memory using Huge Pages. Startup will retry with standard pages. If huge pages are needed for performance, check the OS settings and consider marking them as required with the Cache 'memlock' configuration parameter.
   

   

   ヒュージ/ラージ・ページの割り当てが成功した場合 ：

   Allocated 30232MB shared memory using Huge Pages: 26950MB global buffers, 512MB routine buffers
   

   

3. messages.log の共有メモリの割り当てを記録します。

4. お使いのシステムの手順に従ってヒュージ/ラージ・ページを割り当てます。手順 3 で記録した共有メモリの割り当て量に数 MB を追加した量に相当するヒュージ/ラージ・ページ数を割り当てます (これは、バージョン間の共有メモリの微小な変動を考慮するもので、アップグレードのたびに再計算する手間を省くことができます)。

   • Linux でのヒュージ・ページの構成

   • IBM AIX® でのラージ・ページの構成

5. 変更を確実に反映させるには、ヒュージ/ラージ・ページを割り当てた後、オペレーティング・システムを再起動してください。再起動しないと、ヒュージ・ページが完全に割り当てられない可能性があります。

十分なヒュージ・ページが使用できる Linux プラットフォームでは、InterSystems IRIS の共有メモリ・セグメントがヒュージ・ページ・プールから割り当てられます。ヒュージ・ページを使用すると、ページ・テーブルの領域を節約することでメモリを節約できます。また、InterSystems IRIS を共有メモリ・セグメント内にロックして、そのページがページ・アウトされないようにすることができます。InterSystems IRIS をホストするシステムでは、ほとんどの状況でヒュージ・ページを使用することをお勧めします。

Linux システムの既定のメモリ・ページ・サイズは 4 KB です。最新の Linux ディストリビューションには、ヒュージ・ページ (システム構成に応じて、2 MB または 1 GB のメモリ・ページ・サイズ) のオプションが含まれています。ヒュージ・ページが構成されていると、InterSystems IRIS はメモリの割り当て時に自動的にヒュージ・ページを使用します。

Linux でヒュージ・ページを構成するには、以下の手順に従います。

1. ステータスを確認します。

   /proc/meminfo にはヒュージ・ページに関する情報が記録されています。既定では、ヒュージ・ページは割り当てられていません。既定のヒュージ・ページ・サイズは 2 MB です。以下はその例です。

   HugePages_Total:     0
   HugePages_Free:      0
   HugePages_Rsvd:      0
   Hugepagesize:     2048 KB
   

   

2. /etc/sysctl.conf ファイルに以下の行を入力します。

   echo "vm.nr_hugepages=2056" >> /etc/sysctl.conf  
   

   

3. システムを再起動します。ヒュージ・ページは連続したページとして割り当てる必要があります。また、割り当て後には再起動が必要になることがあります。再起動しないと、ヒュージ・ページが完全に割り当てられない可能性があります。

4. 再起動後に、meminfo を検証します。例えば、以下のようになります。

   [root woodcrest grub]# tail -4 /proc/meminfo
   HugePages_Total:  2056
   HugePages_Free:   2056
   HugePages_Rsvd:      0
   Hugepagesize:     2048 KB
   

   

5. InterSystems IRIS でのヒュージ・ページの使用を検証します。

   InterSystems IRIS を起動すると、割り当てられた共有メモリの量が、例えば以下のようなメッセージで表示されます (これは messages.log ファイルに記録されています)。

   Allocated 3580MB shared memory: 3000MB global buffers, 226MB routine buffers
   

   

   ヒュージ・ページで使用可能なメモリ量は、割り当てられる共有メモリの合計量より多いことが必要です。このメモリ量が不足していると、ヒュージ・ページは使用できません。例えば、共有メモリが 3580 MB で、ヒュージ・ページ・サイズが 2 MB の場合、少なくとも 1791 のヒュージ・ページを構成する必要があります。

6. 例えば、Docker で Linux を使用する場合は、以下の手順でヒュージ・ページのサポートを有効化します。

   コンテナを実行する場合は、--cap-add=IPC_LOCK フラグを追加して、コンテナがメモリ・ページをロックし、メモリ・ページがスワップされるのを防ぐことができるようにします。以下に例を示します。

   docker run ..... --cap-add=IPC_LOCK  
   

   

   または、docker-compose.yaml で管理されるコンテナの場合は、インスタンスのサービス定義の下に cap_add 構成を追加し、メモリ・ページをロックできるようにします。

   services:
   ...
     iris:
       ...
       cap_add:
         - IPC_LOCK
   

   
   Note:

   HugePages_Total を共有メモリ使用量に近い値に設定しつつ、数 MB のヒュージ・ページを追加で割り当てることをお勧めします。これらは、システムのアップグレード時に発生する可能性のある、共有メモリ使用量の小さな変更に対処するための予備として機能します。

AIX は複数のページ・サイズ (4 KB、64 KB、16 MB、および 16 GB) をサポートしています。4 KB ページと 64 KB ページの使用は、InterSystems IRIS にとって透過的です。InterSystems IRIS が 16 MB のラージ・ページを使用するようにするには、そのラージ・ページを AIX で構成する必要があります。AIX は、構成済みのラージ・ページまたはヒュージ・ページの数を需要に基づいて自動的に変更することはありません。現時点では、InterSystems IRIS は 16 GB のヒュージ・ページを使用しません。

ラージ・ページは高性能な環境でのみ構成します。ラージ・ページに割り当てられたメモリは、ラージ・ページのみが使用できるようになるためです。

AIX では、ラージ・ページは以下のように vmo コマンドを使用して構成します。

vmo -r -o lgpg_regions=<LargePages> -o lgpg_size=<LargePageSize>

<LargePages> は予約するラージ・ページの数を指定し、<LargePageSize> は、ハードウェアでサポートされるラージ・ページのサイズをバイト単位で指定します。

例えば、以下のコマンドは、1 GB のラージ・ページを構成します。

# vmo -r -o lgpg_regions=64 -o lgpg_size=16777216

ラージ・ページを構成したら、bosboot コマンドを実行してこの構成をブート・イメージに保存します。システムの起動後、以下の vmo コマンドを使用して固定されたメモリ用にこのラージ・ページを有効にします。

vmo -o v_pinshm=1

ただし、memlock=64 の場合、vmo -o v_pinshm=1 は必要ありません。

InterSystems IRIS がそのメモリを Windows システムで大きなページとして割り当てることができるようにすることをお勧めします。これにより、メモリおよびページング容量をより効率的に使用できます。そのためには、InterSystems IRIS の実行に使用する Windows ユーザ・アカウントに Windows の “メモリ内のページのロック” (SELockMemory) 特権を付与します。この特権により、InterSystems IRIS はメモリをラージ・ページとして要求できるようになります。起動時のメモリ割り当ての詳細な制御については、"memlock" を参照してください。

ラージ・ページを使用しているときに InterSystems IRIS を再起動する場合は、構成されているすべてのメモリが割り当てられるようにするために、通常は Windows の再起動も必要になります。起動時に、構成されているすべてのメモリ容量を割り当てることができない場合は、少量のメモリで起動が試行されます。このとき、大きなページを使用できる場合とできない場合があります。メッセージ・ログで InterSystems IRIS の最新の起動状況を確認することで、実際に割り当てられているメモリをチェックできます。

ストレージ・アレイを取り巻く状況は、技術的特徴、機能、およびパフォーマンスのオプションにおいて絶えず変化していて、複数のオプションが最適なパフォーマンスおよび復元可能性を InterSystems IRIS にもたらします。このセクションでは、InterSystems IRIS の最適なパフォーマンスおよびデータの復元可能性を実現するための一般的なベスト・プラクティスのガイドラインを示します。アプリケーションの入出力パターンによって、最高のソリューションをもたらすストレージ RAID レベルおよび構成をストレージ・ベンダと共に決定できます。さまざまなファイル・システムがサポートされ、構成に応じて最適化されます。

可能な場合には、ファイル・タイプのブロック・サイズと同等のブロック・サイズを使用することが最良です。ほとんどのストレージ・アレイは指定されたボリューム用に使用できるブロック・サイズが低く制限されていますが、ファイル・タイプのブロック・サイズをできる限り近くできます。例えば、ストレージ・アレイ上の 32KB または 64KB のブロック・サイズは、通常、8KB ブロック形式の IRIS.DAT ファイルを効果的にサポートする実用的なオプションです。ここでの目標は、アプリケーションのニーズに基づいてストレージ・アレイの入出力が過剰または無駄にならないようにすることです。

以下の表は、InterSystems IRIS のインストール環境内でのストレージの入出力の一般的な概要を示しています。

ストレージのボトルネックは、データベースのシステム・パフォーマンスに影響する最も一般的な問題の 1 つです。一般的な誤りは、十分な数の個別ディスクを確保して 1 秒あたりに予期される入出力操作 (IOPS) をサポートするのではなく、データ容量のみに対してストレージをサイズ調整することです。

これらの数値はガイドラインとして提供しており、任意のアプリケーションで理想的なパフォーマンスを実現するためには、許容範囲およびしきい値がこれらの数値よりも高いまたは低い場合があります。これらの数値および入出力の水準は、ご使用のストレージ・ベンダとの議論の開始点として使用してください。

このセクションでは、ストレージ・エリア・ネットワーク (SAN) およびネットワーク接続ストレージ (NAS) に関する考慮事項について説明します。

パフォーマンスと復元可能性を高めるために、InterSystems IRIS 用に少なくとも 4 つの独立したファイル・システムを備えて以下をホストすることをお勧めします。

1. インストール・ファイル、実行可能ファイル、およびシステム・データベース (既定では、ライト・イメージ・ジャーナル (WIJ) ファイルを含む)

2. データベース・ファイル (およびオプションで WIJ)

3. プライマリ・ジャーナル・ディレクトリ

4. 代替ジャーナル・ディレクトリ

さらに、それとは別に WIJ ファイル専用のファイル・システムを構成に追加することもできます。このファイルは、既定で install-dir\mgr ディレクトリに作成されます。該当するファイル・システムに、WIJ を最大サイズまで増加できるだけの十分な空き容量があることを確認してください。WIJ の詳細は、"データ整合性ガイド" の “ライト・イメージ・ジャーナリングとリカバリ” の章を参照してください。

重大なディスク障害が発生してデータベース・ファイルを破損した場合、バックアップからのリカバリにおいてジャーナル・ファイルが重要な要素になります。したがって、データベース・ファイルおよび WIJ が使用するデバイスから独立したストレージ・デバイスにプライマリ・ジャーナル・ディレクトリおよび代替ジャーナル・ディレクトリを配置する必要があります(WIJ の損傷によってデータベースの整合性が損なわれる可能性があるため、ジャーナルは WIJ から独立させる必要があります)。 代替ジャーナル・デバイスを使用すると、プライマリ・ジャーナル・デバイスでのエラーの後でもジャーナリングを続行できるため、プライマリ・ジャーナル・ディレクトリおよび代替ジャーナル・ディレクトリも相互に独立したデバイスに配置する必要があります。運用上の理由から、これらの異なるデバイスを同じストレージ・アレイ上の異なる論理ユニット (LUN) にすることもできますが、一般的には独立性が高いほど好ましいです (別々の物理ドライブを強く推奨)。別々のジャーナル・ストレージについての詳細は、"InterSystems IRIS データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナリングの最善の使用方法" を参照してください。

ジャーナル・ディレクトリと WIJ ディレクトリは、インストール時には構成されません。これらのディレクトリを InterSystems IRIS のインストール後に変更する方法の詳細は、"InterSystems IRIS データ整合性ガイド" の "ジャーナル設定の構成" を参照してください。

InterSystems IRIS では、データベース・ディレクトリでのシンボリック・リンクの使用はサポートされていません。

一般に、ほとんどのオペレーティング・システムでは 2 つの異なる入出力方式が用意されています。

• バッファ型入出力 — オペレーティング・システムが読み取りおよび書き込みをキャッシュします。プログラム (InterSystems IRIS など) またはユーザが別途指定しない限り、これが通常の動作モードです。

• 直接入出力、同時入出力、またはバッファなし入出力 — 読み取りおよび書き込みがオペレーティング・システムのキャッシュ処理をバイパスします。一部の InterSystems IRIS ファイルでより良いパフォーマンスおよびスケーラビリティ特性が得られます。

利用可能な場合、InterSystems IRIS は直接、同時、またはバッファなし入出力を利用します。ファイル・システムおよびマウント・オプションを選択する際は、ファイルのタイプに応じて、次の点に注意する必要があります。

通常、このオプションを使用できる場合、ファイル・アクセス時間の更新を無効にすることをお勧めします。これは通常、さまざまなファイル・システムで noatime マウント・オプションを使用して実行できます。

アプリケーションはそれぞれ大幅に異なるため、CPU リソース要件の測定方法として、アプリケーションのベンチマーキングおよび負荷テストや、既存のサイトから収集したパフォーマンス統計ほど優れたものはありません。ベンチマーキングも既存の顧客パフォーマンス・データも使用できない場合は、以下のいずれかの計算から始めます。

• 100 人のユーザごとに 1 ～ 2 つのプロセッサ・コア

• 1 秒あたり 200,000 件のグローバル参照ごとに 1 つのプロセッサ・コア

CPU コアの速度と数のどちらを選択するかについては、以下の点を考慮してください。

• アプリケーションが使用するプロセスが多いほど、並行処理と全体のスループットを高めるうえで、コア数の増加の効果が大きくなります。

• アプリケーションが使用するプロセスが少ないほど、高速のコアの効果が大きくなります。

例えば、きわめて多くのユーザが単純なクエリを同時に実行するようなアプリケーションでは、コア数が多い方が効果的ですが、比較的少数のユーザが計算集約型のクエリを実行するようなアプリケーションでは、数が少なくても高速のコアの方が効果的です。複数のプロセスがすべてのコアで同時に実行されているときにリソースの競合がないことを前提とすると、理論上は、高速のコアが多数あれば、どちらのアプリケーションにも効果的です。プロセッサ・コアの数は、サーバにプロビジョニングするメモリを見積もる際の 1 つの要素であるため、コア数を増やすと、追加のメモリが必要になる可能性があります。

プロダクション・システムは、ベンチマークと現在の顧客サイトにおける測定に基づいてサイジングされます。共有ストレージを使用する仮想化では、ベア・メタルと比べて CPU オーバーヘッドがほとんど増加しないため、ベア・メタルの監視から仮想 CPU の要件をサイジングするのが有効です。

個々の VM に最適なコア数を決定する際には、高可用性を実現するために必要なホストの数とコストおよびホスト管理のオーバーヘッドの最小化の間のバランスを取ります。コア数を増やすことによって、後者に反することなく、前者の要件を満たすことができる可能性があります。

仮想 CPU の割り当てには、以下のベスト・プラクティスを適用してください。

• プロダクション・システム、特にデータベース・サーバは使用率が高いと想定されるため、最初に、物理 CPU と仮想 CPU の間で同等の仮定に基づいてサイジングする必要があります。物理 CPU が 6 つ必要であれば、仮想 CPU も 6 つ必要であると仮定します。

• パフォーマンスの最適化に必要な数を超える仮想 CPU を割り当てないでください。多数の仮想 CPU を仮想マシンに割り当てることもできますが、使用されていない仮想 CPU を管理するために (通常は小さな) パフォーマンスのオーバーヘッドが生じる可能性があります。ここで重要なのは、システムを定期的に監視して、仮想 CPU が正しく割り当てられていることを確認することです。

CPU コアを追加してアップグレードすると、クエリの並列実行と呼ばれる InterSystems IRIS の機能を使用することで、向上した処理能力を最も効果的に活用できます。

クエリの並列実行は、CPU コアごとに 1 つのプロセスを生成する、CPU の使用率を最大化するための柔軟なインフラストラクチャを基盤とし、大規模な集約を行う分析作業負荷など、データ量が多い場合に最も効果的です。