by Carol Zimmet and Amy E Smith
レベル：上級者
対象：Domino R5
原文の掲載：2000年8月1日
ドミノ サーバーは、複雑で広範囲にわたるテクノロジーから成り立っています。ですから、利用できるすべてのオプションを理解するだけでなく、それぞれのサーバー設定でもっともよいオプションを選んだり、ドミノ・コンポーネントの相互関係やそれがサーバーの拡張性に与える影響を理解するということは、管理者にとっては必ずしも簡単なことではありません。
アイリス・ドミノ サーバー・パフォーマンス・チームは、ユーザーの間で、ドミノ サーバーに関しての誤解や、誤った情報が広まっていることに気づきました。同時に、ほとんどのドミノ・ユーザーのサイトが、新機能を利用していないということも明らかになってきたのです。
この記事はいくつかのセクションから成り立っていて、ドミノ管理者やユーザー、コンサルタント、そしてビジネス・パートナーがよく遭遇する問題や、誤解などを解いていきます。また、これらの問題点は、パフォーマンスの観点から見て取り上げています。つまり、これらはドミノ サーバーのパフォーマンスやその装備、そして容量計画に関する決定に直接の影響を及ぼすものです。
各セクションでは、事実をはっきりと提示し、どのように進めていけばいいかをガイドしていきます。また、広くユーザーに利用可能になっていてパフォーマンスに有益であるにも関わらず、あまり使われていないサーバー・オプションを、強調して取り上げています。
さらに、管理者が、より将来大きなスケールで決定を下す際に役立つ、パフォーマンスに関する基本的な考え方のトピックも取り上げています。
ユーザーが自分の環境で問題が生じ、ロータス・カスタマー・サポートに報告する際には、Mem.Allocated と呼ばれるサーバー測定値が使われる場合が多く、この値が物理 RAM の容量を越えている、という報告も多々あります。
名前を見ると、Mem.Allocated (まだ文書化されていません) は、現時点でドミノ サーバーによって割り当てられているメモリーの容量を示すものだと考えてしまうかもしれませんが、そうではありません。
Mem.Allocated は、サーバーが起動されて以来の累計の量であり、しかもエンド・ユーザーによる要求と、サーバーの処理で使われる双方のメモリーを示しています。
ドミノ サーバーがある程度の期間起動していると、Mem.Allocated で報告される値が物理 RAMの容量を越えてしまいますが、これは物理メモリーだけでなく、ドミノに割り当てられた仮想メモリーも含まれているからです。ですから、これは累積の値で、時間と処理によって増えてゆくものなのです。
| 例： | Mem.Allocated = 29,165,024
...
Mem.Free = 27,157,248
Mem.PhysicalRAM = 4,493,312
|
|
Mem.Allocated は、ドミノ サーバーにどれだけのメモリーが割り当てられているかを検知するための簡易的な方法として、少なくとも R4 (おそらくそれ以前だと思いますが) で導入されました。これは アイリスのエンド・ユーザーのグループ内で特にある目的のために使用するものでなければ、また NSF Buffer Pool の値に関連性があるものでもありません。あくまで、簡易的にメモリーの消費の具合をみるためのものです。
Mem.Free は、開放された累積メモリー量を示します。これも同様に、ユーザーが検討すべき内容ではありません。しかし Mem.Free と Mem.Allocated は、ほぼ同じペースで増えていくため、Mem.Free は Mem.Allocated の指標として使うことができます。
プラットフォーム統計 Platform.Memory.KBFree を使って、ドミノ・システムで利用可能になっているすべてのメモリーの推定容量を出してみるとよいでしょう。ドミノ 5.0.2 以降では、Windows NT と Solaris のプラットフォームでの測定もサポートしています。
メモ：Platform.Memory.KBFree の値を採取するには、NOTES.INI に Platform_Statistics_Enabled=1 を追加します。
メモリー統計 Mem.PhysicalRAM （これも文書化されていません) は、システム上の物理メモリーの正確な容量を報告します。
殆どのプラットフォームのベンダーでは、システムの評価にあたっての測定値を設けユーザーに提供しています。( CPU やメモリー、ディスク I/O、ネットワークなど) これを使って、ユーザーは各自のシステムのパフォーマンス評価を行えるようになっています。しかし、ベンダーがこれらの値を低めに設定して、誤解が生じてしまう場合があります。例えば、システム管理者が、ベンダーから示された値のみが正しい値だと思ってしまうケースなどです。
このような測定項目の1つが Page/Sec カウンターで、ドミノだけではなく一般に使用されているシステムの測定項目です。これはメモリー・オブジェクトの一部で、正式には「メモリー参照を解決するために仮想記憶マネージャーがディスクにアクセスする回数」と定義されています (つまり、カレント・メモリーの読み出し、書きこみパスに参照された値がなく、ディスクにアクセスした回数です)。ほとんどのドミノ・システム管理者は、自分が扱っているドミノ・システムの能力を見た上で値を決めるのではなく、ベンダーが決めた値をそのまま使用しています。アイリスでは、Pages/Sec カウンターでのパフォーマンスのばらつきがあり、プラットフォームによって推薦値は異なることを確認しています。
多くのベンダーは、10?20 を Pages/Sec カウンターの適切な値だとしています。ドミノ サーバーのパフォーマンスを実際に見てみると、製品によってはこの適切な値からはみだしているものも見られます。この問題の詳細は、Iris Today の 記事「Optimizing server performance: Handling the curves like a pro」（US） で以前に取り上げられました。この記事では、キャパシティー・プランナーがよりよい決定を下すのに役立つデータも取り上げられています。また、記事中で分析されているベンダーのデータは、推奨システムに沿ったもののみです」 (作業のレスポンス時間が1秒未満で、CPU の利用率が 75% 以下。利用可能なメモリーが4MB 以上)。この記事では、他の基準が適正な値であれば、Pages/Sec 基準がプラットフォームのベンダーが示す適正範囲外であっても問題ではないと述べており、もっと大事なのは1つの測定基準でシステム全体のパフォーマンスを評価しないことだ、と強調しています。
「Handling the Curves」の記事では、ドミノ R4.6 でのデータが使われていますが、ここで取り上げるデータは、R5 のものであり、4.6 とは異なるシステム・プロフィールでの違いが出るようにしてあります。次の図をご覧ください。
上の図は、3種類のベンチマーク・テストの結果です。このテストでは、それぞれ 2500 人、3000 人、そして 4500 人のユーザーで、2時間にわたって観察したものです。このベンチマークで与えた負荷（Workload）は NRPC メールと C&S の負荷です。これらは NotesBench Consortium（US） で現在までに公表されている負荷プロファイルとは異なっていますが、NRPC プロトコルを使用してメールを送るという、基本的な負荷をかける、という点で同様のものです。
| メモ： | ここでの結果は、例として示すために挙げたもので、公表されている結果とは関係ありません。 |
|
ユーザー数が 2500- と 3500- のところでは、Pages/Sec はプラットフォーム・ベンダーで推奨されている値の範囲よりも高い値となっています。ベンダーにとっては、システム上で起動するアプリケーションの数を推定することが難しいため、ベンダーが推奨する値は、実際よりもやや控えめになっています。
次の図は、ドミノ サーバー・プロフィールによって、システムの利用が異なっていることを示しています。これは、実際に本稼動しているシステムが、Web アプリケーション・プロフィールで稼動している様子を表しています。(サーバーは アイリスの Notes.net のものです)
図上の点は、Notes.net の Web サイトをホストしているサーバーのうちのいくつかについて、数日にわたってデータを取ったものです。Pages/Sec についてのデータを、次にまとめました。
| | Server 1 |
Server 2 |
Server 3 |
| 平均 | 89.10 |
83.49 |
52.29 |
| 最大 | 463.63 |
397.11 |
376.27 |
| 最小 | 10.00 |
2.76 |
10.38 |
今回は本稼動しているシステムを例に挙げ、データを取りました。本稼動しているシステムであるため、通常の間隔でデータを取得するにとどめ、システムのレスポンス時間のデータまでは取りませんでした。これは、実行されているアクティビティーのボリュームが大きいため、1秒未満というシステムレスポンス時間の範囲を超えてしまうからです。CPU の利用率と、利用可能メモリーは、上に挙げた範囲内に収まっており、これは本稼動のシステムとしては合格しているといえます。
ここで注目したいのは、異なる負荷のプロファイルによって、値が様々に変化するということです。Iris Today の記事「Optimizing server performance: Handling the curves like a pro」（US）を参考にするとよいでしょう。この記事では様々な負荷プロファイルでの、CPU、メモリー、そしてPages/Sec 値について記されています。
利用可能なメモリーの量を理解し、追加が必要かどうかを判断するためには、この他の測定基準についても考慮することが大切です。Available Bytes と、Commited Bytes を使って、効率良く働いていないメモリーがあるかどうかを調べるのが良いでしょう。
次の表は、2500 人と、3500 人の NRPC ユーザーが動作した状態をシミュレートした際の Available Bytes と、Commited Bytes の概略データです。
| | Available bytes |
% Committed
bytes in use | Committed bytes |
| 平均 | 2,629,185,433.60 |
21.48 |
1,304,857,634.13 |
| 最大 | 2,729,472,000.00 |
21.87 |
1,328,902,144.00 |
| 最小 | 2,601,111,552.00 |
20.13 |
1,222,811,648.00 |
| | Available bytes |
% Committed
bytes in use | Committed bytes |
| 平均 | 2,521,133,563.77 |
23.24 |
1,412,367,216.13 |
| 最大 | 2,605,039,616.00 |
23.61 |
1,434,456,064.00 |
| 最小 | 2,493,661,184.00 |
21.89 |
1,329,868,800.00 |
Available Bytes は、処理に使用可能な物理メモリーの量を示します。正確には、稼動している処理とキャッシュに使われているメモリーを除いた残っているメモリーの量です。仮想メモリーは、実メモリーと、ページング領域から成り立ち、この値が常に (ベンダーによると) 4MB 以下であれば、さらに仮想メモリー (実メモリーと、関連するページング領域の両方) を割り当てられなければなりません。
| メモ： | より多くのメモリーが要求されるサーバー設定では、最低 10MB 必要になります。 |
|
上の図の測定値を見ると、Available Bytes は、許容範囲に入っていることがわかります。パフォーマンス・チームが、メモリーの利用状況を測定するときには、主にこの値を使っています。
Commited Bytes は、使用されている仮想メモリーのサイズを示します。コミット (使用) されたメモリーは、高い確率でハードディスクに一時的に保管されます。このような動作を望まない場合には、予めメモリーを定義しておく必要があります。Commited Bytes は、Commited Limit (利用可能なメモリーの最大値) と比較する必要があります。上に示したサーバーの設定では、Commited Limit は一定の値 (1,781,063 KB) を取ります。Commited Bytes の値が Commited Limits の値に近づいたら、詳しい調査を行うべきでしょう。
提案されたシステム設定に必要なリソースについての質問が、アイリス・ドミノ サーバー・パフォーマンス・チームに多く寄せられます。チームではある機能を取り上げ、それがどのようにさまざまなプラットフォームで稼動するか、ということに焦点を置いて調査しています。この作業の結果として、必要なリソースについて、質問に関する情報や知識を提供しています。
パフォーマンス・チームは、リリース前のコード、特に製品版ではない環境で作業を行い、デバッグ情報なども多く手がけます。その分、より多くの処理が必要になるほか、当然、調査の上で基本となるコードも常に変わっていきます。
パフォーマンス・チームは、典型的な設定は使用しません。それは、「典型的な設定」というものを定義するのが難しいということがあるためです。。またチームでは、ドミノ サーバーのパフォーマンスを制限する要因として、ハードウェアも考慮していません。
パフォーマンス・チームは、ドミノ サーバーを大規模に使用した場合の値を必ずしも提供することはできませんが、様々な作業の結果が問題を解決する一端を担っているほか、製品の上限がどこにあるのかを発見するのに役立っているのではないかと思います。
アイリス・ドミノ サーバー・パフォーマンス・チームが、公式に値を発表する際には、これらの数値はベンチマークで得られた高いレベル、すなわち「ベスト」の数値であり、実際の製品環境では必ずしもその通りに適用できるものではありません。このため、チームでは、ドミノの配備や容量計画の際にこの数値をそのまま適用しないよう、製品の免責事項や文書に加えるべきだと考えています。これらのベンチマークでの値が役立つのはむしろ、ドミノやノーツの限界を、詳細な分析と評価によって知ることができるという点です。
パフォーマンス分析やベンチマークに使用されるシステムと実際に製品環境で使用されるシステムには違いがいくつかあります。以下に、ドミノ サーバー・パフォーマンス・チームがベンチマークを行うシステムの典型的な特徴を挙げます。これらは、一般にエンド・ユーザーが使用する環境ではあまり見られないものです。ベンチマークに使用されるサーバーの特徴は次の通りです。
- システム・サポート処理がすべてロードされているわけではありません。例えば、メール・テストを行う際には、AdminP タスクをロードしません。
- 製品環境で一般的に見られる設定ではありません。特にディスク設定や RAID アーキテクチャー・オプションに関しては異なっています。
- システムにかかる負担を無視した設定になっています。ですから、物理的な設定をなくして、オペレーション・システムを隘路としてサポートしています。
- バックアップ・ソフトやウイルス検知ソフトといった、サポート・ソフトウェアはインストールしていません。これらのソフトウェアは、一般的には選択時間に同時に稼動しています。
システム管理者にとって容量計画でよくある間違いとしては、誤った領域にパフォーマンスデータがあると推定してしまう、ということです。例えば、次のようによく考えてしまいがちですが、これは間違っています。
- システム設定 - 512MB のメモリーで稼動するものは、1GB の設定でも問題なく動く。
- プラットフォーム - Solarisや UNIX で稼動するものは、Windows NT でも問題なく動く。
- ドミノ サーバー・プロフィール - NRPC メール・タスクで稼動するものは、WebMail タスクでも動く。
ベンダーによっては、サーバーのタスクがエンド・ユーザーのプロフィールに合わせて調整されているために、これらの点がどう適用するかはベンダーによって異なっています。ですから、これらのベンダーは製品環境により近い情報を提供したり、推奨を行ったりすることができます。NotesBench Consortium（US） で、テスト結果や情報を公開しているベンダーの連絡先のリストを参照してください。あなたのニーズにあった、より詳しい情報を提供してくれるかもしれません。
ドミノのR5は、 (HTTP や IMAP 接続ではなく) NRPC 接続専用の内部アーキテクチャーを持ち、サーバーの拡張性のサポートが向上されています。
R4.x や、それ以前のドミノ サーバーのリリースでは、1スレッド/セッションのモデルを採用していました。これは、1人のユーザーのセッションが確立するたびに、それ専用に、必要なリソースがドミノ・アプリケーションやオペレーティング・システムのサポート・レベルに割り当てられる、というものでした。これでは、ドミノがより多くのユーザーに対してセッション接続を確立しようとすると、これをサポートするために使用されるリソースの量も増えて、より多くの内部スレッドが必要になってしまいます。
NOTES.INI の SERVER_MAX_SESSIONS パラメーターは、 アクティブになっているセッションの数を「絞る」ことができます。そのセッションが活発であるなしに関わらず、ドミノや、オペレーティング・システムのリソースが同じだけ使用されます。また、使用されるリソースは「予約」されるという形をとるので、アクティブになっていて処理が行われているセッションが他にあっても、そのレスポンスを向上させるために使用されることはありません。
R5 では、「ワーカー・スレッド・モデル」または「Input/Output Completion Ports (IOCP)」 と呼ばれる新しいアーキテクチャーが導入されました。ワーカー・スレッドは、一定数の実行されているスレッドを通して、複数のクライアントのセッションに対して働きます。ドミノは、出荷時にワーカー・スレッド数のデフォルト値が40に設定されていて、管理者が有効にする必要はありません。IOCP は、Windows NT と Solaris、そして AIX のプラットフォームでサポートされています。ドミノ R5.0.3 では、AIX が、よりワーカー・スレッド・モデルを効率良く利用するよう、改良が加えられました。
| メモ： | ドミノ R5.0.3 では、AIX のスレッド・プール・モデルをうまく利用するために必要な処置が加えられて、AIX リリース 4.3.3 で動作します。この処置がうまく作動するために、正しいパッチ・レベルを AIX で使用してください |
|
ワーカー・スレッド・モデルを無効にすると、サーバーは R4 のように、1スレッド/セッションで動作します。
ワーカー・スレッド・モデルは、スーパーマーケットの、レジの店員にたとえることができます。レジの店員の数は、スーパーの利用客の数よりもはるかに少なく、客はレジを利用するためには並ぶことになります。レジの店員が全員レジを打っている場合もあれば、いくつかしか利用されていない場合もあります。ワーカー・スレッドの数と同様に、レジの店員の数は作業の量に関わらず一定です。客の数や、利用可能なレジの機械の数によっては、レジの店員を加えて、より多くの客にサービスを提供することも可能です。
システムがある程度の量の作業を行っている場合には、管理者は、大規模なメモリー利用の改良や、IOCP を完全利用したシステム構築といったことを検討する必要があります。ドミノ サーバーを始動したときには、すべてのワーカー・スレッドが働くように割り当てられています。もし、アクティブで接続されているユーザーの数が少ない場合には、予約されたリソースの量がドミノの以前のリリースで必要だった時よりも多くなっているかもしれません。しかし、ドミノがアクティブなユーザーを多数抱えるような、より一般的な状況では、ワーカー・スレッド・モデルに、1スレッド/セッションモデルよりも少ないシステム・メモリーが割り当てられて、全体的に必要になるメモリーの量が減ります。
また、より大規模な設定を行う場合 (アクティブな NRPC ユーザーが 5000 人レベル) は、管理者は、ドミノ サーバー・パフォーマンスがこれらの要求に答えるように、ドミノ サーバーのパフォーマンスを向上させるよう設定することができます。NOTES.INI の2つのパラメータを変更すると、システムがほぼすべて利用されている場合、より多くの作業を同時に行うことができます。
- SERVER_POOL_TASKS (ドミノ管理ガイドにはまだ文書化されていません) を、100ワーカー・スレッドに設定します。
- SERVER_MAX_CONCURRENT_TRANS は 1000 に設定し、1000 個のドミノ サーバー処理を同時に行うようにします。
サポートされているプラットフォームで、この機能を有効利用することができます。ぜひ実際にやってみてください。
この記事ではサーバー・レベルでのパフォーマンスの調整に焦点を当てていますが、サーバーが全くそれ自体だけで働く、というわけではありません。クライアントが行うことも、サーバーのパフォーマンスに大きな影響を与えます。
この例の1つが、Hide Design オプションです。これは、テンプレートの作成で、セキュリティー対策として使われるオプションで、オリジナルのテンプレートを見えないようにしたり、変更されないようにします。R5 以前ではこれはただのビット設定でしたが、R5 では、式自体を暗号化してしまいます。セキュリティーは強化されていますが、暗号化された式をもう一度解読しなければならず、システムに負担がかかってしまいます。この間接的な負担は、テンプレートが呼び出されるたびにかかり、テンプレートが過度に使用された場合には、大きな負担がかかってしまいます。
ドミノ R5 で複数の MAIL.BOX データベースをサポートしたことによって、mail.* 統計が変わったのかどうか、という質問をよく受けます。
R5 で、パフォーマンスと拡張性を向上させるために、複数の MAIL.BOX データベースのサポートが加えられました。これによって、1つのメール・ファイルに対する負担が軽減され、管理者はドミノ サーバーに複数のメールボックスを設定できるようになりました。
しかし、現在のメール統計が、始めに設定された MAIL.BOX (MAIL1.BOX など) の情報のみを表示する、という誤った理解があります。実際には、Mail.*統計や Mail.Wating 統計は、ドミノ サーバー上で設定された全ての MAIL.BOX ファイルに適用されます。
MAIL.* 統計は、ドミノ サーバー上全体で行われているメールのルーティングや配信についての情報を提供します。 (現段階では、MAIL.BOX データベースを個別に参照するドミノ統計はありません)
MAIL.BOX の情報を分析するために、コンソールで Show Dbs コマンドを使用し、その結果を参照します。このコマンドを使って得られる情報や、その分析については、Iris Today の記事「セマフォ」(セマフォ パート1とセマフォ パート2) で取り上げられています。またこの記事では、Show Dbs コマンドで得られる結果を利用して、サーバーに MAIL.BOX ファイルを追加するべきかどうかを調べる方法も紹介しています。
以下のコンソールには、アイリスのプロダクションサーバーの1つにある、複数の MAIL.BOX データベースへのアクセス率やアクセス時間についての情報が表示されています。
| > sh dbs |
|
| | | | | |
| Database |
Refs |
Mod |
FDs |
LockWaits/ |
AvgWait |
#Waiters |
MaxWaiters |
| mail2.box |
7 |
Y |
2 |
223 |
810 |
0 |
1 |
| mail1.box |
7 |
Y |
2 |
71 |
107 |
0 |
2 |
ここで、平均待ち時間が1秒未満であることに注目してください。平均待ち時間は、メールのルーティングが効率良く行われているかどうかを調べるために、定期的にチェックするのがいいでしょう。
アイリス・ドミノ・ディレクトリー・チームと、ロータス・プロフェッショナル・サービスは、この記事でディレクトリーの最適化について、いくつかの有益な提案をしたいと思います。
まず1つ目は、クイック検索を行う際によく起こる問題点についての提案です。クイック検索は、ディレクトリー・カタログの中の名前を検索しますが、そのディレクトリー・カタログに設定された [ソート方法] でのフォーマットに一致した名前を入力した場合のみ検索されます。
デフォルトの [ソート方法] は [識別名] で、名を先に、姓を後に入力した場合のみ、ディレクトリー・カタログ内でクイック検索が行われます。ほとんどの人はこの順番で名前を入力するので、デフォルト設定は便利です。この他に [姓 (ラストネーム)] というオプションがあり、この場合は姓を名の前に入力しなければなりません。これは検索方法がもう1つあるということで、オプションが変更された場合には、入力される名前のフォーマットも変えなければならないことを意味します。
次の図は、ディレクトリー・カタログ文書の、設定オプションを示しています。
もし、The View (ノーツやドミノについての、テクニカル・ジャーナル) を購読しているなら、November/December 1998 版を参照してください。アイリスの開発者の、Mike O'Brien による「The New Domino R5 Directory Catalog: An Administrator's Guide」の中で、ソート方法フィールドのオプションが取り上げられています。また、それぞれソート方法が姓 (ラストネーム) に設定されたディレクトリー・カタログと、識別名に設定されたディレクトリー・カタログの2つを設定する方法も紹介されています。
ディレクトリー・カタログのセットアップについてについての情報は、R5 システム管理ヘルプでも参照できます。
| メモ：ここで紹介した設定オプションは、R5 クライアントでのみ利用可能です。 |
ドミノ R5 で導入された機能の1つに、トランザクション・ログと復旧のサポートがあります。トランザクション・ログは、信頼の置けるデータ保存のためのソリューションで、有効にすれば、ドミノ サーバーはサーバーに加えられたすべての更新を、トランザクション・ログ (普通はローカル・サーバーのデータ格納場所にあります) に書きこみます。もし、システムやメディアでエラーが起きても、トランザクション・ログと、サードパーティー製のバックアップ・ユーティリティーを使用することによって、データベースを復旧することができます。トランザクション・ログの使用については、Iris Today の「Optimizing server performance: Transaction logging」の中で詳細にわたって取り上げられています。
最近、管理者はトランザクション・ログを有効にしない傾向がある、という報告を受けました。R5 についての最新のデータでは、トランザクション・ログを使用しても、I/O が低?中程度であれば、パフォーマンスの向上が望めない、ということが分かっていますが、システムがディスクの大部分を使用している場合には、レスポンス時間、CPU 利用率、ディスク利用率が低くなる、というデータもあります。システムの I/O が上限を超えている場合は、ディスクを増設して、RAID を構築するのが唯一の解決策かもしれません。
しかしながら、ここで見られたパフォーマンスの向上は、偶然見つかったもので、トランザクション・ログの本当の目的は、ドミノ・データベースの信頼性と、利用可能性を高めることです。プロダクション環境では、これらが求められ、高いレベルのサービスを提供する必要があるため、当然トランザクション・ログのような機能は利用されるべきです。
ドミノ管理者にとっては、ドミノ サーバーを再起動するのにかかる時間が減る、というメリットもあります。これは、複数のサーバーが存在するようなより大きな環境では、相当な時間を節約できます。この点も、トランザクション・ログの第一の目的ではありませんが、見逃すことができません。
サーバー・メモリーについて理解するには、2つの点を知っている必要があります。まず、計画を行う際に、システム上で利用可能なメモリーは、オペレーティング・システムと、その上で稼動するアプリケーションによって使用される、ということを理解していなければなりません。
ドミノ サーバー自体は、利用可能なメモリーの量に基づき、バッファーとアクティブになっている処理のためのメモリーの割り当てを決定します。大抵の場合は、多ければ多いほどいいのですが、ある量以上割り当てても変わらない場合があります。
ある特定のオペレーティング・システムについては、メモリー量に限界があり、システム・メモリーを追加しても何も変わりません。オペレーティング・システムのカーネルが効率良く利用するメモリーの量には上限があります。このセクションでは、システム管理者が「システムが効率良く利用できるメモリー量の上限」を決めるのに役立つガイドラインを示します。
この「システムが効率よく利用できるメモリー量の上限」の計算は、ドミノ サーバーは 32 ビットのアプリケーションであるという前提をもとにしています。32 ビットのオペレーティング・システムで使用可能なメモリーの上限は4GB です。一般的には、この4GB は、2つの2GB の領域に分けられ、1つはアプリケーションに、もう1つはオペレーティング・システムに割り当てられます。
追加したメモリーがどのように使用されるかはプラットフォームによって違い、また、オペレーティング・システムが 32 ビットか 64 ビットかによっても異なります。例えば、ある種類の UNIX では、オペレーティング・システムのインスタンスを複数起動することによって、4GB 以上に追加したメモリーを利用できます。また、64 ビット・オペレーティング・システムである Solaris では、はるかに多くのメモリーを使用できます。ドミノ R5 は 32 ビット・アプリケーションですが、現時点では Solaris の 64 ビット版でサポートされています。
| メモ： | 以下に挙げるオペレーティング・システムでは、パーティションは1つの設定であるとします。複数パーティションがある場合については、追ってこのシリーズに掲載します。 |
|
Windows NT
Standard Edition
ドミノは、2GB までの物理メモリーが使用できます。もし、それ以上のメモリーがシステム上にある場合(3GB のシステムの場合など) でも、ドミノは 2.6GB まで使用するということが分かっています。この際には、0.6GB はオペレーティング・システムに使用され、残りの2GB はドミノアプリケーションに使用されることになります。
Enterprise Edition
このバージョンの NT では、ドミノは3GB まで物理メモリーを使用することができます。これを有効にするには、NT Enterprise Edition (NT EE) を、/3GB のスイッチで起動する必要があり、これによってドミノに2GB、NT に3GB のメモリーが割り当てられていたのが、3GB をドミノに、1GB を NT に割り当てるようになります。ドミノは、このオプションを有効に利用するよう設計されていなければなりませんが、アイリスによる内部テストで負荷を与えた結果、メモリーを追加してもパフォーマンスや拡張性の点で向上は望めないということが分かりました。ですから、どのような使い方をするにしても、ドミノには2GB の物理メモリーの上限があることになります。
また、NT EE のカーネルによって呼び出される 192MB のメモリーも制限を加えています。詳しくは、Lotus Customer Support Technote #179781, Domino R5 on NT Returns: 「Insufficient System Resources Exist to Complete the Requested Service」を参照してください。（現在リンクはありません）
Windows 2000
Server Edition
Server Edition でも、NT の場合と同様、2GB までの物理メモリーが使用可能です。もし、それ以上のメモリーがシステム上にある場合 (3GB のシステムの場合など) でも、ドミノは 2.6GB まで使用するということが分かっています。この際には、0.6GB はオペレーティング・システムに使用され、残りの2GB はドミノ・アプリケーションに使用されることになります。
Advanced Server Edition
NT の場合と同様、2GB までの物理メモリーが使用可能です。システムにメモリーを追加しても、ドミノは2.6GB まで使用できるということが分かっています。3GB のシステムでは、この0.6GB はオペレーティング・システム用に使用されます。Advanced Server Edition では、/3GB スイッチをサポートしており、アプリケーション (特に組み込みのアプリケーション) は追加物理メモリーを使用することができます。NT EE と同様、アイリスによる内部テストで負荷を与えた結果、メモリーを追加してもパフォーマンスや拡張性の点で向上は望めないということが分かりました。ですから、このバージョンの Windows 2000 では、2GB までの物理メモリーが使用できるということになります。
Data Center Edition
現時点では、一般向けに販売されていません。
Solaris/UNIX
ドミノは、32ビット版では、4GB までの物理メモリーを使用することができ、カーネルがその一部を使います。
Solaris のカーネルは、4GB 以上の物理メモリーを搭載/使用することができます。 (ファイル・システム用など)
AIX/UNIX
ドミノは、32ビット版では、4GB までの物理メモリーを使用することができ、カーネルがその一部を使います。
リリース AIX 4.3.3 とその上位版のリリース以降では、AIX カーネルは 64ビットに対応しているため、容易に64GB に対応することが可能です。AIX でサポートされているメモリーの上限は、上がるでしょう。
メモリーについてのより詳しい情報
メモリーなどの物理的なハードウェアによる制限を受けたり、トランザクション・ログなどのオプションを有効にしていないなど、多くの要因がドミノのパフォーマンスに影響を及ぼします。これらの要因について知っているだけでなく、システム管理者は、それらのオプションを理解したり、間違った噂と事実を区別することが必要になります。
アイリス・ドミノ サーバー・パフォーマンス・チームでは、ドミノについての誤った考えをなくすことが、ユーザーの利益に即つながると考えています。Iris Today にこれから登場する「ドミノ サーバーの能力を引き出す」の続きをお待ちください。サーバー・パフォーマンス・チームの得た経験や知識を皆さんに紹介していきます。
謝辞
この記事の内容を充実させるために知識やデータを提供してくれた方々に感謝します。特に、ジェームス・グリスビー、マリア・クリローバ、アイリスパフォーマンス・チーム、ロータス・プロフェッショナル・サービス・テクノロジーチーム、メール・ルーティング・チーム、そしてドミノ・ディレクトリー・チームからは、この記事の内容に多大な協力をいただきました。
著者について
キャロル・ジメットは、1994年から アイリスに勤め、ドミノ・パフォーマンス・チームのリーダーの一人として、パフォーマンス評価や、ツールの開発に携わっています。キャロルは、パフォーマンスに関する問題への、ワンステップ・ソリューションを模索すると同時に、製品の品質を改善するためのアプローチにも興味を持っています。また、子供たちとサイクリングをしたり、ラケットボールをするのが好きで、ステンドグラスをしたいと考えているとか。
アニー E. スミスは、ロータスでユーザー・アシスタンス・ライターのチーフとして活躍し、ドミノやノーツの機能に関するスペックを記述しています。彼女はまた、ノーツ UA Web チームの一員です。
|
 |
|
