IBM Support

(参考) "Not enough memory for full text indexing or search" エラーが発生しサーバーが不安定になる

Technote(トラブルシューティング)


問題

全文検索は、IBM Notes ユーザー、エージェント、ブラウザ、他のサーバーなどから利用されるサービスです。「メモリが不足しています」というエラーは、メモリリソースが使用可能なレベルを超えて消費されていることを示します。
負荷が非常に高いサーバーでは、この使用可能メモリの不足によって、他の機能のメモリリソースにも影響を及ぼします。このため、サーバーが不安定な状況を引き起こします。

HTTP 経由で検索が実施された場合は、JVM も HTTP プロセス内で大量のメモリリソースを必要とするため、影響を受けやすくなります。
検索を実施したときに、GTR レベルでメモリ不足に陥っている場合に、もっとも一般的に出力されるエラーメッセージは、以下のようなものです。

    Full Text message: Memory allocation error. errcode = 3301
    Full Text message: Memory allocation error. errcode = 256
    Not enough memory for full text indexing or search.

GTR (General Text Retrieval) とは、全文検索のための検索エンジンのことです。

症状

複雑な検索構文を使用すると、大量のメモリを消費し、この種のメモリエラーが発生する可能性が高まります。
全文検索で利用可能な検索オプションは豊富ですが、特定の組み合わせを実施すると、メモリリソースが多く消費されます。ワイルドカードの指定は特に注意が必要です。例えば以下のような検索構文、メモリリソースを大量に消費する典型的な例です。

    [Field1] = "aaa*" OR [Field1] = "bbb*" OR [Field1] = "ccc*" OR [Field1] = "ddd*" OR [Field1] = "eee*" OR [Field1] = "fff*" OR [Field1] = "ggg*" OR [Field1] = "hhh*" OR [Field1] = "iii*" OR [Field1] = "jjj*" OR [Field1] = "kkk*" OR [Field1] = "lll*" OR [Field1] = "mmm*" OR [Field1] = "nnn*" OR [Field1] = "ooo*" OR [Field1] = "ppp*" OR [Field1] = "qqq*" OR [Field1] = "rrr*" OR [Field1] = "sss*" OR [Field1] = "ttt*" OR [Field1] = "uuu*" OR [Field1] = "vvv*" OR [Field1] = "www*" OR [Field1] = "xxx*" OR [Field1] = "yyy*" OR [Field1] = "zzz*"

原因


メモリリソースエラーは、検索の複雑さによって発生する可能性が高まります。場合によっては、これらの検索によって、サーバークラッシュに至るレベルの低メモリ状態となることがあります。その他の原因としては、サーバーのメモリ構成、十分な物理メモリの不足、データベースまたは全文索引のサイズ、プラットフォームの制限などが考えられます。

■メモリリソース設定
32 ビットアプリケーションと 64 ビットアプリケーションの一般的なメモリ制限が使用可能メモリに与える影響を下表に示します。


一般的なメモリ制限 32-bit 64-bit
物理メモリ (RAM) 4 GB 128 GB
仮想アドレススペースの合計 (シングルプロセスに基づく) 4 GB 16 GB
32 ビットプロセスあたりの仮想アドレススペース 2 GB (システムが /3GB スイッチでブートされた場合は 3 GB) 4 GB (/LARGEADDRESSAWARE でコンパイルされた場合)

2 GB (それ以外の場合)
64 ビットプロセスあたりの仮想アドレススペース 適用外 8 GB
ページプール 47 MB 128 GB
非ページプール 256 MB 128 GB
システム PTE 660 MB ~ 900 MB 128 GB

この表から、64 ビットで使用できるメモリは、32 ビットよりもはるかに大きいことがわかります。大量のデータセットに対して複雑な照会を使用するアプリケーションは、32 ビット OS ではすぐにメモリを使い果たしてしまいます。また、使用できるメモリのタイプも明らかです。使用可能なメモリを正確に測定して活用する方法は、プロセスメモリの使用量を正確に測定することから始まります。システム管理者は Task Manager で [メモリ使用量] (Mem Usage) の統計を見ますが、[メモリ使用量] はプロセスのメモリスペースに割り当てられた (マッピングされた) メモリ量を示す正確な指標ではありません。[メモリ使用量] は、プロセスによって現在使用されている物理的なメモリ量を表します (PerfMon の [ワーキングセット] (Working Set) と同等です)。

Task Manager と PerfMon のメモリ指標の対応関係を下表に示します。

PerfMon のカウンタ Task Manager のメトリック 説明
[プロセス] - [ワーキングセット] メモリ使用量 プロセスに直接 (現在) 割り当てられている物理メモリ量。このメモリにはページ障害を起こさずにアクセスできます。この数値には、他のプロセスと共有されているページも含まれます。
[プロセス] - [プライベートバイト] 仮想メモリ (VM サイズ) プロセスに割り当てられているプライベート仮想メモリの合計 (物理またはページ)。
[プロセス] - [仮想バイト] N/A プロセスに割り当てられている仮想メモリ全体の合計 (プライベートまたは共有、物理またはページ)。

[メモリ使用量] は物理メモリに基づくので、これにはプロセスのプライベートメモリと共有メモリの両方が含まれる可能性があります。その結果、[メモリ使用量] が [VM サイズ] よりも大きいか小さいかはサーバーアクティビティによって決まります。この数値は、共有メモリセグメントが物理メモリにページングされ、実際に追加メモリが割り当てらなかったという事態によって、突然急上昇することがあります。

PerfMon の [プロセス] - [仮想バイト] カウンタは、プロセスが見ることができるすべてのメモリ (共有またはプライベートのいずれかで物理またはページファイル) を示す唯一の指標です。Task Manager には、この指標と同等のものはありません。この指標は、プロセスのメモリスペースにどれだけの量のメモリが割り当てられているかを真に示しています。Procmon ユーティリティには、プロセス単位で割り当てられている物理メモリと仮想メモリの測定に使用できるプロセス統計も用意されています。


■検索構文とワーキング結果セットのサイズ

なぜ、特定の検索構文が他の構文よりもメモリに大きな影響を与えることがあるのかを理解するために、メモリ消費のテスト用に作成されたサンプルの検索とデータベースを調査しました。データベースのサイズが増加するにつれて、予測どおり全文索引のサイズが増加し、検索結果の平均サイズも増加します。良好な検索パフォーマンスに悪影響を与える原因は以下の通りです。

a. 索引のサイズ
b. 検索の種類/複雑さ
c. 検索結果またはワーキングセットのサイズ
d. 同時検索の数 (検索数/秒で表現)

一般に、IBM Domino の全文検索では、1 回の検索によって見つけられる文書が増加するほど、より多くのメモリリソースが必要となります。次の 2 つのグラフは、以下の「** 仕様」に沿ったデータセットを用いて作成したものです。最初のグラフは、結果セットを生成する 1 つの照会でのメモリ消費を Mb 単位で示し、単一文書が返されるケースと、データベース内の全文書が返されるケースを比較しています。検索結果の文書数が多いと、メモリの消費も大きくなります。

単一文書が返されるケースと、データベース内の全文書が返されるケースを比較

検索構文の複雑さも、メモリ消費の主な要因となりえます。ワイルドカードや「or」などの特定の演算子は、メモリ消費を劇的に増加させます。データベースと索引のサイズも重要な要因です。次のグラフは、単一の複雑な検索を最適化してメモリ消費 (Mb) を減らして、全体のパフォーマンスを改善する方法を示しています。最適化を行うには、使用されている用語/演算子を特定し、同じ結果 (単一文書) を得るために検索構文をどのように改変できるのかを調べて、データまたは照会構文を再編成します。

このテストで利用した検索構文は以下のようなものです。
    一文書のみ検索できる構文: "abdc9"
    すべての文書を検索する構文: "a*"
    複雑な構文:"(a* or b* or c* or abcd*) and ([docnumber] > 1990 and [docnumber] < 1992)"
    一部の最適化: "abcd* and ([docnumber] > 1990 and [docnumber] < 1992)"
    全体の最適化: "([docnumber] > 1990 and [docnumber] < 1992)"

すべてのクエリをこの例のように最適化できるわけではありませんが、検索構文によってこれほどメモリの消費が変わります。


検索クエリの最適化

以下は、同時検索数がパフォーマンスに影響を及ぼすことを示しています。

スレッド数と文書数による検索速度
スレッド数と文書数による検索速度 (1) スレッド数と文書数による検索速度 (2)

** 仕様: メモリリソース比較用のデータセットは、同じ設計を持ち、文書数が 9103 (大: 1.3 Gb)、 5967 (中: 0.603 Gb)、2000 (小: 0.072 Gb) と異なる 3 つのデータベースで構成されています。生成された全文索引のサイズは、それぞれ 235 Mb、119 Mb、17.6 Mb です。

診断

次のデバッグパラメータは、メモリが枯渇する状況になる際に、どの様な検索クエリが実施されたのか把握するために役立ちます。このデバッグは、調査の目的でのみ使用してください。


    DEBUG_THREADID=1
    CONSOLE_LOG_ENABLED=1
    DEBUG_FTV_SEARCH=1

このデバッグパラメータを設定すると、コンソールログに以下のような出力が行われます。
    [185C:000B-1D08] IN FTGSearch

    option = 0x400089
    [185C:000B-1D08] Query: [Field1] = "aaa*" OR [Field1] = "bbb*" OR [Field1] = "ccc*" OR [Field1] = "ddd*" OR [Field1] = "eee*" OR [Field1] = "fff*" OR [Field1] = "ggg*" OR [Field1] = "hhh*" OR [Field1] = "iii*" OR [Field1] = "jjj*"
    OR [Field1] = "kkk*" OR [Field1] = "lll* [185C:000B-1D08] Engine Query: "aaa@F234" * "bbb@F234" * "ccc@F234" * "ddd@F234" * "eee@F234" * "fff@F234" * "ggg@F234" * "hhh@F234" * "iii@F234" * "jjj@F234" * "kkk@F234"
    * "lll@F234" * "mmm@F234" * "nnn@F234" * "ooo@F234" * "ppp@F234" * "qqq@F234" * "rr
    [185C:000B-1D08] FTGmalloc failed, error = 418, size = 44
    [185C:000B-1D08]OUT FTGSearch error = F34

上記のように、複数の条件を指定しているような検索構文は、メモリに多大なインパクトを与えます。

※ DEBUG_NOTEOPEN=5 も設定しないと、データベースの特定ができません。

解決方法

■低メモリ状態を削減する方法

システムメモリからの直接割り当てを許可するための NOTES.INI パラメータを設定します。
このパラメータは、数値フィールドが多数ある大きなデータベースで特に効果的です。このパラメータを設定すると、IBM Notes メモリマネージャを通じてメモリを要求する代わりに、オペレーティングシステムから直接 malloc 呼び出しを使用するようになります。

    FTG_USE_SYS_MEMORY=1


メモリ枯渇によってサーバーが不安定となることを防ぐには

問題報告番号 JSTN8C52GM によって機能強化され、GTR 検索エンジンでのメモリ消費を監視および管理することができるようになりました。システム管理者はこのオプションを使用して、メモリ不足を事前に検出することができます。
  • FTG_CHECK_THREAD_MAX_MEM=1 : GTR 用のメモリ検出/モニタリングを有効にします。
  • FTG_MAX_MB_PER_THREAD=<メガバイト> : 1 つのスレッドに許可される最大メモリ (メガバイト)。デフォルトは 100 です。
  • FTG_MB_PER_THREAD=<メガバイト> : スレッドあたりに許可される平均メモリ量 (メガバイト)。この値はFTG_MAX_MEM_POOL と乗算することによってのみ使用されます。デフォルトは 1 です。
  • FTG_MAX_MEM_POOL=<同時スレッド数> : これを FTG_MB_PER_THREAD の設定値と乗算した値は、同時に行われるすべての全文索引検索スレッド全体に許可されるグローバルメモリを示します。デフォルトは 512 です。

STEP 1:
「FTG_CHECK_THREAD_MAX_MEM=1」を有効にして、許可されるデフォルトのメモリ割り当てを超える特定の検索構文を検出し、消費メモリを明らかにします。これは、特定の検索が原因となっている場合に推奨されるトラブルシューティングオプションです。
また、「FTG_MAX_MB_PER_THREAD= <メガバイト>」は、1 つのスレッドに許可される最大メモリです。デフォルトは 100 MB ですが、メモリの大量消費が疑われる検索を検出するために、一時的に低い値に設定することができます。
「FTG_CHECK_THREAD_MAX_MEM=1」を設定すると、サーバーコンソールで「Show Statistics FT」コマンドによって、メモリ消費の統計が表示できるようになり、リソース消費の監視強化に役立ちます。

STEP 2:

サーバーの使用可能なセッション数を制限します。
「FTG_MB_PER_THREAD= <メガバイト>」は、許可される最大アクティブセッション数に基づくことがあります。この設定と同時スレッドの「FTG_MAX_MEM_POOL」を組み合わせることで、同時に行われるすべての全文索引検索スレッド全体に許可されるグローバルメモリが設定され、各スレッドの使用可能なメモリリソースがサーバーベースで最大化されます。


■関連文書
原文:
(英文)「Server instability accompanied by memory allocation errors such as "Not enough memory for full text indexing or search"」(Technote #1634309)

この文書は、米国 IBM 社の資料を翻訳した参考文書です。日本語環境での検証は行っておりませんのでご注意ください。翻訳元の文書は、関連文書のリンクよりご参照ください。

Document information

More support for: IBM Domino
Full Text Index

Software version: 9.0

Operating system(s): AIX, Linux, Solaris, Windows

Software edition: All Editions

Reference #: 1976880

Modified date: 04 January 2017


Translate this page: