ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

ドミノサーバーの能力を引き出すパート3

by Carol Zimmet and Amy E. Smith
レベル：上級者
対象：Domino 5.0
原文の掲載：2000年12月1日

Iris Today Archivesの原文（US）

インデックス

	アプリケーション・サーバーにおけるディスク入出力とそれ以外の事項の監視
	パーティション・システムにおけるメモリー構成の要点
	ユーザー・マニュアルのような設計やコーディングができるとは限らない
	まとめ

この記事は、ドミノの管理者やユーザー、コンサルタント、ビジネス・パートナーがたびたび直面する問題や勘違いを特定し、明らかにするというシリーズのパート3です。これらの記事では、コンセプトやオプション機能を紹介するほか、その機能の使用の有無によるドミノサーバーのパフォーマンスや導入に関する影響や、キャパシティー・プランニングの決定に及ぼす影響ついて議論しています。これらの記事では、メールの配送やアプリケーションの開発テクニック、Web 関連の戦略、データベース管理や設計といった、さまざまな領域やプラットフォームに渡っており、時には特定のプラットフォームについて議論しています。

このシリーズのパート1では、ドミノサーバーのユーザー・コミュニティーで広まっている誤解や誤った情報を一掃することと、まだ一般に十分に広まっていない新機能に注目しました。パート2では、管理者がシステムのパフォーマンスを改善するために、システム・パラメーターの調整や、ユーザー・ファイルの最適化、健全なアプリケーションの開発習慣といった積極的な手段について議論しました。パート3では、メモリー性能の低下の監視や、パーティションされた設定においてのメモリーの割り当て方法といったメモリーの利用に関する話題を扱います。また、ドミノ・アプリケーションの設計や開発におけるヒントも紹介します。

このシリーズの記事で、Iris のドミノサーバー・パフォーマンス・チームは、ドミノサーバーをサポートしているすべてのプラットフォームについての情報を提供しています。パフォーマンス・チームは、そのプラットフォームに関する最も正確な情報を得て、これらのプラットフォームでのドミノやノーツの動作についてのパフォーマンスのデータを収集するために、プラットフォームのベンダーと密接に協力しています。

アプリケーション・サーバーにおけるディスク入出力とそれ以外の事項の監視

ディスクの入出力はおそらく最も重要な追跡すべき統計情報といえるでしょう。というのも、ディスクは最も負荷がかかっているように見え、修復が非常に困難なシステム・コンポーネントだからです。しかしながら、管理者は CPU、メモリー、ネットワークといった他のコンポーネントにも目を配る必要があります。

特にメモリーに関しては、どのようなシステムの設定でも、システムの負荷が高すぎるときにはディスクと同様に疑ってよいコンポーネントです。多くの管理者は高負荷なサーバーがいつメモリー不足になるのかということや、危機的な状況に陥る前にその状態を検出する方法を知りたいと思っています。最近、あるシステム管理者がサーバー・パフォーマンス・チームにメモリー不足に関して重要な指標や、その情報の解釈の仕方、またメモリー増設のタイミングについて尋ねてきました。

以下のグラフでは、ある顧客の R5 環境のデータを示しています。グラフのデータは、午前 9:30 から午前 11:30 までの2時間についてのもので、この時間帯はユーザーの活動が最も活発になります。ある特定のシステムについての詳細は、意図的にここでの議論の対象からはずしています。ここでは、メモリー不足というどんなシステムでも起こりうる状況の検出方法、対応方法について焦点を当てています。このような場合、管理者はドミノサーバーのパフォーマンスを監視するためにどの測定項目に着目すべきかということが悩みの種でした。

ここで述べるプロダクション・サーバーは非常に多数のビューをもつ巨大なデータベースをサポートしているアプリケーション・サーバーです。このサーバーでは、おおよそ 70 種ものアプリケーションが実行され、5.4GB のデータにピーク時には、週に 17,000 人ものユーザーがアクセスするというものでした。このサーバー上のあるアプリケーションは、128 のビューを持っており、1.9GB ものサイズのデータベースを扱っていました。サーバーの構成は、CPU が Pentium Pro 200MHz で、もともと 256MB のメモリーを搭載していましたが、評価時には 512MB のメモリーを搭載しました。

以下のグラフではこのアプリケーション・サーバーにおける利用可能なメモリーの残量を示しており、単位は MB (メガ・バイト) で、2時間分のデータを用いています。利用可能なメモリー残量の平均値は 28MB で、システム全体で 512MB のメモリーがあることを考えるとぎりぎりの残量であると言えます。ときどきメモリーの残量が5MB を下回ることがあり、全体の 23% もの時間を占めています。これらの2点については個別あるいは双方において、サーバーになんらかの対処を施す必要があることを示しています。

Memory available

もちろん、その他の重要な要素についても同時に見る必要があります。この2時間の間の CPU の利用率は、平均値が 27.9% で、最大値が 66.7% と、妥当な範囲に収まっていました。データ・ドライブのディスク入出力は、平均キュー長が 1.48 で、最大キュー長が 6.59、ディスクの読み書き時間については、平均 77.76% 、最大 100% と非常に高い負荷がかかっていました。(ディスクのキュー長について、詳しくはこのシリーズのパート2をご覧ください)

以下のグラフでは、プロセッサー、メモリー、ディスクについての情報を示しています。これにより、システムの負荷がいつ頂点に達しているかということや、それがどのぐらい続いているのかということが分かります。そして、そのときのシステムの動きは何が原因になっているかを関連付けることができます。(このグラフでは、見やすくするためにディスクのキュー長を10倍にして表していることに注意してください)

Key system metrics

システムの情報をより見やすくし、得られた情報を適切に評価するために、サーバー・パフォーマンス・チームは、ドミノの管理者に以下のような質問をしてみました。

そのドライブではドミノ・アプリケーション以外のアプリケーションが実行されていますか？
その他に非常に活発なドミノのタスクが実行されていますか？
ディスクのスピンドルの数をご存知ですか？ (これは後ほど述べますが、ディスクのキュー長の計算の際に必要になります)

いくつかのプラットフォームでは、ディスクのスピンドル数を知るのは困難なことですが、このようなシステム設定情報を得ることは非常に重要です。しかし、ディスクのキュー長単体だけを見ても意味がありません。システムのディスクのスピンドル数も考慮する必要があります。ディスクの使用率が飽和しているかどうか判断するには、ディスクの平均キュー長がスピンドル数を越えているかどうか調べます。もし越えていたらディスクの使用率が飽和していることになります。ディスクのキュー長とスピンドル数の開きが大きいほど問題の度合いが大きいことになります。サーバー・パフォーマンス・チームは、一般的な経験から、平均キュー長はディスク利用率のよい指標となるということが分かりました。他の測定基準として、サービス時間や、ディスクを利用している時間の割合は他のプラットフォームでも有効です。

先ほどのグラフのディスクのデータに注目して別のグラフに表します。以下のグラフでは、ディスク入出力のデータを表しています。(ディスクのキュー長は見やすくするために正規化していることに注意してください)

Data disk I/O analysis

もともとこの分析をしたときには、ディスクのスピンドル数は不明でした。しかし、理論的な視点から分析することができます。多くの場合における入出力のボトル・ネックを評価するためのアルゴリズムとして、平均ディスク・キュー長をスピンドル数で割り、その結果を調べます。結果の値が1よりも大きければ、より詳しく調査を行う必要があります。上の例では、もしスピンドル数が4で、平均キュー長が4よりも小さければ、そのシステムの動作はディスクの入出力によって制約されていることにはなりません。もしディスクのスピンドル数が2であると仮定すると、そのシステムは入出力によって制限を受けていることになります。またディスクの使用時間率を計算に入れることができます。(経験上、このプラットフォームでは、使用時間率はディスクの利用の飽和を示すよい指標ではありません)そして、非常に長時間に渡って使用時間率が 100% に達しているため、ディスクの入出力の設定についてより詳しく調査する必要がありそうです。

メモ：

上記の状況ではディスクのスピンドル数は明らかではありませんでした。このような場合、ディスクの平均キュー長を計算する方法を知るために、ディスクの製造業者の協力を得ましょう。

メモ：

記の分析では、NT や Windows 2000 を中心に考えたものでしたが、各プラットフォームで、ディスクの飽和状態を分析するための独自の測定基準を提供しています。各ベンダーや、ベンダーが Web サイトに載せている情報は、分析手順を知るための助けになるはずです。プラットフォームの統計情報は、このような方法を念頭において導き出され、それらの中には、プラットフォーム固有の非常に重要な情報も含まれます。ドミノの統計情報から、このような分析の水準に達することができます。

ドミノ管理者の疑問に話を戻して、必要最小限として利用可能なメモリー容量は 4MB 以上になるようにすることをお勧めします。しかしながら、利用可能なメモリーが全体の 5% 以下になれば、管理者はサーバーの分析を行い、近い将来に起こることに対して対策を練らなければなりません。統計 & イベントからこの値をしきい値として設定し、利用可能なメモリー容量がこの値よりも小さくなればサーバーが警告を発するようにできます。最初に示した図では、ドミノサーバーは平均的に 28MB のメモリーが利用可能で、ある警告状態にあると解釈できます。オペレーティング・システムは、最後の 4MB あるいはそれ以上のメモリーをオペレーティング・システム自身のために使用すると考えられます。そのため利用可能なメモリーがしきい値以下になることはありません。

より大規模なマシンでは、それほどメモリー不足の状態を監視する必要がありません。これらのマシンのメモリーの基本設定もまた規模が大きいからです。サーバー・パフォーマンス・チームは、非常に頻繁にページングが発生し、ドミノ・ページングではなく、ファイル・システムのページングが発生するほど、ページ・スキャン率が上昇するというベンチ・マークを (たとえば、UNIX システム上で) 行います。ファイル・システムのページング・レートが非常に高い状況では、メモリーの増設は非常に有効でしょう。パフォーマンス・チームは UNIX システム上で利用可能なメモリー容量の監視を行いましたが、vmstat コマンドの出力の、"swap" から現在利用可能なスワップ領域の大きさを KB (キロ・バイト) 単位で得ることができます。さらに、vmstat の出力の "free" の欄からフリー・リストのサイズを KB 単位で得ることができます。

メモ：

このセクション内で後ほど示す表を見ると、各プラットフォームにおいてドミノのメモリー監視の統計情報が分かります。

プラットフォームの統計収集は、従来のドミノサーバーから強化された部分で、NT と Solaris/UNIX 用のドミノのリリース 5.0.2 と、AS/400 用のドミノのリリース 5.0.3 で導入されました。現在は、NT と IBM AS/400 (iServer 400)、Solaris/UNIX で利用可能で、ドミノサーバーを起動する前に、NOTES.INI ファイルで、Platform_Statistics_Enabled=1 と設定する必要があります。統計情報には、そのプラットフォームの基本的な情報 (プロセッサー、メモリー、ディスク入出力) が含まれます。ドミノの管理者はこの値に注意を払い、その機能をサーバーで利用可能にすることが重要となります。

プラットフォームの統計情報を有効にした結果、ドミノの統計情報として、新たに Platform.Memory.KBFree という測定基準が利用できるようになります。統計 & イベント環境が設定されて実行中であれば、管理者は、この測定基準の値が設定した範囲よりも小さくなった場合に警告を発するようにしきい値を設定できます。たとえば、ドミノは統計情報を KB 単位で出力するので、しきい値を 10 に設定したり先ほどお勧めしたように、おおよそ 5% に設定し、それ以下になれば警告を発するように設定できます。そして、サーバーでメモリー不足が起こると管理者は通知を受け取ることになります。

管理者はサーバーの利用可能なメモリー容量を追跡するためのツール・ボックスを利用することができます。それは、監視の測定基準 (Platform.Memory.KBFree) として、メモリーの残量の危険信号のしきい値 (たとえば、10MB 以下の値) や、注意信号のしきい値 (たとえば、28MB 以下の値) といったものや、メモリー不足に陥った場合に通知の処理を行います。

メモ：

AS/400 のプラットフォームでは (シングル・レベルの記憶装置なので)、IBM は測定基準として代わりに、Platform.Memory.FaultsPerSec と Platform.Memory.WaitToIneligible の使用を勧めています。

もはや、個々のプラットフォームのパフォーマンス・ツールで他の測定基準を監視する必要はありません。ドミノサーバーの Platform 統計情報により、たった1つのインターフェースで監視を行うことができます。以下の表では、Platform 統計情報で追跡できる情報を示しています。以下の表ではドミノサーバーでサポートしている Platform 統計情報の一部だけを紹介していることに注意してください。

パフォーマンス統計情報 (システム・コンポーネントごと)	説明
メモリー
Platform.Memory.KBFree	システムで利用可能な仮想メモリーの総量 (KB) です。Windows NT のシステム・モニターの、Memory/AvailableBytes を 1024 で割ったものと同じ意味です

Platform.Memory.FaultPerSec (AS400 のみ)	サーバーが利用しているメモリー・プールでの1秒あたりのページ・フォールト数

Platform.Memory.WaitToIneligible (AS400 のみ)	サーバーが利用しているメモリー・プールでスレッドの不適切な遷移待ちの回数。0より大きな値であれば、メモリー・プールの max active が非常に低いことを示しています。
CPU
Platform.System.TotalUnit	システム内のすべての CPU の平均利用率を表します。NT のシステム・モニターの System/% Total Processor Time と同様です。

Platform.System.TotalPrivUtil	システム内のすべての CPU における特権モードでの平均利用率です。NT のシステム・モニターの System/% Total Privileged Time と同様です。

Platform.System.TotalUserUtil	システム内のすべての CPU におけるユーザー・モードでの平均利用率です。NT のシステム・モニターの System/% Total User Time と同様です。
ディスク
Platform.LogicalDisk. _Total.1._Total.1.PctTime	全物理ディスク上の全論理ディスクが読み書きの要求を処理するサンプリング間隔の割合。NT のシステム・モニターの LogicalDisk/% Disk Time と同様です。最初の "_Total" は全物理ディスクを表しており、次の "_Total" は全論理ディスクを表しています。

Platform.LogicalDisk. _Total.1._Total.1.AvgQueueLength (NT のみ)	サンプリング間隔内で、全物理ディスク上の全論理ディスクにキューイングされた読み書き要求の平均の個数を表します。これは NT のシステム・モニターの LogicalDisk/Avg.Disk Queuue Length と同等です。

Platform.LogicalDisk. _Total.1._Total.1.ServiceTime (Solaris/UNIX のみ)	読み書きコマンドの実行時間の総量です (ミリセカンド単位)。

管理者の究極の目標として、負荷分散やメモリー増設のタイミングの境界を見極めることです。この場合の監視すべき測定基準は、Platform.Memory.KBFree になります。また、次のことを強くお奨めします。

システム上で残しておくべきメモリーの最小量と、利用可能なメモリー容量に注意してください
パーティション設定の要素
メモリーの利用レベルの測定
安全網として少なくとも 10% のメモリーを確保しておく

この例の場合、ドミノ管理者にとっての勝利とは、メモリーの残量が4から 5MB に達していたことを確認し、これがメモリー不足の状況を示していることを理解したということになるでしょう。このドミノ管理者にとってもう1つの勝利とは、平均ディスク・キュー長についてのより深い知識の学習と、ディスクがボトル・ネックの状況で、ディスクのスピンドル数を考慮して分析することの重要性を理解しているということでしょう。

基本となるメモリー容量が 512MB では、管理者はメモリー不足の状況に陥る時間や、将来の計画に基づいてシステムにメモリーを増設するとよいでしょう。先ほど話の中では、管理者は現在のアーキテクチャーや設計、サーバーで実行中のアプリケーション数や種類の変更を望んでいませんでした。アプリケーションの数や種類の変更は、メモリーが大きなボトル・ネックになっている場合には十分ありえる解決方法と言えます。特に、サーバー・パフォーマンス・チームはメモリーの増設は、256MB 以上の単位で行うことを推奨します。というのも、現在はメモリーの価格が低いことと、メモリーの増設が非常に容易だからです。

ドミノさまざまなプロセスに対して、どのようにメモリーを使用するのかについてより深く理解するために、Inside Notes をご覧になることをお勧めします。ここから、ノーツやドミノサーバーのアーキテクチャーに関する情報を得ることができます。非常に多数のドミノサーバーを管理している顧客の一例として、Lotus IT Central Performance Zone の、「Acxiom Corporation: Upgrade to Notes and Domino Release 5 Nets Improved Productivity, Performance, Hardware Consolidation for Acxiom.」という記事をご覧ください。

上に戻る

パーティション・システムにおけるメモリー構成の要点

かつてユーザーはシングル・パーティション・システムでは何ができるのかを知っていました。彼らはシングル・システムで複数のパーティションを実装する可能性を探ることもありました。その結果として、サーバー・パフォーマンス・チームはサーバーの物理メモリーや、ドミノがそれをどの程度使用するのかについてたびたび尋ねられました。しかしながら、システム・アプリケーションはオペレーティング・システムの機能に制限されるため、オペレーティング・システムの重要性についても理解しなければならないという事実があるためにその答えは、非常に複雑になります。アプリケーションが要求する以上のハードウェアを実装することも可能ですが、効率的にメモリーを使用するには、オペレーティング・システムのオプションや、パーティションのデザインに関して「独創的な設定」が必要となります。パーティションを利用することで、単一のシステムで複数のドミノのインスタンスが共存でき、以下のようなことが可能になります。

大規模システムの能力を最大限に利用できる
ドミノの特殊機能を利用できる (システムのすべての能力を使うこととは対照的です)
使用状況が異なるユーザーや、プロファイルの異なるユーザーで利用できる
サーバーの合併戦略の一部として、サーバーの独立性を保ったまま複数の独立したサーバーを1つのシステム上で実現できる。

このシリーズのパート1では、シングル・パーティション・システムでの利用可能なメモリーの使用計画について議論しました。ここからは、パーティション・システムでのメモリーの分析について議論していきます。おさらいすると、ドミノサーバーは利用可能なメモリー容量に基づいてバッファーやプロセスにメモリーを割り当てます。一般的にメモリーが多いほど良いですが、この場合では、ある点についてだけ良いと言えます。メモリーの使用を計画するには、以下の事柄を考慮しなければなりません。

利用可能なメモリー容量
対象となるプラットフォームとオペレーティング・システム
アプリケーションのビルド・レベル (32 ビットあるいは 64 ビット)
オペレーティング・システムでサポートされているアドレス空間 (32ビットあるいは 64ビット)

パーティションの設定を考えると一層複雑になります。というのも、パーティション・システムの目標や、プラットフォームとその設定が要求を満たしているかということについて考慮しなければならないからです。たとえば、ユーザーはオペレーティング・システムが 32 ビットあるいは 64 ビットをサポートしているかについて知っておく必要があります。 (例として、Solaris/UNIX や AS/400、RS/6000/AIX は 64 ビットをサポートしているオペレーティング・システムです) 64 ビットのオペレーティング・システムでは、アプリケーションが 64 ビットのアドレス空間をサポートしているかについて知っておかなければなりません。

あるオペレーティング・システムでは、メモリーを増設しても全く効果がありません。というのも、オペレーティング・システムのカーネルが利用できるメモリーの上限が決まっているからです。しかし、余剰メモリーを利用するためにパーティション化するというわけではありません。以下では、管理者の手助けとなるように、32 ビットのオペレーティング・システムを用いている場合でも、システム上のメモリーを最大限に有効活用するためのガイドラインを示します。

増設メモリーの利用はプラットフォームに依存し、各プラットフォームやリリースごとに検討する必要があります。先ほど述べましたが、オペレーティング・システムが 32 ビットあるいは 64 ビットのどちらをサポートしているかが、分析のポイントとなります。たとえば、いくつかの UNIX では、複数のオペレーティング・システムのインスタンスを実行することで 4GB 以上のメモリーを使用できますが、Solaris/UNIX などの 64 ビットのオペレーティング・システムではより大きなメモリー空間を扱えます。ドミノ R5 は 32 ビット・アプリケーションなので 64 ビットの Solaris 上では 32 ビット・アプリケーションとして実行されます。

これらの計算はドミノサーバーが 32 ビットのアプリケーションなので必要となります。32 ビットのオペレーティング・システムのメモリー空間は最大で4GB です。典型的にはこれは、2つの 2GB の領域に分けられ、1つはアプリケーションに利用され、もう1つはオペレーティング・システムのために予約されています。この経験則は、マイクロソフトのオペレーティング・システムの大部分に適用されています。以下のセクションでは、各オペレーティング・システムのサポート範囲ついて詳細に述べていきます。

ここ数ヵ月で、サーバー・パフォーマンス・チームはプラットフォームのベンダーから多くの 64 ビットのオペレーティング・システムがリリースされたのを確認しました。以下に述べる二点では、このような設定で、複数のパーティションを実装する際に考慮すべき点を述べています。

ドミノを 64 ビットのオペレーティング・システム上で実行する場合、32 ビットのアプリケーションとして実行されるため、内部のキャッシュやデータ構造に関して依然として以下で述べるような制限があります。
64 ビットのオペレーティング・システム上で複数のドミノの設定をする場合、セマフォを利用することで負荷の集中を低減できます。結果として、ドミノに関連するリソースの分散や複数のインスタンスを実行することでシステムの利用率を改善できます。

メモ：

以下で述べるすべてのプラットフォームでは、複数パーティション・システムで分析を行っています。

Windows NT - Standard Edition
シングル・パーティション・システムでは、ドミノは最大 2GB までの物理メモリーを利用できます。システムにさらに多くのメモリーがある場合 (たとえば、3GB のシステム)、おおよそ 2.6GB まで利用できることを確認しました。このような場合、0.6GB はオペレーティング・システムが利用し、残りの 2GB をドミノが利用することになります。2GB 以上のメモリーを持つサーバーの複数パーティション・システムでは、ドミノ・パーティションはメモリーをアドレス可能な 2GB の範囲に収まるように分割します。たとえば、2つのパーティションがあり、アドレス可能な範囲が依然として 2GB の場合、2GB を最大限に使用するために、ドミノは 1GB ずつ各パーティションに割り当てます。この場合、メモリーを増設しても効果はありません。

Windows NT - Enterprise Edition
Enterprise Edition の NT では、ドミノは 3GB までの物理メモリーにアクセスできます。これを可能にするためには、NT Enterprise Edition (NT EE) を /3GB のスイッチをつけて起動しなければなりません。この変更により、ドミノに 2GB、NT に 2GB というメモリーの割り当ては、アプリケーションに 3GB、NT に 1GB となります。このオプションを活用するには、ドミノを特別な方法で構築する必要がありますが、Iris 内の内部テストでは、メモリーを増設してもパフォーマンスやスケーラビリティーの向上は望めないことが分かりました。そのため、/3GB オプションは新しいリリースで利点が得られるかどうかを定期的に調査する予定です。意志や目的に関係無く、NT の Enterprise Edition のために、ドミノは最大 2GB までの物理メモリーを扱うことができます。言い換えると、ドミノが利用可能な最大のアドレス空間は、Windows NT Standard Edition の場合と同様ということになります。

さらに、NT EE の 192MB のカーネルのページング制限も問題となります。詳しくは、Lotus Customer Support Technote #179781 , 「Domino R5 on NT Returns: Insufficient System Resources Exist to Complete the Requested Service」（US）をご覧ください。

Windows 2000 - Server Edition
Windows 2000 -Server Edition では、NT と同様にドミノは最大 2GB までの物理メモリー空間を利用できます。システムにさらに大きなメモリーがあれば (たとえば、3GB のシステムを考えます)、おおよそ 2.6GB まで使用することができます。このような場合、0.6 GB はオペレーティング・システムで利用され、2GB がドミノで使用されます。Windows 2000 上のドミノでも依然として 2GB という最大アドレス空間の制限が存在します。

Windows 2000 - Advanced Server Edition
Windows 2000 - Advanced Server Edition では、NT と同様にドミノは最大 2GB までの物理メモリー空間を利用できます。システムにさらに大きなメモリーがあれば (たとえば、3GB のシステムを考えます)、おおよそ 2.6GB まで使用することができます。このような場合、0.6GB はオペレーティング・システムで利用され、2GB がドミノで使用されます。Windows 2000 上のドミノでも依然として 2GB という最大アドレス空間の制限が存在します。

特別に構築された場合、このバージョンは /3GB スイッチをサポートしており、アプリケーションはさらに多くのメモリーを有効利用できます。この場合もやはり、さまざまな負荷をかける内部テストを行いましたが、パフォーマンスやスケーラビリティーの点で特によい結果は出ませんでした。現在、このバージョンの Windows 2000 で、ドミノは 2GB までの物理メモリーをサポートしています。Windows 2000 はさきほど述べた NT のカーネル・ページの問題を解消するために、オペレーティング・システムの多くのメモリー・プールを倍増しています。結果として、このバージョンも、ドミノが利用できるメモリー空間の大きさという点では、Windows 2000 - Standard Edition と同様と言えます。

Windows 2000 - Data Center Edition
Windows 2000 Data Center Edition の OS パーティショニングは、インテル・システムのベンダーに依存しています。このバージョンの Windows はまだ市場に出たばかりで、あまり利用されていません。私たちが知る限りでは、Compaq や Unisys だけが Data Center Edition での OS パーティショニングを提供しています。

Solaris/UNIX
Solaris/UNIX では、ドミノは 32 ビット・バージョンのオペレーティング・システム上でも 4GB の物理メモリーを利用できます。この物理メモリーの一部はカーネルでも使用されます。

64 ビット版の Solaris カーネルは 4GB 以上の物理メモリー空間を利用できます。ドミノでは 4GB までのメモリーしか利用できませんが、カーネルは残りのメモリーを利用でき、OS レベルの操作 (ファイル・システムの入出力など) に用いることができます。結果として、64 ビットのオペレーティング・システム上では、メモリーの利用に関してそれほど気を使わなくてもよいということになります。また、ドミノは 32 ビットのアプリケーションで、最大 4GB というメモリーの利用制限があり、複数のドミノ・パーティションを1つのシステム上で実行することもできます。

RS600/AIX/UNIX
RS600/AIX/UNIX では、ドミノは 32 ビットのオペレーティング・システム上で 4GB までの物理メモリーを利用できます。そのうちの一部はカーネルで使用されます。リリース・バージョン 4.3.3 以上の AIX では、カーネルは 64 ビットのアドレス空間をサポートしており、64GB までは容易に利用できます。また今後 AIX でサポートされるメモリーの上限は増加するでしょう。

ドミノでは 4GB までのメモリーしか利用できませんが、カーネルは残りのメモリーを利用でき、OS レベルの操作 (ファイル・システムの入出力など) に用いることができます。結果として、64 ビットのオペレーティング・システム上では、メモリーの利用に関してそれほど気を使わなくてもよいということになります。また、ドミノは 32 ビットのアプリケーションで、最大 4GB というメモリーの利用制限があり、複数のドミノ・パーティションを1つのシステム上で実行することもできます。

AS/400
OS/400 のメモリー管理は他のものとは多少異なっています。OS/400 は 64 ビットのオペレーティング・システムで、一次記憶としては 96GB まで (オプションで 128GB まで) のメモリーをサポートしています。また、二次記憶装置は 2000TB (テラバイト = 1024 GB) までサポートしていますが、個々のファイルは 64GB のサイズ制限があります。OS/400 のシングル・レベルのストレージ管理により 96GB 以上のアドレス空間を利用できます。

通常、最大 99 個のドミノサーバーを OS/400 上で実行できます。また、1つの OS/400 のマシンを論理パーティション (LPAR) に分割できます。各論理パーティションで、99 個のドミノサーバーを実行できます。現時点での論理パーティションの最大数はプロセッサー数に等しく、現状では、最大 24 個の論理パーティションに分けることができます。その数に 99 を掛け算すると、1台のマシンで 2376 のドミノサーバーを実行することができます。

各ドミノのパーティションは、どのような記憶装置でもアドレッシングできます。つまりオペレーティング・システムは、メモリーかディスクかを決定します。たとえば、2000TB を1つのパーティションで使用することも、1つ目のパーティションに 5TB 割り当て、2つ目のパーティションに 1995TB を割り当てることもできます。ドミノで利用できない記憶装置はオペレーティング・システムでは少しの容量しか使用されません。

詳細については、AS/400 IBM のサイト（US）の記事をご覧ください。特に、「Improve the return on your IT investment with Server consolidation」と「Domino on the AS/400」をご覧になることをお勧めします。

S/390
現在利用可能な OS/390 環境では、単一のドミノ・パーティションで 2GB までのメモリーが利用可能です。すべてのパーティションのメモリー要求が 2GB を越えない範囲で、複数のドミノ・パーティションを単一の OS/390 インスタンス (論理パーティション) 上で実行できます。2GB を要求する各パーティションのサーバーは別の OS/390 論理パーティションに配置する必要があります。1台の S/390 マシンで最大 15 個の OS/390 論理パーティションをサポートしています。

新しい zSeries 900 (現在の S/390 製品のシリーズに続くものです) では、64 ビットの実メモリー空間を提供してます。ドミノサーバー自身は 2GB のアドレス空間しか利用できませんが、各論理パーティションで、最大 64 GB の実メモリーが利用可能です。これは、すべてのドミノ・パーティションを複数の OS/390 の論理パーティションに分散していたものを、1つの z/OS 論理パーティションに集約できることになります。

メモ：

利用可能なメモリーに対して、適切に NOTES.INI ファイルの変数を設定することは、メモリーを構成する際には不可欠なことです。慣例上、この変数とは NSF_Buffer_Pool_Size を意味します。しかしながら、R5.0.4 以上のバージョンでは、NSF_Buffer_Pool_Size の代わりに、ドミノ R5.0.4 で導入された PercentAvailSysResources を使用することを強くお勧めします。この値を常に監視することが必要ですが、特にハードウェアやソフトウェアの設定が変更された後は重要です。 (PercentAvailSysResources の詳細については、Domino R5.0.4 Release Notes（US）や Iris Today の「Managing memory allocation using NOTES.INI variables（US）」をご覧ください)

上に戻る

ユーザー・マニュアルのような設計やコーディングができるとは限らない

この哲学は、長年にわたって学術的なセッションに参加したり、技術文書を読んで試みてきたこととは全くの正反対だとみんなは知っています。講義や技術研修コースやコンファレンスでの好ましい訓練に従えば、アプリケーションは完璧に仕上がると信じている人もいるかもしれません。しかし、開発手法の純粋主義者になることで、よい性能が得られ、非常に多数のユーザーをサポートできるアプリケーションを常に開発できるとは限りません。成功する (つまり、スケーラビリティーやパフォーマンスが高い) アプリケーションの開発に新たな手法を取り入れる必要があります。

以下の具体的な2つの例がサーバー・パフォーマンス・チームが顧客アプリケーションの開発者と行ったミーティングで引き合いに出されました。

フィールド・タイプ：決定すべき重要事項
フィールド・タイプを決定する際に、各タイプが何をサポートし、それを実現するためのオーバーヘッドを考慮することが重要となります。このセクションでは、テキスト・フィールドとリッチ・テキスト・フィールドの話題を扱います。

リッチ・テキスト・フィールドは、フォントや添付、フォーマットなどさまざまな機能を持つため、アプリケーションがサポートする中で最も遅いフィールドの1つです。目標はこのフィールド・タイプの使用を最小限にすることです。これを達成するためには、余分にコードを書く必要がありますが、非常に多くのリッチ・テキスト・フィールドを用いる場合では、フィールド操作に関して新しい手法を取り入れることでパフォーマンスの改善が期待できます。

以下に、テキスト・フィールドとリッチ・テキスト・フィールドについて注目すべき点を挙げます。

中間テキスト・バッファーを使用することで、「オフライン」でテキストの内容を作成できます。これは、テキスト・フィールドを必要なときにリッチ・テキスト・フィールドに変換することで実現できます。これにより、可能な限りリッチ・テキスト・フィールドのオーバーヘッドを軽減できます。
もし可能なら、リッチ・テキスト以外のものを使用します。フィールドの定義をデフォルトのリッチ・テキストのままにしないでください。
テキスト・フィールドの操作をする場合、テキスト・フィールドにテキストを追加するのではなく、文字列同士を加えるようにしてください。これは、append 関数は、文字列を最初から最後まで読みなおすためです。
サーバー・パフォーマンス・チームは最近、不必要なリッチ・テキスト・フィールドを使用している顧客のお手伝いをしました。顧客は、ページを作成する際に、　appendText メソッドを用いていました。表面的にはうまく動作しているようでしたが、調査の結果、1行あたりで多数の appendText メソッドを呼び出していました。アルゴリズムとしては、ページを1行ずつ合成すると言うものでしたが、行を出力してページを作成する際に、非常に多くの appendText メソッドを呼び出していました。こういったネストされたループは、特定部分のコードが繰り返し実行されるためループの回数が多くなるほど影響が大きくなることはご存知だと思います。もっと理想的な時間内でページを表示できる優れたバッファーリング方法を使用すべきでしょう。

ロータス・プロフェッショナル・サービスに言わせると、リッチ・テキスト・フィールドもまた開発者の利益となるように動作します。アプリケーションは単純なテキスト・フィールドや、少数のリッチ・テキスト・フィールドを使用して開発されるため、負荷が大きな作業はサーバー上で実行されるためです。リッチ・テキスト・フィールドは索引化されないので、このフィールド・タイプの使用により潜在的なシステムのオーバーヘッドを軽減できます。

最後に、ここで一番言いたかったことは、一歩下がって、ある動作の背後で起こっていることを分析することの重要性です。さらに深く洞察することで伝統的でない手法で開発し、より良いアプリケーションの結果が得られるでしょう。

スクリプト・ライブラリー
サーバー・パフォーマンス・チームは、コンファレンスや Notes.net フォーラムでスクリプト・ライブラリーについて何度か相談されたことがありました。スクリプト・ライブラリーを使う主な理由として、アプリケーション中のコードの再利用性が高まるからです。スクリプト・ライブラリーは、ノーツ・クライアントや Web ベースのアプリケーションが共通のロジックを得るための中枢機能を果たします。逆にいえば、パフォーマンス・チームはスクリプト・ライブラリーのサイズ制限を見落としていました。これはアプリケーションの開発者が直面する問題です。これまでに、スクリプト・ライブラリーのサイズが 1MB を越えるような状況にも遭遇しました。これは特にスクリプト・ライブラリーが頻繁にアクセスされ、そのロジックがキャッシュされていない場合には懸念事項になります。たとえば、エージェントがスクリプト・ライブラリーを使用しており、エージェントを実行するたびに 1MB のスクリプト・ライブラリーがロードされるという状況を考えてみてください。この状況の対処方法の1つとして、スクリプト・ライブラリーを複数の小さなスクリプト・ライブラリーに分割し、共通に使用される機能はグループ化します。

設計ビューで、「設計」の「情報」タブのプロパティーからスクリプト・ライブラリーの判断ができます。これはライブラリーのサイズを示しています。具体的には次の通りです。

スクリプト・ライブラリーのバイト単位でのトータル・サイズは、「設計」プロパティーの「サイズ」から分かります。
ソース・コードのトータル・サイズを得るには、$ScriptLib フィールドの「データのサイズ」の値を調べます。(このようなフィールドは 64KB からオーバーヘッドを引いた値、この場合 R5 では 61,310 バイトになります。)
Lotus Script のオブジェクトのサイズを得るには、$ScriptLib_O フィールドの「データのサイズ」を調べます。同様に各フィールドはおおよそ 64KB あります。

サーバー・パフォーマンス・チームはスクリプト・ライブラリーの理想的な最大サイズを聞かれることもありました。このような質問はビューの設計で尋ねられることと同種です。答えを言うと、スクリプト・ライブラリーのサイズは、システムと使用法に依存するということです。それほど頻繁にロードされないスクリプト・ライブラリーは大きめでも構わないでしょうが、頻繁にロードする場合は、できる限り小さくしたり複数のライブラリーに分けると良いでしょう。サーバー・チームはこのような領域に関して特別な研究を行ったわけではなく、このような見解は、アイデアの推奨やこの問題を協調するに足る経験から導かれたものです。

また、ロータスノーツ＆ドミノ・アドバイザー・マガジン（注：日本では出版されていません）の 2000 年 9 月号の記事「Code for Better Performance」をご覧ください。著者のマット・ホルスはノーツ・アプリケーションの開発について、新しい戦略やヒントを提案しています。

アプリケーションの開発：アドバイスと実戦的な見識
ロータス・プロフェッショナル・サービスでは、さまざまなお客様のアプリケーションの調査に基づいて以下のような見解を示しています。

書き込み操作の頻度を分析し、できる限り少なくなるようにする。このセクションのテーマに続いて、書きこみ操作をグループ化するために、出力フィールドや文書の独創的な設計方法を見つけたいと考えていることでしょう。計算はできる限りメモリー上で行い、適当な終点でそれを書き込むようにすべきでしょう。
読み込みについては、1度で済ませてメモリー上でさまざまな操作をするようにします。1回で読み込み、メモリー上で複数に分けて操作するということです。

他に参照すべき情報源として、「ロータスノーツ/ドミノ R5 ベスト・プラクティス・ガイド」というデータベース設計の最適化について書かれた文献をお勧めします。

要約すると、背後で起こる処理を思い描きながら、アプリケーション・コードの流れやアーキテクチャーを調査することが重要ということです。また、伝統的なコーディング習慣に盲目的に従わず、パフォーマンスやスケーラビリティーを実際に改善できるアプリケーションの開発手法に寛大であることも重要です。

上に戻る

まとめ

この記事では、サーバーのパフォーマンスの管理手法や少しでもサーバーのパフォーマンスを改善するための手段をドミノの管理者に紹介しました。メモリーの利用率を監視し、報告された情報を得ることが重要で、管理者が複数パーティション・システムでのプラットフォームごとのメモリーの割り当て方の違いを理解する必要性についても述べました。最後にこの記事ではさまざまな視点からアプリケーションの開発を見なおし、教科書のコーディング・スタイルを考え直すことの必要性について強調しました。またリッチ・テキスト・フィールドやスクリプト・ライブラリーなどのサーバー負荷の高い要素の影響を最小化することでアプリケーションの開発を改善するためのヒントを示しました。

サーバーのパフォーマンスについての更なる情報は、Notes Bench Consortium（US）や Lotus IT Central Performance Zone（US）をご覧ください。

謝辞
この記事を仕上げるためにさまざまな人達や、チームに意見やデータを出してもらい非常に感謝しています。特に、ドミノサーバー・パフォーマンス・チーム、ロータス・プロフェッショナル・サービス・テクノロジー・チーム、ジェームス・グリスビーはこれらの記事で、非常に価値のある貢献をしてくれました。また、この記事のために寛大にも情報と時間を共有してくれたすべてのプラットフォームのベンダーに感謝しています。

著者について
キャロル・ジメットは 1994 年に Iris で働き始めました。彼女は、ドミノ・パフォーマンス・チームのサブ・リーダーで、パフォーマンスの評価やパフォーマンス・ツールの開発に責任があります。キャロルは誰もが簡単にパフォーマンスの問題を解決できるような方法を模索中です。彼女はまた、製品の品質の改善のためのホワイト・ボックス・アプローチにも関心があります。キャロルは、彼女の子供とサイクリングをしたり、ラケット・ボールをして楽しんでいます。また、ステンド・グラスをしたいと思っています。

エミー・E・スミスはロータスのユーザー・アシスタント・ライターのトップです。彼女はドミノやノーツの機能詳細を書いたり維持しています。彼女もまた、ノーツ UA Web チームのメンバーです。

上に戻る