 |
ソフトウェア >
Lotus >
Lotus Developer Domain >
翻訳技術情報アーカイブ >
Iris Today Archives
ドミノ サーバーの能力を引き出す パート2
|
|
|
by Carol Zimmet and Amy E. Smith
レベル：上級者
対象：Domino R5
原文の掲載：2000年9月1日
これは、ドミノの管理者やユーザー、コンサルタント、ビジネス・パートナーがたびたび直面する問題や勘違いを特定し、明らかにするというシリーズのパート2です。この記事では、追加で設定できる機能を紹介するほか、その機能の使用の有無によるドミノ サーバーのパフォーマンスや導入に関する影響や、キャパシティー・プラニングの決定に及ぼす影響ついて、基本的な考え方と共に解説していきます。ここでは、ありのままにデータを記録し、そこからどのように進めていけばよいかの推奨案を提示していきます。
ドミノ サーバーのパフォーマンスの改善や、導入、キャパシティー・プラニングの話になれば、最良の選択をすることは複雑な問題です。サーバーのパフォーマンスやスケーラビリティーの問題は複数の領域（メールの配送、データベース管理、アプリケーションの設計など）や、複数のプラットフォームに及びます。この問題を扱う上では、サーバーの設定やドミノの各コンポーネント間の相互関係が密接に関連しています。
このシリーズのパート1では、ドミノ サーバーや、まだ一般に十分広まっていない新機能に関する思い違いやユーザー・コミュニティーに広まっている間違った情報を一掃するような話題を扱いました。この話題では、管理者がシステム・パラメーターの調整や、ユーザー・ファイルの最適化、適切なアプリケーションの開発などにより、システム・パフォーマンスの改善に専念することができます。
ここで述べられる測定基準や情報の多くは最新のものでは無いということに注意してください。しかしながら、ドミノ サーバー・パフォーマンス・チームは新しい方法でこのような情報を調べており、アート（あれこれと推量すること）ではなくサイエンス（説明できるもの）としてパフォーマンスの分析をしています。ドミノのシステム管理者にとって、説明可能なパフォーマンスの分析法を導入することは、リスクを最小化し、新しいアイデアや、新しいことを試すことにつながります。
対象の大規模システムが、Sun Microsystems の Solaris/Sparc プラットフォームである場合を考えてみましょう。ドミノ サーバー・パフォーマンス・チームは、1プロセスあたりのファイル・ディスクリプタの数を増やすために、/etc/system にあるシステム・パラメーターを変更することで、Solaris/SPARC 上でスケーラビリティーの目標を達成しました。
Sun では、ドミノのような poll システム・コールを利用するアプリケーションを Solaris/Sparc プラットフォーム（リリース 2.6、現在は 2.8）上で実行する場合は、1プロセスあたりのファイル・ディスクリプタ数をデフォルト値の 1024 から引き上げることを推奨しています。（select システム・コールを利用するアプリケーションではデフォルト値の 1024 のままにしておくべきです）パフォーマンス・チームは、これを試みて、ドミノのシステム全体でのファイル・ディスクリプタ (fd) の数を限界の 64k まで引き上げることができました。以上の結果から、私たちは今ではこれを、高いスケーラビリティーを得るための必須事項として推奨するようにしています。
ファイル・ディスクリプターの数を 65536 にするには、以下の行を /etc/system ファイルに付け加えてください。（必ず以下の警告をお読みになってから行ってください）
set rlim_fd_max=65536
| 警告： | この後、変更を有効にするために、Solaris/SPARC システムを再起動しなければいけません。しかし、もし誤った入力をしたり、大きすぎる値を設定すると、システムを起動できなくなるかもしれません。 |
|
サーバーのプロトコルによって、必要なファイル・ディスクリプターの数は異なってきます。たとえば、NRPC は永続的なコネクションの (セッションを保持する) プロトコルですが、各ユーザーは大体4つまたは5つのファイル・ディスクリプターを使用します（各データベースごとにネットワークレイヤーのコネクションが必要となるからです）。つまり、10000 の NRPC のユーザーがいれば、50000 のファイル・ディスクリプターが必要となります。IMAP も永続的なコネクションのプロトコルで、ユーザーごとに3つまたは4つのファイル・ディスクリプターが必要となります。
| メモ： | R5.0.5 では、AIO スレッドを用いて効率よくシステムを利用することができます。（スレッドが足りない場合、起動時にサーバーが指摘します） |
|
コネクションレス型のプロトコルの HTTP では必要なファイル・ディスクリプターの数はかなり少なくなります。実際、NotesBench R5Webmail の報告で Sun は 8000 という値を推奨しています。しかし、もちろん 65536 に設定することもできます。65536 というのは単なる上限で、実際にそれだけの資源が割り当てられるというのは別問題です。
Sun の Solaris と Domino のチューニングについてのドキュメントについては docs.sun.com で、追加のパラメーターも網羅し、他のシナリオ(ユーザーの操作のプロファイル化したもの)でうまく動作させるための詳細事項も提供しています。
管理者は、ファイルを複数のドライブに分けることで、アクティブなユーザー数を増やしたり、サーバーのディスク・アクセスのパフォーマンスを改善できます。パフォーマンス・チームは最近、1ドライブ、2ドライブ、4ドライブの設定で、ブラウザーからのメールの作業負荷（一般的に見られる Web メールの作業負荷の変形）の評価を含むいくつかのテストを行いました。このテストで、複数のドライブのシステムでは、より多くのユーザーを扱えることが明らかになりました。（この方法は、アプリケーションのファイルやどのようなメールの設定にも適用して効果を得ることができます）
まず最初に、パフォーマンス・チームは、すべてのメール・ファイルが同じドライブ（I:）に存在する場合の設定のテストをしました。1000 人のユーザーと、ユーザーのメール・ファイルの処理についてのテストはうまくいきました。それから、1ドライブのシステムでユーザー数を 500 人ずつ増やしていきましたが、1500 人までしか増やすことができませんでした。この時点で、ディスクの入出力がボトルネックになっていることが分かりました。（下のテーブルのディスクの入出力の部分を見てください）さらにユーザー数を増やして、2000 人の場合を試しましたがうまく行きませんでした。つまり、システムが過負荷になり、2000 ものユーザー数を維持できなかったということです。さらに、Mail.Waiting が増加するにつれて、レスポンス・タイムも増加します。（この評価法で達成したユーザー数は、このテストの設定環境内でのみ意味を持ちます）
| メモ： | データベースの利用率の代わりの情報源として、"sh dbs" とコマンドをドミノのコンソールから入力することで、細かなデータを確認できます。これに関しての詳細な情報は、Iris Today 日本語版の セマフォ パート1 と セマフォ パート2 の記事をご覧ください。 |
|
次に、パフォーマンス・チームは、ユーザーのメール・ファイルを2つのドライブに分けました。実際には、2つの物理ドライブと、1つの共通のコントローラー・ポートを用いた構成になります。結果は、使われていないプロセッサーのパワーを活かして、ユーザー数を増やすことができ、より高い Domino.Requests.Per1Minute.Total を達成することができました。ここに示したディスクの入出力の情報はアクセスレートが妥当な範囲（これは製品レベルの標準的な値に基づいています）にあるということを示しています。
パフォーマンス・チームは、さらに一歩進め、データ・ファイルを4つのドライブに分けた場合の影響について調べて、その評価をしました。以下の表には、これらのテストで得られたキーとなるシステムの計測結果を示しています。
| 測定項目 | 平均値 |
最大値 |
| プロセッサー利用率（単位は%） | 46.90 |
84.92 |
| 空き容量（KB） | 1,516,109.97 |
1,692,352.00 |
| 平均ディスク・キュー長（I:） | 1.62 |
5.53 |
| 平均ディスク・キュー長（J:） | n/a |
n/a |
| Mail.Waiting | 0.94 |
4.00 |
| Server.Mailboxes | 4 |
|
| Domino.Config.ActiveThreads.Max | 100 |
|
| コンテキストの切り替え | 2,298.12 |
8,591.47 |
| Domino.Requests.Per1Minute.Total | 823.28 |
|
| Domino.Requests.Per1Minute.Total（平均） | 6.53 |
|
| Mail.Delivered（平均） | 53.51 |
|
| 測定項目 | 平均値 |
最大値 |
| プロセッサー利用率（単位は%） |
53.75 |
58.61 |
| 空き容量（KB） | 934,232.30 |
972,044.00 |
| 平均ディスク・キュー長（I:） |
2.39 |
3.93 |
| 平均ディスク・キュー長（J:） | 2.05 |
3.46 |
| Mail.Waiting |
1.13 |
3.00 |
| Server.Mailboxes | 4 |
|
| Domino.Config.ActiveThreads.Max |
125 |
|
| コンテキストの切り替え | 2,402.08 |
2,905.43 |
| Domino.Requests.Per1Minute.Total |
1,124.93 |
|
| Domino.Requests.Per1Minute.Total（平均） | 4.69 |
|
| Mail.Delivered（平均） |
79.92 |
|
| 測定項目 | 平均値 |
最大値 |
| プロセッサー利用率（単位は%） |
52.75 |
55.54 |
| 空き容量（KB） | 990,532.10 |
1,037,996.00 |
| 平均ディスク・キュー長（I:） |
0.95 |
1.12 |
| 平均ディスク・キュー長（J:） | 0.71 |
0.80 |
| Mail.Waiting |
1.06 |
3.00 |
| Server.Mailboxes | 4 |
|
| Domino.Config.ActiveThreads.Max |
100 |
|
| コンテキストの切り替え | 2,356.45 |
2,605.77 |
| Domino.Requests.Per1Minute.Total |
1,114.92 |
|
| Domino.Requests.Per1Minute.Total（平均） | 4.74 |
|
| Mail.Delivered（平均） |
79.34 |
|
上に示した測定項目は、テスト環境で通常よく見られるものです。このテストから判明した内容を以下に記します。
 |
メモリーの使用率（メモリーの空き容量：Availavle KBytes の逆の解釈になります）はドライブの数の増加に伴なって、高くなりました。恐らく、4ドライブの設定では、ディスクの入出力の改善やメモリー・バッファを少なくすることにより、メモリーの使用率が改善されたものと考えられます。 |
|
|
HTTP のアクティブ・スレッド数（この値は Domino.Config.ActiveThreads.Max から得られます。ノーツの NRPC クライアントのスレッド・プールと同一ではありません。）は追加された作業負荷を処理するために、同時ユーザー数と共に増加します。システムへのさらなるメモリー負荷に対する余裕があるので、これは特に問題ではありません。 |
|
|
ドミノ R4.x の統計には、HTTP スレッドに対して、Max、Allocated、Currently Used といった値が、エントリーされていました。ドミノ R5.x がサポートしている統計は、Max と Allocated だけになっています。必要があれば、Max の値が割り当てられた合計に達し、値は減少しません。常に Max 値を用いるというロジックを用いたコーディングがされています。今となっては、 Currently Used と Max は等価なので、Currently Used と Max の関係を分析する必要はありません。 |
|
|
さまざまな設定を用いた場合の I:ドライブの平均ディスク・キュー長の値は、さまざな設定を用いてもディスクの利用率が非常に高いことをしめしています（実際、平均ディスク・キュー長は増加している）。これは、1ドライブから2ドライブに変更した場合でも同様です。さらに4ドライブに設定することで、負荷に対する余地が増えたことが分かります。4ドライブの設定にすることで、その測定結果がはっきりと改善されたことが分かります。しかしながら、管理者は、自分が管理しているサーバー固有の問題を理解し、個々の問題を基にして最適なドライブの設定を評価する必要があります。 |
|
|
HTTP サーバーの使用状況は、ユーザー数を 1500 から 2000 に増やすと増加しました。これは、メール配送の総計と、処理されたHTTP サーバーへのリクエストの総計から測定しました。これはディスク入出力のボトルネックが最小化されたときにドミノ サーバーが、さらにどれぐらいの作業負荷を処理できるのかということを示しています。HTTP リクエストのレート（処理された合計）をユーザー数で割ると、ユーザー数が 1500 から 2000 に増加したときには、平均値が減少しているということが分かります。これは、HTTP の処理に割り当てられたスレッドの数が十分に利用され、リクエストが処理待ちのキューにキューイングされているという指標になります。このHTTP リクエストには、メール送信のリクエストも含まれていますので、Mail.delivered の平均値がどの程度上昇したかを確認することができます。データを複数のドライブに分けることで、ボトルネックを解消でき、ドミノ サーバーはより効率的に処理を行うようになります。
|
|
|
コンテキストの切り替えは、あるスレッドから別のスレッドに切り替えるレートを示しています。このスレッドの切り替えは、いくつかの理由で発生しますが、重要なことは、システム内のユーザー数が増加したときに、コンテキスト切り替えの度合いが危険な領域に達することの無いようにする点です。このような領域では、システムは実行すべきタスクのために費やすべき処理時間のほとんどを、コンテキストの切り替えに使用してしまいます。この現象は、システム時間とユーザー時間とを比較することで確認できます。（下のグラフをご覧ください）先程の表で示したように、テストで得られた値ではコンテキストの切り替えレートは上昇していないことを示しています。 |
|
|
グラフに示されたデータは、ユーザー数が 2000 で、2ドライブのシステムを用いたときのものです。最初のグラフは、コンテキストの切り替えレートそのものを示しています。ここでは、その値の範囲と、振幅の回数が読みとれます。2つ目のグラフと組み合わせてみることで、コンテキストの切り替えレートと、プロセッサーの振る舞いとの関係を見ることができます。さらに、この表では、プロセッサーが消費しているパワーを特権時間、プロセッサー時間、ユーザー時間のそれぞれに分けて示しています。 |
|
| |
|
|
|
メール・スループットは容認できるレベルです。この記事のあとの方でも紹介しますが、Mail.Waiting はルーターのタスクが、リクエストを処理出来ているかを示す指標になります。リストにある Mail.Waiting の平均値は、かなり妥当な範囲にあります。これは、どの設定でも、平均がおおよそ1に近いところにあるということから分かり、メールを受け取ると、ただちにメールを配送していることを意味しています。つまり、要求に追いついて、十分なペースで早く処理をしているということになります。このような場合、1分間に 400 通近くのメールを生成します。 |
テストの結果からも分かるように、データベースを分散させることの有効性が確認できました。データベースを分散すると、ドライブの利用率を改善するだけでなく、ユーザー数を 33 パーセントも増加することができ、管理や、TCO のことを考えると非常に価値があることと言えます。
AS/400 でのディスク装置の設定
デフォルトで AS/400 は、ディスク・ユニットに等分にデータを分けますが、これが AS/400 の長所だと言えます。これにより、すべてのディスクのアームを使用し、ディスクの利用がバランスよく分散されるので、システムのパフォーマンスは向上します。また、デフォルトの設定より補助記憶装置プール（ASP）の設定を優先させることもできます。（詳しくは、OS/400 Hierachical Storage Management V4R4、QB3A0Z01をご覧ください）
デフォルトの設定ではで、ドミノ サーバーは、AS/400 の基本記憶装置プール内で実行されます。基本記憶装置プールとは、共有システム・プールで、そこで数多くのオペレーティング・システムの機能や、システムのジョブが実行されます。システムの他のプールに割り当てられていない主記憶装置は、すべて基本記憶装置プールに格納されます。一般的に、このデフォルトの設定を用いると最高のパフォーマンスが得られます。というのも、AS/400 は必要になれば資源を割り当てることができるからです。しかしながら、サーバーを独自の記憶装置プールに割り当てたくなる場合もあるかもしれません。たとえば、特別な優先順位、メモリーなどを指定してドミノ サーバーを独自の記憶装置プールに配置したくなるかもしれません。もし、サーバーを別のプールに隔離しても、システムは自動パフォーマンス・チューニングの機能を用いて資源を移動させ、さらに移動された資源に対してさまざまな制御をすることができます。（記憶装置プールの生成については、Work Management for Version 4 Release 4、SC41-5306をご覧ください）
| メモ： | ここでは詳しく説明しませんでしたが、メール配送時には、MAILn.BOX ファイルに非常にアクセスが集中します。ディスク・アクセスの集中を避けるために、MAILn.BOX を独自のディスク・ドライブに移動するというのも検討に値します。（ドミノのコンソール・コマンド sh dbs や sh stats を用いて、このような測定情報を得ることについては、このシリーズのパート1の記事をご覧ください） |
|
簡単にパフォーマンスを向上させる手段の1つとして、NOTES.INI ファイルの、NSF_DbCache_MaxEntries パラメーターを変更するというのがあります。このパラメーターにより、サーバーがデータベース・キャッシュ内に一度に格納できるデータベースの数を変更できます。Database.DbCache.MaxEntries の統計値は、設定されたパラメーターと密接な関連があり、キャッシュ内に保持できる最大データベース値を表示します。
| メモ： | このパラメーターは、ドミノ サーバーのデータベース・キャッシュの基本概念と同様に、「R5 システム管理ヘルプ」に記述されています。しかしながら、ここで示されるいくつかの情報は、文書中に書かれた内容と異なり改定されたものとなっています。これは、マニュアルが出版されてから得られた追記事項を反映したためです。 |
|
データベース・キャッシュは、直近にオープンされたデータベース・ファイルのキーとなる情報をメモリー中の決められた領域に保持します。データベースの情報がメモリーに格納されていると、エンド・ユーザーがデータベースを参照したときのレスポンス・タイムが良くなります。これはディスク入出力装置に比べて、メモリーのほうが早くデータベースのキー情報にアクセスできるからです。データベースの数が増加すると、より多くのメモリーが使用され、より多くのエントリーがキャッシュ内に保持されることになります。（そのためメモリー内でマッチする可能性がより高くなります）
使用可能メモリーの総計とキャッシュのためのメモリー容量との間には常にトレードオフの関係が存在します。非常に多くのメモリーがキャッシュに割り当てられると、他のサーバータスクのメモリーを奪うことになります。そのために、データベースのキャッシュ・サイズを正確で効率的に割り当てることは、匠の技で成し遂げるか、技術的な分析により成し遂げるかといった世界の話になります。あまりに多くの非常に多くのエントリーがデータベース・キャッシュにあると、利用可能なメモリー量が減少し、他の処理でメモリーが利用できなくなるために、サーバーの速度が低下します。
キャッシュで許される最小のエントリー数は 25 です。この値は、大規模な設定では実際的な数字ではありません。多くの場合、NSF_Buffer_Pool_Size の値を 300K で割って得られた結果を用います。もし結果が、25 よりも小さければ 25 を用います（このようなことは、ほとんどありませんが）。つまり、計算結果と 25 を比較して大きいほうを用います。サーバーのプラットフォームに依りますが、可能な最大値は 10000 です。AS/400 や RS/6000/AIX、Windows NT、Windows 2000、Solaris/SPARC のどれもが、最大 10000 エントリーをサポートします。もし NSF_DbCache_MaxEntries が定義されていない場合、システムの利用可能メモリーからデフォルト値を推定して使用されます。これはまず、NSF_Buffer_Pool_Size の値を取り出し（ドミノ サーバーのコンソールから Database.Database.BufferPool.Maximum.Megabytes の値を調べてみてください）、そして使用するデフォルト値が計算されます。そして、最大値と最小値が違反しないことを確認する必要があることから、notes.ini への NSF_Buffer_Pool_Size の値の設定はあまりおすすめできません。もし値を設定した場合、環境に適した設定になっていることを確認してください。さらに、バッファ・プールのサイズが、他のパラメーターに副作用連鎖作用を及ぼすこともあります。
以下では、アナリストのシステムからいくつかの例を示します。
- システム・ブレード (サーバー名) は4GB のメモリーを持っており、単一のパーティションで、以下のような値に設定されています。
Database.Database.BufferPool.Maximum.Megabytes = 747
Database.Database.BufferPool.MM.Reads = 0
Database.Database.BufferPool.MM.Writes = 0
Database.Database.BufferPool.Peak.Megabytes = 7
Database.Database.BufferPool.PerCentReadsInBuffer = 97.12
Database.DbCache.CurrentEntries = 0
Database.DbCache.HighWaterMark = 0
Database.DbCache.Hits = 0
Database.DbCache.InitialDbOpens = 33
Database.DbCache.Lookups = 0
Database.DbCache.MaxEntries = 2241
Database.DbCache.OvercrowdingRejections = 0
- 512MB のメモリーを持つ Hades2K (サーバー名) も単一パーティションのシステムで以下のような値に設定されています。
Database.Database.BufferPool.Maximum.Megabytes = 171
.
.
.
Database.DbCache.MaxEntries = 513
一般的に、Database.DbCache.MaxEntries の値を任意に設定してデフォルト値ではなく優先してその値を使うようにし上書きし、ユーザーがアクセスするデータベースのファイル数に調節することで、データベースのキャッシュのパフォーマンスがよくすることができます。メール・サーバーの設定としては、Database.DbCache.MaxEntries をアクティブなユーザー数に近い値に設定することでパフォーマンスを向上できます（これは多くのユーザーが少数のファイルにアクセスするというようなアプリケーション・サーバーには当てはまりません）。さらに一般にいくつかのシステム用のデータベースが使われるので、サーバー・パフォーマンス・チームでは、Database.DbCache.MaxEntries の値をアクティブなユーザー数よりも 50 大きな値に設定しています。
たとえば、2700 人のメールのユーザーが存在し、各自が自分のメール・ファイルを持っているとします。この場合、3000 という値は申し分が無いと言えます。しかし、2700 人のアプリケーション・ユーザーがいて、全員が同じアプリケーション・データベースをオープンするというような場合、デフォルト値で十分と言えます。（注意：ここで推奨している方法を用いるとメモリーの使用量が増加します。そのため、空きメモリーが十分に無い場合は、ここで述べた方法を適用すべきではありません。）
また、Database.DbCache.Current を監視しておくべきです。これにより、データベースのキャッシュが実際にどれほど利用されているのか分かります。Database.DbCache.CurrentEntries の値と Database.DbCache.MaxEntries の値が等しく、利用可能な空きメモリーが十分にある場合、NOTES.INI の値を設定すべきです。
| メモ： | メモリーに空きがあるかどうかを見るために Mem.Free や Mem.Available を用いないでください。この記事のシリーズのパート1に、この問題に関しての情報が掲載されています。 |
|
また、Mail.DBCacheEntries をキャッシュの使用状況を判断するのに用いることができます。ルーターのデータベースのキャッシュのデフォルト・サイズは（NSF_BUFFER_POOL_SIZE_MB*3）に設定されていうることに注意してください。Mail.DBCacheEntries を監視することで、システムが最大限にキャッシュを利用しているかどうかということや、Mail.DBCacheHits と Mail.DBCacheReads を比較することで、どれほどキャッシュが効率良く利用されているかが分かります。
多数のユーザーが少数のファイルにアクセスしているというように、システムがアプリケーション・サーバーよりであることをサーバーの利用状況から分かる場合、この種の変更を加えてもそれほど利点は無いでしょう。このような場合、アクセスされたデータベースはすでにデータベース・キャッシュ内にあり、スワップ・アウトされることはありません。データベースのキャッシュ・サイズが増加してもデータベースの情報へのアクセス時間に影響を与えることはありません。
どのようにしてこの設定をうまく活用するのか思案中であれば（そうであることを願いますが）、ベンダーが NotesBench Consortiumの Web サイトに投稿したレポートを見て、ベンダーは NOTES.INI ファイルをどのような設定にしているのかを確認してください。ベンダーは、ユーザーのレスポンス・タイムが最小になるように、あらゆる設定や調整を行っています。
要約すると、各設定とドミノ サーバーが異なるため、DbCache の値を設定することはお勧めしません。データベース・キャッシュはメモリーに依存しており、NOTES.INI ファイルを変更していなければ、デフォルトでは NSF_Buffer_Pool の3倍の値になっています。まず最初に管理者が確認すべきこと点は、サーバーのメモリー容量に加えて、サーバーにあるデータ・ファイルの数です。たとえば、2500 個のメール・ファイルがある場合、NSF_DbCache_MaxEntries を 2550 に設定します（log.nsf や name.nsf などのために余分に 50 エントリー用意します）。実際には、そのようなファイルはもっと少ないです。
ドミノのフェイル・オーバーの機能を使用しながら適切な設定を施したいと思ったとします。これは必ずしも現在のシステムとドミノの利用状況パターンによっては、フェイル・オーバーのメカニズムが動作するとは限りません。いつフェイル・オーバーが動作させるべきかを判断するために Server.Availability 統計情報が用いられます。また、クラスタでフェイル・オーバーをサポートする余裕のあるシステムが必要となります。クラスタ設定のための設計は難しい問題ですが、計画を練って分析を行った後でさえも、期待したパフォーマンスが出ているかどうかを監視しつづける必要があります。出発地点として、フェイル・オーバーのためにシステムのServer.Availability の値を観測するとよいでしょう。
| メモ： | クラスタ内のすべてのシステムが過負荷になった場合（このようになることは避けるべきです）、フェイル・オーバーを導入しないほうがよいでしょう。 |
|
実装システム微調整することができるシステム・コントロールがあります。
前と同じように、オリジナル・システムが規模にあったもので無ければ、微調整を用いたところでスケールの大きな問題を解決することはできません。NOTES.INI ファイルに、Server_Availability_Threshold と Server_Transinfo_Normalize という2つの変数がありますが、これらはクラスタのフェイル・オーバーが滑らかに行われることを保証するために用いられます。適切なフェイル・オーバーとは、サーバーが過負荷になる前に、ドミノ サーバーが新しいユーザー・コネクションを拒絶する境界線を予想できるということを意味しています。このような慎重な計画により、現在利用中のユーザーには良いレスポンス・タイムが保証され、新しくコネクションを張ろうとしているユーザーも良いレスポンス・タイムを得ることができるのです。
最初のほうの NOTES.INI のパラメーターの Server_Availability_Threshold は Server.Availability の統計情報に連動して設定され、Server.Availability が Server_Availability_Threshold パラメーターに設定したしきい値に達すると、サーバーはユーザーのリクエストを拒絶し始めます。フェイル・オーバーの特性を最大限得るには、しきい値を高く（95-97）設定する必要があります。
さらに、Server_Transinfo_Normalize を設定する必要があります。これはドミノ サーバーのレスポンス・タイムを正常な値内に収めるようにするもので、フェイル・オーバーの処理は、予定通り行われるようになるでしょう。この値は、環境に応じて調節します。
ここで重要なことは、サーバーのパフォーマンス・パラメーターや統計情報は、これからの計画の助けとなるだけでなく、導入後のシステムの監視やチューニングの助けにもなることです。（ユーザーの作業負荷、ユーザー数、ハードウェアの設定の変更など）設定に変更があれば、パラメーターの値をチェックする必要があります。このような不断の努力により、サーバーのパフォーマンスが改善され、ユーザーに高い信頼性を提供できることになります。
クラスタリングに関する詳細については、Iris Today の「Optimizing server performance:Domino cluster Part 1 (US)」と「Optimizing server performance:Domino cluster Part 2 (US)」をご覧ください。ロード・バランスについては、Iris Today の「Workload balancing with Domino clusters (US)」をご覧ください。
これまでノーツやドミノ・アプリケーションの最適化に関する開発技術についての情報の多くは、ユーザー・コミュニティの間で共有されてきました。そのような情報は以下のようなところで見つけることができます。
このような媒体に掲載されている情報の例として、The View magazine には、GetNthDocument コードと GetNextDocument コードを用いた場合の比較をした記事が扱われたことがあります。。そしてこれまでに、この記事は非常に数多く参照され、ドミノの開発者コミュニティーに大きな影響を与えました。実戦での使用やテスト分析でも、特に非常に多くのドキュメントを扱う場合は、GetNextDocument コードを用いるべきであるということが実証されています。
これは、サーバーへの負荷を減らす、効率の良いアプリケーション開発の習慣の例といえます。他にも無数の習慣が存在します。もし、あなたが開発者なら、開発習慣がサーバーにどれほどの負荷を与えるのかを考える必要があります。これには、ループの内側には何があるかということや、1回のディスク・アクセスにはどのような種類の操作が含まれるかなど、コードの裏側でなされていることに対する洞察力が要求されます。
よいコーディング習慣は、アプリケーションによい影響を及ぼすでしょう。アプリケーションが使用する LotusScript や ドミノのバックエンド・クラス、他のコンポーネントだけがアプリケーションのパフォーマンスに影響を与えるわけではありません。不適切なコーディング習慣は、しばしば問題の原因となり、アプリケーションがその部分で非常に多くの時間を費やしていることを分析するのにも時間がかかります。健全なアプリケーション開発習慣により、アプリケーションがサーバーでのボトルネックにならないようにすることで、サーバーのパフォーマンスを改善することになります。
もしサーバーが好調に動作していても、よい習慣の下でアプリケーションが開発されたという保証にはなりません。つまり、パフォーマンスに問題があるとしても、必ずしも、サーバーが原因ではないこともあるのです。よりよいパフォーマンスを得ようと思えば、アプリケーションの分析が、手軽でよいアプローチといえます。
アプリケーションの動作が貧弱で、パフォーマンスの改善が必要なときのために、以下にいくつかの着目点を挙げておきます。ビューのオープンやスクロールが遅ければ、次の点をチェックしてください。
- データの量。アーカイブする時期かもしれません。
- 日付や時間データを用いたビューの計算式。
- ビューに表示される文書に読者フイールドや作成者フイールドがあるかどうか確認します。これが設定されていると、文書毎にビューに表示する際に計算が発生します。
読みこみ専用モードの場合でも、文書の作成や保存、オープンが遅ければ、次の点をチェックしてください。
- 特にキーワード・フィールドで、@Db 式が多いかどうか。
- （Web）QueryOpen や（Web）QuerySave エージェントを用いているかどうか。
- スケジュールされたエージェント。特に、文書が新しく作成されたり、更新されると実行されるエージェントや、毎時間もしくは、それより頻繁に実行されるエージェント。このようなエージェントは、処理が高速に行われるはずであり、ログから情報をかなり素早く見つけることができます。経験則として、何か特別な理由が無い限りスケジュールされたエージェントで数秒以上かかるものはありません。
- ロジックやコーディングが貧弱である。つまり、文書のコレクション (DocumentCollection) の方法が不適切で、実行時間がかかり過ぎてしまう。
The View Magazine にバーク・ラッセルが、｢オブジェクト志向デザインのテクニックを用いた LotusScript コードのパフォーマンス・テスト｣ という記事で、パフォーマンスに問題のあるプログラムの各部分を分離するテクニックを紹介し、どの部分がボトルネックになっているのかを特定するユーティリティーを提供していましたが、そのユーティリティー・プログラムを記事の概要ページからダウンロードできます。
このシリーズのパート1でも述べましたが、クライアント・レベルの動作状況がサーバー・レベルのパフォーマンスに大きな影響を与えます。このシリーズでの調査で、サーバー・パフォーマンス・チームは、ドミノ サーバーの管理者が、サーバーのパフォーマンスを向上させるために、クライアント・レベルで改善できることがあることを見つけました。
その1つとして、イメージ・リソースの格納方法について問題です。アプリケーション開発者は、R5 で新たに導入されたデータベースのイメージリソースの格納方法を利用するべきです。データベースでイメージを扱う方法は他にもありますが、イメージリソースの機能では、イメージを1つの場所に格納しておき、それを使用する場合に常にその場所を参照するようになり、イメージの利用方法としては最も効率的です。イメージに変更があれば、その内容はイメージが参照されると反映されます。ロータス・プロフェッショナル・サービス・テクノロジー・チーム(サポート・チーム)の経験によると、アプリケーション開発者は、パフォーマンスや管理の面で、この機能を現在使っておらず、パフォーマンスを上げる余地があると見ています。
ドミノ サーバーの膨大な統計リストがあっても、それらの意味は明確ではないことが多いですが、それらの中には、ドミノ サーバーの理解を助けてくれる隠された宝石のように貴重な情報もあります。これから説明する、様々な機能に関して、それぞれの統計情報を正しく評価して、必要なら先手を打つことができます。このセクションでは、特にメール配送 NRPC によるメール配送についての話題を扱います。（ルーターは、IMAP や Web メールなど、NRPC に限らずすべてのタイプのメール配送の操作をします。そのため、ここで紹介する情報は、他のメール・プロトコルにも応用して考えることもできます）
以下に示した統計情報は、パフォーマンスの観点から見た Mail.Delivery の統計分析のみに集中したものとなっています。ここで注意すべきことは、ここで紹介する分析は統計情報の Mail セクションだけを見ていることです。メール処理のパフォーマンスに関する全体像を把握、対処するには、プラットフォームやデータベースの統計情報も分析する必要があります。
| メモ： | セットアップ終了後に最初にサーバーを起動した場合、メール・ルーターが動作していても。以下に示すドミノの統計情報の一部が表示されるまでに数分の時間がかかることがあります。また、使用されていない機能があれば、それに関係するドミノの統計情報は統計情報リストに表示されません。たとえば、SMTP の配送を行わない場合は、ドミノの統計情報リストに SMTP の情報は表れません。 |
|
Mail.Waiting
配送待ちのメールの件数。正確に記すと、ルーターにあり、配送先に転送または配信されようとしているメールの件数。この値は、すべての MAIL.BOX ファイルの累計になります。
ベンチマーク測定の環境で得た結果から、この値がメール・システムの分析を行う上で最も利用価値が高いものであることが分かっています。パフォーマンスの分析を行う場合には、この値が増加する場合には、メール・ルーターの処理が入ってくるリクエストに対して追いついていないことを示しています。しかし、実際に使われている環境においては、この見方は必ずしも正しいとは限りません。というのも、メール・サイズには偏りがあり、また、リクエストがピークに達する時間もありますから、一概に結論づけられないのです。さらに重要なことは、目的地のサーバーあるいは、次に転送するサーバーが利用できない場合、メール・アイテムはローカル・サーバーに蓄積されます。このような状況は、パフォーマンス分析の実験環境では通常想定しておらず、テストされていないことです。しかし、実際の環境ではこのようなこともありえるでしょう。
Mail.WaitingForDNS は、DNS が順調に動作しているかどうかの指標になります。ドミノ・ルーターは DNS で転送先ドメインを参照して、SMTP で接続すべきホスト名を取得します。DNS がダウンしていたり、十分なパフォーマンスが得られていない場合は、この値は上昇します。これは、ネットワークの設定のボトルネックを示しており、この時点でトラブル・シューティングを行うべきです。
Mail.WaitingRecipients は、Mail.Waiting キューにある各メールの受信者の合計数を表しています。ただし、ここに示される人数の内の一部には既にメールが配送されている可能性がありますので注意が必要です。たとえば、メールがルーターに到着し、受信者が 10 人いるとします。そして、そのうちの9名はメールを受け取り、残りの1名はサーバーがダウンしているため受け取れなかったとします。このような場合、Mail.WaitingRecipient の値は 10 となります。
Mail.TotalPending
これは、すべてのアクティブな MAIL.BOX ファイルにある、現在のメールの件数を表しています。（これはドミノ R 5.0.4 で新しく導入されたものです。）複数の MAIL.BOX ファイルがサーバー上で利用可能なら、この値は、その時点で MAILn.BOX データベースにあるすべてのメッセージの数を表しています。この値には、送信待ちメールのほかに、送信無効メール（配送不可能なメール）や、送信処理を一旦止めている (ホールドしている) メールが含まれます。
Mail.TotalPending は（サーバーへの負荷を軽減するため）5分間隔で更新され、他のプロセスの処理状況に関係なく定期的に実行されます。この更新処理は、ルーターでなくサーバー・プロセスにより行われ、統計情報を管理、監視します。そのため、ルーターがメールを処理した直後のタイミングで更新されるわけではなく、ルーターがメールを処理中、あるいは処理前といった状況にかかわらずデータが収集されます。その結果、Mail.TotalPending の値は増加することがあります。実際の運用では、Mail.TotalPending は、すべての MAIL.BOX ファイルにあるメールの件数を表しており、メッセージがルーターで処理されたり、MAILn.BOX から削除されると、その値は減少します。
Mail.Delivered
この値は、ローカル・サーバーで受信ボックスが更新される受信者の数を表しています。たとえば、1通のメッセージが3人の受信者あてにローカル・サーバーに配送されると、3とカウントされます。
Mail.TotalRouted
これは、転送、あるいは配送されたメッセージを受け取る受信者の数を表します。たとえば、物理的に1度に、受信者が3人いる1通のメッセージが1つの目的地に配送されると、この値は3になります。
この値は、プロトコルによって分けることができます。
Mail.TotalRouted = Mail.TotalRouted.NRPC + Mail.TotalRouted.SMTP
Mail.Deliveries
これは、指定したユーザーにたどり着くまでに、メール・ファイルを操作した回数を表します。これは、ユーザーのメール・ファイルが開かれたり、閉じられた回数と一致します。また、この値は常に、Mail.Delivered 以下になります。たとえば、1人のユーザー宛に2つのメッセージがあり、ルータがメール・ファイルを1回オープンし、2つのメッセージを配送し、そしてメール・ファイルを閉じた場合、Mail.Delivered は2で、Mail.Deliveries は1になります。
Mail.Transferred
これは、ドミノ サーバーから指定した目的地（もしくは、次の中継地点）まで転送されたメッセージの件数を表します。受信者が3人で同じ目的地の1つのメッセージは、1と計算されます。同じメッセージで、受信者が2人で、目的地が異なる場合は、2と計算されます。
この値もまたプロトコルで分けることができます。
Mail.Transferred = Mail.Transferred.NRPC + Mail.Transferred.SMTP
Mail.Transferred.TotalKBT もまた同時に計算されます。これは、転送したメッセージの合計の KB 数を表します。
Mail.Hold
これは、管理者要求アクションを反映した値になります。ルーティング状況をもったメッセージの件数になります。管理者が、未配達のメールを保持するという設定をしていると、RoutingState の値が設定されたメッセージの件数となります。
他のメール統計情報
管理者の立場から見て、他に有用なドミノの統計情報として、Mail.AverageDeliverTime や Mail.MaximumDeliverTime、Mail.MaximumSizeDelivered といったものがあります。
例：以下にいくつかの分析結果を示します。
| |
Mail.
Waiting |
Mail.
WaitingForDNS |
Mail.Waiting
Recipients |
| 01/28/00 12:54:31 PM |
3 |
0 |
9 |
| 01/28/00 12:55:31 PM | 0 |
0 |
0 |
| 01/28/00 12:56:31 PM | 4 |
0 |
12 |
| 01/28/00 12:57:31 PM | 3 |
0 |
5 |
| 01/28/00 12:58:31 PM | 2 |
0 |
6 |
| 01/28/00 12:59:31 PM | 2 |
0 |
6 |
| 01/28/00 01:00:31 PM | 1 |
0 |
1 |
| |
Mail.
Hold |
Mail.
Delivered |
Mail.
Deliveries |
Mail.Total
Routed |
| 01/28/00 12:54:31 PM |
3 |
21972 |
21956 |
21972 |
| 01/28/00 12:55:31 PM | 0 |
22248 |
22222 |
22248 |
| 01/28/00 12:56:31 PM | 4 |
22511 |
22486 |
22511 |
| 01/28/00 12:57:31 PM | 3 |
22750 |
22725 |
22750 |
| 01/28/00 12:58:31 PM | 2 |
23025 |
23003 |
23025 |
| 01/28/00 12:59:31 PM | 2 |
23252 |
23231 |
23252 |
| 01/28/00 01:00:31 PM | 1 |
23503 |
23477 |
23503 |
これまで説明してきたことだけで、皆様が次のサーバーの計画する際の助言として十分ではないし、誤解を拭うのに十分であるとは言えないと思います。ただ、私たちはすでに非常に多くの情報を共有しており、プレゼンテーションや、Notes.net の記事や投稿記事にも情報を掲載するようにしています。新しいサーバーや追加のサーバーに投資しようとしているなら、情報源や以下のリストをチェックすべきです。このリストは、クロスプラット・フォームのツールや情報の素晴らしい要約です。Lotusphere で、この種の情報を見つけることが難しいという声があったので、それに対する答えになっています。
| メモ： | このリストには各ベンダーへのリンクは含まれていません。各ベンダーのサイトへのリンクは NotesBench Consortium の Web サイトをご覧ください。 |
|
| プラットフォーム |
キャパシティー・プラニング・ツールや技術白書 |
| IBM Netfinity NT |
|
IBM Netfinity サイジング・ツール |
|
| Compaq NT |
|
Compaq Proliant Sizer for Domino |
|
| Dell NT |
|
Dell の担当者にお聞きください。 |
|
| Sun Solaris/UNIX |
|
| RS6000/AIX |
|
内部ツール。IBM AIX の担当者にお聞きください。 |
|
「RS6000 resources」 |
|
「Resource Tuning of Lotus Domino on AIX:Quick Reference Guide」 |
|
| AS400 |
|
AS400 用のドミノのパフォーマンス・ページに、AS400 の作業負荷評価ツールなどのサイジング情報へのリンクがあります。 |
|
技術白書： |
「Evaluating Appropriate workloads for the AS400e Dedicated Server for Domino」
「AS/400 Performance Tuning for Domino」
「Domino for AS/400 Performance Tuning」 |
|
| S/390 |
|
ドミノの管理者になると、サーバーのパフォーマンスを最適化について継続的に問題の解決にあたることになります。サーバーが提供する情報を理解する必要があるだけでなく、その情報を適切に設定に反映させる必要があります。管理者にはまた、パフォーマンスの問題について、事前の策を講じる機会があります。それには、すべての情報を集め、それらをうまく用いてサーバーを調整し、より高いパフォーマンスを実現することができます。より高いレベルでは、管理者は組織でのアプリケーションの開発習慣のレベルからサーバーのパフォーマンスを高めることを保証するように取り組むことができます。
サーバーのパフォーマンスに関するさらなる情報は、NotesBench Consortiumをご覧ください。
謝辞
この記事を仕上げるためにさまざまな人達や、チームに意見やデータを出してもらい非常に感謝しています。特に、ドミノ サーバー・パフォーマンス・チーム、ジェームス・グリスビー、マリア・クリロバ、ロータス・プロフェッショナル・サービス・テクノロジー・チーム、ロータス・サポート、そしてメール・ルーティング・チームはこれらの記事で、非常に価値のある貢献をしてくれました。私たちは、この記事のためにデータの生成や分析をしてくれた、サーバー・パフォーマンス・チームのルイス・ブラッドバードやリチャード・カノスキーに感謝します。
著者について
キャロル・ジメットは 1994 年にアイリスで働き始めました。彼女は、ドミノ・パフォーマンス・チームのサブリーダーで、パフォーマンスの評価やパフォーマンスツールの開発に責任があります。キャロルは誰もが簡単にパフォーマンスの問題を解決できるような方法を模索中です。彼女はまた、製品の品質の改善のためのホワイト・ボックス・アプローチにも関心があります。キャロルは、彼女の子供とサイクリングをしたり、ラケットボールをして楽しんでいます。また、ステンドグラスをしたいと思っています。
エミー・Ｅ・スミスはロータスのユーザー・アシスタント・ライターのトップです。彼女はドミノやノーツの機能詳細を書いたり維持しています。彼女もまた、ノーツ UA Web チームのメンバーです。
|
|
|
|
