（参考）バックアップアプリケーションの実行後の低メモリー状態によるサーバークラッシュ

Lotus Domino サーバーがクラッシュしています。NSD (Notes System Diagnostic) ログの致命的なコールスタックは少し異なりますが、一貫してメモリーアロケーション関数 (たとえば、AllocDBlock) で失敗しています。
NSD ログの上位 10 の共有メモリーセクションを調べると、ブロックタイプ 0x82e9 が非常に多く使用されていることがわかります。このブロックの名前は BLK_NSF_BACKUP_CONTEXT で、サードパーティーアプリケーションが Lotus Domino API 関数を用いてデータベースのバックアップを実行するときに使用されます。

この問題は、問題報告番号 DSTT6APL83 として Quality Engineering に報告され、下記のリリースで修正されています。

修正:6.5.5 Fix Pack 2 (FP2); 6.5.6; 7.0.2; 8.0

Lotus Notes/Domino 障害修正リスト 6.5.5 FP2 より抜粋

問題報告番号 DSTT6APL83 - サーバー
この修正により、ディスクの一時ファイルを使用する前に消費するバックアッププロセスの共有メモリの最大量を制御する Notes.ini 変数が提供されます。Notes.ini 変数「NSF_Backup_Memory_Constrained=1」を使用すると、この機能に対して 20 MB のデフォルトサイズが設定されます。このサイズの調整は、Notes.ini 変数「NSF_Backup_Memory_Limit」によって行います。デフォルト値は、NSF_Backup_Memory_Limit=20000000 です。


現在、次の notes.ini パラメーターを使用して、バックアッププロセスがディスク上の一時ファイルを使う前に消費する共有メモリーの最大量を制御できます。

NSF_BACKUP_MEMORY_CONSTRAINED=1
NSF_BACKUP_MEMORY_LIMIT=size

size はバイト単位で、デフォルトは 20 MB です。このサイズに達すると、一時ファイルの使用が開始されます。この値は大幅に増加させないでください。あるケースでは、お客様が「NSF_BACKUP_MEMORY_LIMIT=1073741824」という設定を使用しました。この設定により、サーバーのクラッシュが続きました。IBM は、このパラメーターには 300 MB よりも大きな値を設定しないことをお勧めします。実際に、デフォルト値が不十分だと判断されるまでは、このパラメーターをデフォルト値のままにしておくことを推奨します。問題が発生した時点で、パラメーターの設定を 100 MB から開始します。高すぎる値を設定すると、逆にクラッシュを招くことになります。

この動作は Lotus Domino 7.x でも発生します。この問題は間接的に修正されていますが、この notes.ini パラメーターの実装が必要です。

サードパーティーアプリケーションが NSF ファイルのバックアップを開始するとき、NSF への各更新により、更新されるディスク上のブロックの「before image」状態が Lotus Domino によって共有メモリーに記録されます。これは、バックアップアプリケーションが NSF のバックアップを完了するまで続行します。
スケジュール済みエージェントを使用したり、compact、fixup、updall、またはその他の任意のメンテナンスタスクを実行すると、バックアップ中の NSF に大量の更新が発生し、Lotus Domino によって非常に多くのディスク状態情報が共有メモリーに書き込まれることがあります。この結果、プロセス用のアドレス可能なすべての仮想メモリーが消費されてしまいます。このようになると、最終的に Lotus Domino の Panic が発生します。たとえば、Tivoli Data Protector (domdsmc タスク) が大きなデータベースをバックアップしているときに、エージェントが同じデータベースの多数の文書を変更すると、クラッシュが発生する可能性があります。

ベストプラクティスとして、バックアップ時に実行がスケジュールされているメンテナンスタスクを制限するだけで、通常はこの Panic を回避できます。

メモ:domdsmc が admin4.nsf (1.5 GB) をバックアップしている際に updall -R を実行したために、この問題が発生したケースがありました。updall のスケジュールを変更し、バックアップとの重複を避けることで、この問題は解決しました。

まとめると、バックアッププロセス中にメンテナンスまたはエージェントが大きなデータベースの 1 つにアクセスすると、バックアップの最中にそのデータベースへの変更が発生します。これにより、バックアップはこれらの変更にも対応しなくてはならず、共有メモリーの使用量が増加します。この結果、バックアップが失敗したり、Lotus Domino がクラッシュする可能性が高まります。


■ 対策
1 つの回避策としては、バックアップのみを実行し、データベースへのタスクの処理を一切停止する時間を設けることです。バックアップ中のデータベースで発生する変更が少なくなると、バックアップソフトウェアがバックアップを完了させるために必要な時間も短縮されます。

バックアップの失敗または Lotus Domino のクラッシュが頻繁に発生する非常に大規模なデータベースについては、次の回避策をご検討ください。

1. 非常に大規模なデータベースでは、バックアップの直前または直後を避けてメンテナンスするようスケジュールを設定します。
Lotus Domino のメンテナンスは、次の 3 つの方法で起動できます。

a. Notes.ini* (例: ServerTasksAt2=UpdAll)
b. プログラム文書
c. 手動

* Lotus Domino のより新しいバージョンにサーバーをアップグレードすると、定期保守用のデフォルトエントリーが notes.ini ファイルに戻されます。バックアップを計画している時間に実行するために、これらのエントリーを再調整している場合は、アップグレードをメンテナンスする際に、必ず notes.ini のメンテナンスエントリーを希望の設定に再設定してください。

2. データベースへのアクセスが少ない時間帯にバックアップするようスケジュールを設定します。

3. バックアップ中に影響するエージェントのスケジュールを設定します。
バックアッププロセス中にエージェントがデータベースに定期的に変更を加えるケースでは、時間についての次の点を考慮してください。

a. エージェントを調べ、特定のデータベースで多数またはすべての文書に実行されるエージェントのスケジュールを変更し、バックアップ中には実行されないようにします。

b. バックアップ中にエージェントを実行しなくてもよい場合は、バックアップを開始する前に AMGR タスクを終了するようプログラム文書を設定できます。次に、別のプログラム文書を使用して、タスクを再ロードします。これにより、バックアップ中のエージェントによる問題を避けることができます。

AMGR を終了するプログラム文書は、次のように設定します。
「基本」タブ:
プログラム名: nserver
コマンドライン: -c "tell amgr quit"

AMGR をロードするプログラム文書は、次のように設定します。
プログラム名: amgr

(英文)「Server crashes due to low memory condition after backup application runs」(Technote #1211241)