Domino/400 R5 Performance Tuning Tips (聞き書きモード)

聞いたこと/読んだことを書いておきます。
さすがにわたくしパフォーマンスをテストできるような環境を持ち合わせていませんので、どなたか試された方はご一報いただけると幸いです。
ただし、こうしたシステム設定だけでパフォーマンスが劇的にあがる、なんてことはほぼまったくありえません。
それ以前にマシンのキャパシティ自体がきちんと足りているかどうか、くれぐれもご確認ください。

On−Disk Structure
DominoがR5になって大きく変わったもののなかにデータベースのフォーマットがあります。
データベースのプロパティを見てみてください。
R4.xのものは「ODSバージョン 20」
R5.0のものは「ODSバージョン 41」
と表示されています。(「ODS」とは「On-Disk Structure」の略です
この新しいデータベースフォーマットは、よりRDBのように信頼性を高く、I/Oコストを下げ、パフォーマンスをあげるために開発された、ということです。
ですので、R4.xからR5に移行し、データベースフォーマットを変更するだけでいくらかのパフォーマンス向上がある場合もありえる、ということでしょうね。
このODSのバージョンはあくまでノーツデータベースファイルの物理的なフォーマットですので、テンプレートとは関係ありません。
物理的に.NSFファイルをコピーした場合R4.xでは使用できなくなるだけで、レプリカなどには影響ありません。
データベースの圧縮を行えば、フォーマットの変換は行われますので、まずR5へ移行の際は最初に試してみる価値はありそうです。

「未読マークを使用しない」
データベースのプロパティで「詳細」タブに「未読マークを使用しない」というものがあります。

ノーツのアプリケーションによっては未読マークをいちいちトラックする必要がないものがあります。
ちょっと考えただけでも、各ユーザーのためにいちいちひとつひとつの文書の未読マークを維持管理するなんてすごいパフォーマンスをロスしそうな処理ではないでしょうか?
必要ないアプリケーションでは積極的に「未読マークを使用しない」にチェックしてみる価値はありそうな気はします。
なんでもAS/400では20%ちかくCPU使用率が、30%ちかく平均レスポンスタイムが、それぞれ下がったケースがあるそうです。

パーティションサーバーあたりのユーザー数の増加
UNIXやNTでパーティションサーバーを稼動させる場合、CPUの数と同じかそれより少なくすることが望ましい、とされています。
唯一の例外がAS/400で、稼動できるパーティションサーバーの数はCPUの数にまったく関係ありません。
また、それぞれのパーティションサーバーでサポートできるユーザー数がR5になって劇的に増えています。
ひとつのパーティションでサポートできるユーザー数はR4.6.3では2,700ユーザー(シンプルメールユーザー)だったのが、R5になって10,500ユーザー(シンプルメールユーザー)に増えた、というテスト結果もあるそうです。
UNIXやNTの場合では、容量の大きなサーバーの場合、パーティションサーバー機能を使用しないと効率よくシステムが使用できないケースがあります。
AS/400ではOSがハードウェアを仮想化して効率よくシステムを使いきれるようにしてくれるので、パーティションサーバーを利用しないテはないでしょう。

パーティションサーバー同士のクラスタリング
Dominoはソフトウェア的にサーバーがコケてしまうことがあります。つまり、関連したハードウェア障害がない場合でもDominoサーバーが落ちてしまっていることがあります。
AS/400はOSがコケて反応が気が付いたらなくなってた、なんてことはまずありませんし、ハードウェア障害もあまりありません。
Domino自体のサーバー障害を避けるために、同一AS/400上でパーティションサーバーをクラスタリングするケースもあります。
また、クラスタリングはサーバーの負荷分散(ロードバランシング)のためにも使用できます。
いずれの場合でも、AS/400のDominoサーバーではパーティションサーバー同士の通信で*LOOPBACKアドレスが使用できます。
ローカルアドレス(127.0.0.1)を使用してサーバー同士が通信できますので、よりCPUの負荷が軽減でき、より高速にクラスタリングを行えることが予想されます。
V4R4以降のOS/400上で稼動させていれば、自動的に*LOOPBACKアドレスを検出するため、特別な設定は必要ありません。

NSF_Buffer_Pool_Size
NSFバッファープールというものにサーバー上でキャッシュされた情報が格納されています。
このNSFバッファープールのサイズを変更することによって、ディスクへの入出力バッファーのサイズをコントロールすることができます。
この値はnotes.iniの中の「NSF_Buffer_Pool_Size」「NSF_Buffer_Pool_Size_MB」のどちらかの指定によって決定されます。
「NSF_Buffer_Pool_Size」の場合は”300000000”、「NSF_Buffer_Pool_Size_MB」の場合は”300”というのがサイズに300MBを指定する場合の指定のしかたになります。
ただし、AS/400の場合現在はこの300MBという値が最大の値になります。
パーティションサーバーで複数のサーバーをひとつのAS/400で稼動させる場合は(あとで述べますが)もっと小さい値を指定することになります。

(a) ドミノサーバーがAS/400上ただひとつの場合
まず、ドミノサーバーが稼動するプールの値の25%か300MBのどちらか小さいほうが上限になります。
(たとえば、プールサイズが1200MB以上にできるのであればプールサイズを変更するのも併用可ですが...)
プールサイズが1350MBだった場合、その25%は337.5MBになります。ただし、この場合は300MBを超えていますので指定する値は300MBです。
プールサイズが700MBだった場合、その25%は175MBになりますので、そのまま175MBが指定の値になります。

(b) ドミノサーバーがAS/400上でいくつかのパーティションサーバーの場合
ひとつのAS/400上でパーティションサーバーが4つ稼動している場合を想定してみましょう。
こういう場合は逆に割り当てられたメモリープールサイズの75%を稼動しているパーティションサーバーで分け合う、という考え方になります。

プールサイズが700MBであった場合、その75%は525MBになります。これをパーティションサーバーの数(4)で割ります。
指定の値は131MBになります。
プールサイズが15000MBの場合、同じ計算をすると各サーバーの値が2812MBになってしまいますので、
上限が300MBである、というルールがここで適用されて指定の値は300MBになります。

実際にこのバッファーのサイズがどう使用されているかは sh stat database コマンドをコンソールから打ち込んでみるとわかります。
結果の中から以下の3つの値に注目してください。

それぞれ上から、現在の値、サーバーが必要とした値、バッファーから読み出しがヒットした割合、を表します。
Database.Database.BufferPool.Peak.Megabytesの値がDatabase.Database.BufferPool.Maximum.Megabytesの95%以下であればインデックスはバッファーから適切に読み出されています。
逆に95%を超えていればDatabase.Database.BufferPool.Maximum.Megabytesの値を増やす必要があるでしょう。

ドミノ関係のリンク

[Top Pageに戻る]

Ads by TOK2