Skip to main content

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

InterSystems SQL でアプリケーションを開発および実行する場合、自由に使用できるシステム・リソースについて考慮し、これらを管理して、システムのパフォーマンスを最適化する必要があります。このページは、特定のワークロードに必要なリソースを見積もったり、ワークロードで利用可能なリソースを最適化したりするのに役立ちます。

インスタンスを導入する前に、次のセクションを参照して、最適なパフォーマンスの実現に必要なリソースを見積もることができます。

次のセクションでは、導入時または導入後の共有メモリの構成プロセスについて説明します。

次のセクションで説明するとおり、リソースの使用量を定期的に監視することで、パフォーマンスを最適化できます。

メモリの計画

ここでは、システム・メモリ・リソースの計画に関するガイドラインを示します。メモリ・リソースについて特に注意が必要な特定のワークロード・シナリオについても説明します。これらのガイドラインを使用することで、適切にリソースを割り当てることができます。

メモリ計画の目的は、各ホストで実行されるすべてのエンティティに、すべての通常の動作環境下で十分なメモリをホスト上で提供することです。これは、パフォーマンスと可用性の両方における重要な要素です。共有メモリの割り当てを決定したら、導入中または導入後に適宜共有メモリを構成する必要があります。導入後は、定期的に動作中の実際のメモリ使用量を確認および監視し、必要に応じて調整する必要があります。

Important:

インターシステムズ製品では、メモリ・バルーニングやオーバープロビジョニングはサポートしていません。インターシステムズ製品では、すべての仮想化プラットフォームおよびコンテナ化プラットフォームに 100% のメモリ予約が必要です。

Linux システムで十分な物理メモリを構成しておらず、たびたび限界付近に達している場合、ライト・デーモンや CSP サーバ・プロセスなど、長時間実行される InterSystems IRIS プロセスのうち、通常動作で多くのメモリにアクセスするものを、OOM killer が誤って問題の原因と判断し、それらを終了させるリスクがあります。これにより InterSystems IRIS インスタンスの障害が生じ、その後の開始時にクラッシュ回復が必要となります。

ただし、OOM killer を無効にすることはお勧めできません。この安全メカニズムにより、メモリの不足時にオペレーティング・システムのクラッシュを回避し、ユーザが介入して InterSystems IRIS を通常動作に戻す機会が与えられるためです。この問題を回避するには、OOM killer が機能することがないよう、十分な物理メモリとスワップ領域を構成することをお勧めします(詳細は、"インターシステムズ製品のプロセス・メモリ" を参照してください)。

共有メモリの割り当て

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

データベース・キャッシュ (globals)

データベース・キャッシュ (グローバル・バッファ・プールとも呼ばれます) に割り当てられたメモリは、データのバッファリングに使用されます。

この既定値は控えめな見積もりであり、このパラメータは、システムのサイズとアプリケーションのニーズに基づいて調整する必要があります。一般に、システム・メモリ全体のかなりの部分をデータベース・キャッシュに割り当てる必要があります。データベース・キャッシュは、共有メモリの割り当ての大部分を占めます。データベース・キャッシュが適切なサイズであれば、他の共有メモリのパラメータを既定値から調整する必要はありません。

ルーチン・キャッシュ (routines)

ルーチン・キャッシュに割り当てられたメモリは、サーバ側プロセスが実行するルーチンとクラスのバッファリングに使用されます。

このパラメータの既定の設定では、データベース・キャッシュのサイズに応じて適切な量が割り当てられます。

共有メモリ・ヒープ (gmheap)

共有メモリ・ヒープに割り当てられたメモリは、グローバル・マッピング、データベース名とディレクトリ情報、セキュリティ・システムなど、必要に応じてさまざまな目的に使用されます。

いくつかの例外を除いて、これは既定値のままにする必要があります。既定値では、データベース・キャッシュのサイズに応じて適切な量が割り当てられます。

このパラメータを既定値から調整する必要があるのは、アプリケーションで多数の SQL クエリを使用する場合や、並列デジャーナリングを有効にすることを計画している場合のみです。これらの場合は、追加メモリを gmheap に割り当てる必要があります。詳細は、"並列クエリ処理の構成" の "共有メモリの考慮事項"、および "並列デジャーナリングのシステム要件" を参照してください。

ジャーナル・バッファ (jrnbufs)

ジャーナル・バッファに割り当てられたメモリにより、メモリ内に保持できるジャーナル・データの量が決まります。

このパラメータの既定値は 64 MB であり、通常はこの量で十分です。

共有メモリ合計の見積もり

これらの各パラメータの初期設定を決定したら、次の式を使用して、インスタンスの合計共有メモリ要件を見積もることができます。(MaxServers と MaxServerConn によって、インスタンスから、およびインスタンスへ、それぞれ許容される ECP 接続の最大数が指定されます。既定値は、前者が 2、後者が 1 です。)

globals*1.08 + routines*1.02 + gmheap (MB 単位) + jrnbufs + (MaxServers + MaxServerConn)*2 + 300

実際のプロセス・メモリおよび共有メモリの使用量は、上記の見積もりとは異なる可能性があります。特に次のことに留意してください。

  • データベース・キャッシュ (globals) の場合、既定のデータベース・ブロック・サイズの 8 KB に乗数 1.08 が適用されます。この係数は、ブロック・サイズが大きい場合は小さくなります。データベース・キャッシュを許可し、これを複数のブロック・サイズに割り当てる場合、効果的な乗数はより小さくなります。

  • 共有メモリ・ヒープのサイズは、ホストの CPU の数に応じて自動的に増加される可能性があります。

"メモリ使用量の確認と監視" では、インスタンスの実際のプロセスおよび共有メモリの使用量の確認方法について説明しています。

ヒュージ・ページおよびラージ・ページの構成

サポートされていれば、ヒュージ/ラージ・メモリ・ページの使用は、パフォーマンスにおいて非常に有益であり、パフォーマンスが優先されるシステムには強くお勧めします。

既定では、ヒュージ/ラージ・ページが構成されている場合、InterSystems IRIS は開始時にそれらの利用を試みます。十分な領域がない場合、InterSystems IRIS は標準のページに戻ります。ただし、memlock パラメータを使用すれば、この動作を制御することができ、ヒュージ/ラージ・ページの割り当てに失敗した場合は開始時に失敗します。

Windows では、ラージ・ページの量は自動的にスケーリングされます。IBM AIX® および Linux ディストリビューションでは、ユーザがヒュージ/ラージ・ページの量を構成する必要があります。ヒュージ/ラージ・ページの割り当ては、共有メモリの割り当てよりも若干大きくする必要があります。共有メモリとまったく同じ量のヒュージ/ラージ・ページを割り当てた場合、バージョン間での共有メモリの小さな変更を考慮して、アップグレード時に調整が必要になることがあります。アップグレードのたびに再計算しなくて済むように、この潜在的な差異を考慮して、数 MB を追加で割り当てます。割り当てる量を決定するには、以下の 2 つのオプションがあります。

  • 共有メモリを見積もって、それに応じて割り当てるヒュージ/ラージ・ページの量を決定します。

  • ヒュージ/ラージ・ページを有効にせずに InterSystems IRIS を導入し、messages.log ファイルに表示された共有メモリの割り当てを記録し、それに応じてヒュージ/ラージ・ページを割り当てて、システムを再起動します。

ヒュージ/ラージ・ページを構成するには、お使いのシステムの関連ドキュメントを参照してください。

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

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> は、ハードウェアでサポートされるラージ・ページのサイズをバイト単位で指定します。

Note:

動的 LPAR (Logical PARtitioning ： 論理区画) をサポートするシステムでは、-r のオプションを省略して、システムを再起動することなく動的にラージ・ページを構成できます。

例えば、以下のコマンドは、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 は必要ありません。

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

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

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

Important:

2.6.38 カーネルを使用する一部の Linux ディストリビューションには、透過的ヒュージ・ページ (THP) が導入されていて、ヒュージ・ページの作成、管理、および使用が自動化されます。ただし、THP は InterSystems IRIS に割り当てられたメモリの大半を構成する共有メモリ・セグメントを処理しません。また、実行時にメモリ割り当ての遅延を引き起こすことがあり、パフォーマンスに影響する可能性があります。この影響は、ジョブまたはプロセスの作成頻度が高いアプリケーションでは顕著に表れます。このような理由から、InterSystems IRIS をホストするすべてのシステムで THP を無効化するようにお勧めします。このトピックの詳細は、InterSystems Developer Community の "Linux Transparent huge pages and the impact to InterSystems IRISOpens in a new tab" を参照してください。

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

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

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

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

  2. ヒュージ・ページ数を変更します。

    ページ数のシステム・パラメータを直接変更できます。例えば、2,056 ページのヒュージ・ページを割り当てるには以下のように指定します。 

    # echo 2056 > /proc/sys/vm/nr_hugepages
    Note:

    また、以下のように sysctl(8) を使用することもできます。 

    # sysctl -w vm.nr_hugepages=2056

    ヒュージ・ページは連続したページとして割り当てる必要があります。また、割り当て後には再起動が必要になることがあります。したがって、割り当てを確実なものとして恒久的な変更とするには、以下の手順に従います。

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

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

    2. システムを再起動します。

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

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

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

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

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

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

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

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

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

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

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

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

Windows でのラージ・ページの構成

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

Note:

InterSystems IRIS が既定の SYSTEM アカウントで動作している場合は、既定で “メモリ内のページのロック” 特権が付与されています。

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

並列デジャーナリングのシステム要件

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

Note:

並列デジャーナリングにより複数のアップデータが同じデータベース内で別のグローバルを記録できるため、少数のデータベースで作業する場合でもスループットを向上させることができます。

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

CPU の最小数 最小データベース・キャッシュ・サイズ 最小空き gmheap アップデータ数
8 0 GB 0.4 GB 2
9 0 GB 0.6 GB 3
12 0 GB 0.8 GB 4
15 160 GB 1.0 GB 5
18 192 GB 1.2 GB 6
21 224 GB 1.4 GB 7
24 256 GB 1.6 GB 8
27 288 GB 1.8 GB 9
30 320 GB 2.0 GB 10
33 352 GB 2.2 GB 11
36 384 GB 2.4 GB 12
39 416 GB 2.6 GB 13
42 448 GB 2.8 GB 14
45 480 GB 3.0 GB 15
48 512 GB 3.2 GB 16
Note:

システムが搭載する CPU の数の決定については、"CPU (プロセッサ)" を参照してください。

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

ストレージの計画

現在、従来の磁気回転方式の HDD デバイスから SSD および PCIe フラッシュ・ベース・デバイスに至るまで多くのストレージ技術が利用されています。さらに、複数のストレージ・アクセス技術には、NAS、SAN、FCoE、直接接続、PCIe、ハイパー・コンバージド・インフラストラクチャを備えた仮想ストレージなどがあります。

ご使用のアプリケーションに最適なストレージ技術は、アプリケーション・アクセス・パターンで決まります。例えば、ランダム読み取りが大部分であるアプリケーションの場合、SSD またはフラッシュ・ベース・ストレージが理想的なソリューションです。また、書き込みが非常に多いアプリケーションの場合、従来の HDD デバイスが最適です。

このセクションでは、以下を含む、アプリケーションに最適なストレージ・ソリューションのガイドラインとベスト・プラクティスを示します。

ストレージの構成

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

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

Important:

パフォーマンスと復元可能性を最適化するために、ジャーナル・ファイルは別個のストレージ・デバイスに配置する必要があります。

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

入出力の種類

タイミング

方法

留意事項

データベースの読み取り (ほぼランダム)

インタフェースおよびユーザの処理ごとに継続的

インタフェース・クエリまたはユーザの処理によってディスク入出力が開始され、データを読み取り

データベースの読み取りは、デーモンが処理する Web ページ、SQL クエリ、または直接ユーザ処理によって実行されます。

データベースの書き込み (順序付けされるが非連続で実行)

約 80 秒ごとまたは保留中の更新がデータベース・キャッシュのしきい値のパーセントに達したとき (先に基準を満たした方)

 データベース・ライト・デーモン

(8 個のプロセス)

データベースの書き込みは、ライト・デーモンと呼ばれる一連のデータベース・システム・プロセスによって実行されます。ユーザ処理によってデータベース・キャッシュが更新され、トリガ (時間またはデータベース・キャッシュのパーセントが一杯になったとき) によってライト・デーモンを使用してディスクの更新が実行されます。通常、更新レートに応じて、書き込みサイクル中に数 MB から数 GB 書き込む必要があることを想定しています。

WIJ 書き込み (連続)

約 80 秒ごとまたは保留中の更新がデータベース・キャッシュのしきい値のパーセントに達したとき (先に基準を満たした方)

 データベース・マスタ・ライト・デーモン (1 個のプロセス) ライト・イメージ・ジャーナル (WIJ) は、データベースの書き込みサイクル中のシステム障害から物理データベース・ファイルの整合性を保護するために使用されます。書き込みは、約 256KB のサイズごとに行われます。

ジャーナル書き込み (連続)

ジャーナル・データの 64KB ごとまたは 2 秒ごと、または ECP またはアプリケーションの同期要求

 データベース・ジャーナル・デーモン (1 個のプロセス)

ジャーナル書き込みは連続で、4KB から 4MB までサイズが変化します。1 秒あたり数十回の書き込みから、ECP および個別のアプリケーション・サーバを使用した非常に大きい配置の場合には 1 秒あたり数千回の書き込みまでになる場合があります。

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

入出力の種類

平均応答時間

最大応答時間

留意事項
データベースのランダム読み取り (キャッシュ処理なし)

<=1 ms

<=2 ms

データベース・ブロックは固定 8KB、16KB、32KB、または 64KB (ホストでのデータベース・キャッシュは大きいため、ディスクへのほとんどの読み取りはキャッシュされません)。
データベースのランダム書き込み (キャッシュ処理あり)

<=1 ms

<=2 ms

すべてのデータベース・ファイルの書き込みは、ストレージ・コントローラのキャッシュ・メモリによってキャッシュされることが想定されます。
ジャーナル書き込み

<=1 ms

<=2 ms

ジャーナル書き込みは連続で、4KB から 4MB までサイズが変化します。

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

ストレージの接続

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

SAN ファイバ・チャンネル

各ホストから SAN スイッチまたはストレージ・コントローラに複数のパスを使用します。1 つのカードの障害から保護するために複数の HBA を使用すると保護のレベルが上がりますが、最小の推奨事項は、少なくとも 1 つのデュアルポート HBA を使用することです。

ストレージ・アレイ・レイヤに復元可能性をもたらすには、ストレージ・コントローラの障害から保護し、ファームウェアの更新などのアクティビティのためのメンテナンス期間でさえも継続してアクセスを提供するために、アクティブ/アクティブ構成またはアクティブ/パッシブ構成のいずれかのデュアル・コントローラを備えたアレイをお勧めします。

冗長性を実現するために複数の SAN スイッチを使用する場合、推奨される一般的な方法は、各スイッチを個別の SAN ファブリックにし、不具合のある構成の変更を 1 つのスイッチにとどめ、両方のスイッチに影響してすべてのストレージ・アクセスが妨げられることがないようにすることです。

ネットワーク接続ストレージ (NAS)

これは、一般的に 10GB のイーサネットが使用可能であり、最高のパフォーマンスを実現するためには、10GB のスイッチおよびホスト・ネットワーク・インタフェース・カード (NIC) をお勧めします。

専用のインフラストラクチャを用意して、LAN の通常のネットワーク・トラフィックからトラフィックを分離することもお勧めします。こうすることによって、ホストとストレージの間の NAS のパフォーマンスを予測できます。

ジャンボ・フレームのサポートを含めて、ホストとストレージの間の十分な通信を提供することも必要です。

多くのネットワーク・インタフェース・カード (NIC) は TCP オフロード・エンジン (TOE) をサポートします。TOE のサポートは、普遍的に利点があると見なされているわけではありません。使用可能なサイクル (またはその欠如) に対するオーバーヘッドおよびゲインは、サーバの CPU によって大きく変化します。また、TOE のサポートは役に立つ期間が制限されます。これは、指定された NIC の TOE パフォーマンス・レベルにすぐにシステム処理能力が追いつくまたは多くの場合追い越すためです。

ファイル・システムの分離

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

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

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

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

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

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

Note:

UNIX®、Linux、および macOS プラットフォームでは、/usr/local/etc/irissys は InterSystems IRIS レジストリ・ディレクトリであるため、ローカル・ファイル・システム上に配置する必要があります。

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

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

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

Note:

現在のストレージ・アレイ (特に、SSD/フラッシュ・ベースのアレイ) では、前に推奨した種類の独立性は必ずしも可能ではありません。このような技術を使用する場合、パフォーマンスと復元可能性を高めるために、ストレージ・ベンダの推奨事項を参照して、これに従ってください。

バッファ型入出力と直接入出力

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

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

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

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

ジャーナル・ファイル

一部のプラットフォームには、このリリース用のドキュメント "インターシステムズのサポート対象プラットフォーム" の "サポートされているファイル・システム" に記載のとおり、最適なパフォーマンスを実現するための直接入出力または同時入出力のマウント・オプションの使用に関して特別な推奨事項があります。その他のプラットフォームでは、InterSystems IRIS はジャーナル・ファイルには適切に、自動的に直接入出力を使用します。特別な考慮事項は必要ありません。

データベース (IRIS.DAT ファイル)

InterSystems IRIS は独自のデータベース・キャッシュを使用するため、データベース・ファイルに対してオペレーティング・システム・レベルのバッファ処理を行うことに優位性はありません。データベース・キャッシュに十分な容量を割り当ててください。また、お使いのプラットフォームでの直接入出力の最適な使用方法について確認してください。

  • Linux — InterSystems IRIS は、データベース・ファイルに直接入出力を使用します。

    これは、VxFS ファイル・システムを使用している場合、cio マウント・オプションを使用して同時入出力のファイル・システムをマウントすることによってオーバーライドできます。

  • macOS — InterSystems IRIS は、データベース・ファイルにバッファ型入出力を使用します。

  • Windows — InterSystems IRIS は、データベース・ファイルにバッファなし入出力を使用します。

  • IBM AIX — InterSystems IRIS は、cio ファイル・システムのマウント・オプションが使用されているかどうかにかかわらず、データベース・ファイルに同時入出力を使用します。

    Note:

    AIX では、InterSystems IRIS の実行中に、データベース・ファイルを読み取るために外部コマンドが使用されるという特殊な構成では、その外部コマンドが失敗する可能性があります。これは、同時入出力のために、データベース・ファイルが InterSystems IRIS によって開かれているためです。一例を挙げると、高度なバックアップまたはスナップショット・ユーティリティがあるにもかかわらず、cp コマンドを使用して外部バックアップを実行する場合です。cio オプションを使用してファイル・システムをマウントすると、すべてのプログラムが同時入出力でファイルを開くように強制されるため、この問題が解決します。

インストール・ファイルと実行可能ファイル

InterSystems IRIS は、これらのファイルにバッファ型入出力を使用します。直接入出力マウント・オプションをサポートするプラットフォームでは、これらのファイルにバッファ型入出力を使用することが推奨されます。

外部アプリケーション・ファイルおよびストリーム

通常、外部ファイルを使用するアプリケーションは、バッファされたファイル・システムに配置されたファイルを利用します。

noatime マウント・オプション

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

InterSystems IRIS の CPU サイジングおよび拡張

InterSystems IRIS は、システムの全体的な CPU 処理能力を最大限に活用するように設計されています。すべてのプロセッサやプロセッサ・コアが同様であるわけではありません。クロック速度、コアあたりのスレッド数、プロセッサのアーキテクチャなど、表面上の差異があるだけでなく、仮想化の影響も異なります。

CPU の基本的なサイジング

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

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

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

Important:

これらの推奨値は、アプリケーション固有のデータを使用できない場合の開始点にすぎず、使用しているアプリケーションに適しているとは限りません。アプリケーションのベンチマーキングと負荷テストを実施して、正確な CPU 要件を確認することが非常に重要です。

コアの数と速度のバランス

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

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

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

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

CPU の仮想化に関する考慮事項

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

Note:

ハイパー・コンバージド・インフラストラクチャ (HCI) の導入については、HCI ストレージ・エージェントまたはアプライアンスのオーバーヘッドに対応するために、ホストレベルの CPU 要件の見積もりに 10% を加算してください。

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

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

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

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

クエリの並列実行でのコア数の活用

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

クエリの並列実行
9 コアのサーバの場合、クエリは 9 個のサブクエリに分解され、並列処理されて単一の結果が返されます

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

InterSystems IRIS 共有メモリの構成

前のセクションで説明した共有メモリ割り当ては、導入時に上記パラメータを構成マージ・ファイルに含めることで構成マージ機能を使用して実行します。以下に例を示します。

[config]
globals=0,0,5000,0,0,0
gmheap=165888
jrnbufs=64
routines=151
Note:

gmheap の値は KB 単位、その他は MB 単位です。globals の値内の複数のフィールドは、さまざまなデータベース・ブロック・サイズに対するデータベース・キャッシュのサイズを指定します。一般的には、ここで示すように、8 KB のブロック・サイズのキャッシュのみが指定されます。

ファイル内の設定は、導入時に既定の構成パラメータ・ファイル (CPF) にマージされるため、インスタンスの初回起動時には、指定されたパラメータ値と適宜割り当てられた共有メモリを使用して起動されます。(構成マージは、自動導入では大変便利で、異なるマージ・ファイルを適用することで、同じソースから異なる構成のインスタンスを導入することができます。)

導入時に構成マージを使用してこれらの割り当てが行われない場合、割り当ては導入の直後に以下のようにして指定できます (いつでも指定できるわけではありません)。

これらのいずれかの方法で必要なすべての変更を行った場合、それらを適用するには、インスタンスを再起動します。

メモリ使用量の確認と監視

プロダクション・システムにおけるパフォーマンスの問題は、多くの場合、アプリケーションに必要なメモリが不足していることが原因です。1 つ以上の InterSystems IRIS インスタンスをホストするサーバにメモリを追加すると、データベース・キャッシュ、ルーチン・キャッシュ、共有メモリ、またはいくつかの組み合わせに、より多くのメモリを割り当てることができます。データベース・キャッシュが小さすぎて作業負荷の作業セットを保持できない場合は、クエリがディスクにフォールバックされて、必要なディスク読み取りの回数が大幅に増加し、深刻なパフォーマンスの問題が生じます。そのため、これが、メモリを追加する主な理由となることがよくあります。並列ジャーナリングやクエリの並列処理を使用する場合などの特定の状況では、共有メモリ・ヒープおよびルーチン・キャッシュを増やすことも役立つ場合があります。

インスタンスの起動の最後に、インスタンスの共有メモリ割り当ての概要を示す、以下のようなメッセージがメッセージ・ログに書き込まれます。これには、"InterSystems IRIS 共有メモリの構成" の例の値が組み込まれています。

11/06/21-10:59:37:513 (91515) 0 [Generic.Event] Allocated 5682MB shared memory using Huge Pages
11/06/21-10:59:37:514 (91515) 0 [Generic.Event] 5000MB global buffers, 151MB routine buffers, 
  64MB journal buffers, 289MB buffer descriptors, 162MB heap, 6MB ECP, 9MB miscellaneous
Note:

バッファ記述子という用語は、グローバル、ルーチン、およびジャーナル・バッファに関連する制御構造を表します。ヒープの数は、自動調整されるため、gmheap で指定した値より大きくなる可能性があります。

構成マージを使用して必要な共有メモリ割り当てで導入を行う場合、これらのメッセージを確認することで、意図した割り当てになっているかを確認できます。導入に続いて共有メモリを割り当てる場合は、変更後に開始する再起動に続いて、これらの割り当てを確認できます。

システムがテスト環境またはプロダクション環境で稼働したら、InterSystems IRIS 内の実際のメモリ使用状況を以下のように確認できます。

  • インスタンスの共有メモリ使用状況を表示するには、管理ポータルの [システム使用状況モニタ] ページに移動し ([システムオペレーション]→[システム使用] の順に選択します)、[共有メモリヒープ使用状況] ボタンをクリックして、[共有メモリヒープ使用状況] ページを表示します。このページに表示される情報については、"監視ガイド" の "共有メモリ・ヒープ使用状況" を参照してください。

  • InterSystems IRIS プロセスによる最大メモリ使用状況を大まかに見積もるには、実行プロセスのピーク数に、プロセスあたりの最大メモリ (bbsiz) の既定の設定である 262.144 MB をかけます。ただし、この設定を “無制限” を表す -1 に変更している場合 ("プロセス当たりの最大メモリの設定" を参照) (これはインターシステムズがほとんどのプロダクション・システムに推奨する設定です)、これらのプロセスに必要な最大メモリ使用状況を見積もるには、より詳細な分析が必要です。InterSystems IRIS プロセスが使用するメモリの詳細は、"インターシステムズ製品のプロセス・メモリ" を参照してください。

Important:

システムが通常のプロダクション・ワークロード下にあるときに、システム・モニタによって、「Updates may become suspended due to low available buffers」というアラートや、「Available buffers are getting low (25% above the threshold for suspending updates)」という警告が生成される場合は、データベース・キャッシュ (グローバル・バッファ・プール) の大きさが十分でないため、キャッシュを増やしてパフォーマンスを最適化する必要があります。

データの圧縮とストレージ・コストの削減

ストレージ・コストは、特にクラウド・インフラストラクチャを使用している場合、アプリケーションのオーバーヘッドの大部分を占めることがよくあります。慎重に監視し、定期的にデータを圧縮することにより、これらのコストを削減できます。InterSystems IRIS では、データを圧縮するいくつかの方法を提供していますが、それぞれ利点とリスクが異なります。以下の表をガイドとして使用して、個々のアプリケーションに最も適した方法を決定することができます。

方法 利点 リスク
ジャーナルの圧縮

  • ストレージを即座に大幅に削減します。

  • ジャーナル暗号化に適合します。

  • 毎日のジャーナル・ボリュームは頻繁にデータベースの合計より大きくなるため、5:1 を超える圧縮率が可能です。

  • ジャーナル・リストアに必要なオーバーヘッドが増大する可能性があります。

  • ジャーナル・ファイルの内容によっては、圧縮率が低くなる場合があります。

データベース内ストリーム圧縮

  • ストリーム圧縮は、ストリーム・データ型に対してのみ機能します。

  • 新規ストリームのみを圧縮します。

  • コードに対する更新または変更が必要となる場合があります。
データの削除

  • データ・ボリュームが、削除された量だけ直接削減されます。

  • 空き容量の圧縮および削除を使用して、.DAT ファイルのサイズを縮小できる場合があります。

  • データは永久に削除されます。

  • .DAT レベル以外のデータの削除は複雑です。
データのアーカイブ

  • データには引き続きアクセスできます。

  • データはよりコストの低いストレージ・オプションに移行できます。

  • 空き容量の圧縮および削除を使用して、.DAT ファイルのサイズを縮小できる場合があります。

  • アーカイブされたデータにアクセスを試みる際に、遅延が大きくなったり、パフォーマンスが低下することがあります。

  • .DAT レベル以外のデータのアーカイブは複雑です。
グローバルの圧縮

  • グローバル・データはより少数のブロックに統合され、データベースの空き容量が増加します。

  • スペースを節約しつつ、データを維持できます。

  • 空き容量の圧縮および削除を使用して、.DAT ファイルのサイズを縮小できる場合があります。

  • グローバル・ブロック密度が高いと、ランダムな挿入のパフォーマンスが大幅に低下する場合があります。

  • ランダムな挿入またはランダムな削除を伴うグローバルは、定期的に圧縮する必要がある場合があります。

  • ミラーリング時は、グローバルの圧縮は、両方のメンバで実行する必要のあるI/O負荷の高い操作です。

ストレージ・レベルの圧縮

  • 自動的に行われ、最も小さな労力で済みます。

  • ミラー・メンバに同じストレージ・アレイを使用している場合、重複排除機能には大きな利点があります。

  • ストレージ・レベルの暗号化に適合します。

  • ストレージ・レベルの圧縮はベンダから提供されるため、追加の費用がかかる場合があります。

  • すべての追加費用がストレージの節約を上回る損益分岐点を考慮する必要があります。

  • 暗号化データベースは、ストレージ・レベルの圧縮の利点を無効にする可能性があります。

  • .DAT ファイルのサイズは変わりません。

データベース管理は、ストレージのオーバーヘッドを削減する重要なツールです。このトピックの詳細は、"ローカル・データベースの管理" を参照してください。

FeedbackOpens in a new tab