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

Iris Today Archives

ドミノパフォーマンス・チューニングの基礎

by Lou Bradbard
レベル：ビギナー
対　象：Domino R5
原文の掲載：2000年9月1日

Iris Today Archivesの原文

インデックス

	パフォーマンス・チューニングとは？
	パフォーマンスのチューニングを行うには
	ドミノのパフォーマンス・テスト用ツール
	ベンチマーク・サーバーの役割を理解する
	安定した状態とは？
	システム・モニター・ツールで、パフォーマンスに関するデータを集める
	ドミノ・パフォーマンス・テストツールは、どのように働くか
	テスト結果を分析する：最もよく見られる問題とは
	以上のことを理解したら・・・

あなたがドミノ管理者なら、サーバーがより効率よく稼動して、パフォーマンスが向上すればいいと思うでしょう。システムへの要求は常に変化したり増えていくものですが、サーバーを最大限に活用するということは、常に管理者の重要な役割であると言えます。

この記事では、ノーツ/ドミノのパフォーマンス分析の概念と、ツールの基礎を紹介します。そして最後に、より高度な内容の記事や、パフォーマンスに関連したオンライン・リソースへのリンクを紹介しています。この記事は、コンピューターのシステムやドミノサーバーの管理についての一般的な知識があることを前提としています。

パフォーマンス・チューニングとは？

パフォーマンス・チューニングの目的とは、大まかに「ハードウェアを最大限に活用する」ということです。しかし、どうすればドミノサーバーのリソースを最大限に活用しているかどうかが分かるのでしょうか。

具体的には、オペレーティング・システムやアプリケーションのレベルで効率よく動いていない部分を突き止め、メモリ、CPU、ディスク・ドライブ、そしてネットワークといった主要なコンポーネントが全て最適なパフォーマンスを示すように、システムのハードウェアやソフトウェアを分析、調整します。例えば次の通りです。

プロセッサーは、インデクサーのスピード、レプリケーターのスピード、データベースが一度に可能なトランザクション数、そして同時に並行して起動可能なアドインの数に影響します。
ディスク・アクセス率とその設定は、データベースとビューを開いたり、コレクション(ビュー・インデックス)を開くときの速さに影響します。
メモリーは、同時に確立可能なノーツ・クライアントの接続 (セッション) の数、キャッシュのサイズ、そしてサーバー・アドインのタスクのパフォーマンスに影響します (ディスクに対する呼び出しが減るため)。

上に戻る

パフォーマンスのチューニングを行うには

まずは、トップダウン式の方法でパフォーマンス・チューニングを行うのがいいでしょう。ドミノサーバーのパフォーマンス・チューニングを始める前に、ネットワーク・コンポーネントが正常に稼動していることを確認する必要があります。ネットワークの混雑には、さまざまなコンポーネントが影響しており、簡単に割り出すことはできません。ルーターやゲートウェー、ファイアウォール、そしてネットワークの衝突といったものが、パフォーマンスを低下させる原因になりえます。また、ネットワーク・トラフィックの問題を見つけるには、スニッファーを使う必要があるかもしれません。

それが終わったら、ドミノ・システムがネットワークを効率よく利用しているかを確認します。Network Utilization、Total Bytes sent/second、そしてWindows では、 Processor オブジェクトの Percent DPC (Deferred Process Calls) Time と DPCs Queued/Second をチェックします。これによって、プロセッサー時間が、どのくらいネットワークに使われているか、また DPC キューが増加しているかどうかが分かります。

ネットワークのチューニングが終わったら、実際にドミノサーバーのパフォーマンスを見てみましょう。ドミノサーバーのパフォーマンス・チューニングがどれだけ複雑なものになるかは、ドミノ・ネットワークの複雑さと大きさによって変わってきます。もしディスク・ドライブを1つ、CPU を1つしか持たないドミノサーバーが1台のみ、という場合には、パフォーマンス・チューニングのオプションはとてもシンプルで基本的なものになります。

最大限のパフォーマンスを引き出すようにアプリケーション、フォーム、ビュー、そしてページを設計する。
リダイレクション URL を使用する。
サブフォームや Java スクリプトなどの、できるだけ動作の速い手法をとる。
必要のないドミノサーバー・タスクを切る。
LotusScript と Java コードを最適化する。

Lotus White Paper の「Maximizing Application and Server Performance in Domino」で、ここに挙げたパフォーマンス調整の例を参照してください。

複数の CPU やハード・ドライブを持つドミノサーバーのパフォーマンス・チューニングのオプションは、より複雑になります。上に挙げた方法を用いることもできますが、この他にも、ドミノの行う仕事が、すべての物理ディスク・ドライブの間で効率よく振り分けられて、バランスが取れているようにする必要があります。ドミノサーバーはディスク集中型なので、ディスク・ドライブの設定や、RAID と呼ばれるハード・ドライブの配列を用いることで、サーバーのパフォーマンスを大幅に向上することができます。

とても複雑なシステムでドミノサーバーのパフォーマンスを向上させるための鍵は、一言で言えば次のようにまとめられるでしょう。

「ハードディスク間、CPU 間で仕事を分担させる」

これらのシステムでパフォーマンス・チューニングを行うには、ディスク・ドライブをパーティションに分けたり、システムやプログラム、そしてデータ・ディレクトリーをうまく配列して、仕事をシステム全体に均一に行わせるようにします (Iris Today の記事「Optimizing server performance: I/O subsystems」を参照してください)。このようなシステムでは、最適なパフォーマンスを得るために、ハードウェアやソフトウェアを実験的に設定したり、調整するといったことが必要になる場合もあります。パフォーマンス・テストツールを使えば、RAID 配列のストライプ・サイズや、ハード・ディスクのファイル・フォーマットといったさまざまなシステム設定を実験して、どの組み合わせでよりよいパフォーマンスを得られるかを調べることができます。

上に戻る

ドミノのパフォーマンス・テスト用ツール

パフォーマンスが効率悪くても、それはサーバーに大きな負荷がかかったときだけに初めて分かります。サーバー・パフォーマンス・ツールを使えば、メール・メッセージやデータベースといった負荷のシミュレーションを行うことができます。Server.Load と NotesBench パフォーマンス・ツールはドミノ・ベースで開発され、ノーツ・クライアント・システム上で稼動します。そして、ワークロード・スクリプトにより、サーバーに対してユーザーが行うであろう行動をシミュレーションします。

NotesBench と Server.Load は、同じサーバー・パフォーマンスのテスト・エンジンを使って作られていて、ここ数年でインターネット・メール、掲示板データベース、そしてカレンダーやスケジュール機能などが加えられ、拡張されてきました。Server.Load は、NotesBench の、よりシンプルでフレキシブルなバージョンとして設計されました。

Server.Load
Server.Load は、GUI (Graphical user interface) を使ってタスクをコントロールしており、小・中規模なテストに向いています。Server.Load は、ドミノサーバーの CD ROM に入っています。

150 のパフォーマンス評価基準の値を、テスト対象のシステムから集めます。
ビルトインや、カスタマイズしたワークロード・スクリプトを起動します。

NotesBench
NotesBench は、コマンドライン・ベースの強力なツールで、NotesBench Consortium の会員や、パフォーマンス分析についてのトレーニングを受けた人のみ使用することができます。Server.Load よりも、ドミノ・システムに関する詳しい知識が必要になり、セットアップにも、より時間がかかります。小規模のテストには向いていないと言えるでしょう。NotesBench とは次のようなものです。

システムの毎秒のユーザーの数と、そのレスポンス時間を算出します。
スタンダードなビルトインのワークロードを起動します。
NOTES.INI ファイルから、ワークロードの制御情報をすべて取り出します。
複数のテスト・ドライバーを、親/子の関係にしてシンクロナイズさせます。

どちらのツールが必要？
NotesBench と Server.Load は、サーバー上での効率よく動いていない部分を見つけるワークロードを起動するために使われますが、ドミノのパフォーマンス分析を手軽に始めるには、Server.Load がいいでしょう。すでにプログラムや必要な文書がドミノサーバーの CD に揃っているのですから。

大きな規模でのドミノの配備を考えているなら、NotesBench Consortium の会員になってサービスを受けることをお薦めします。NotesBench の設定や稼動に関する経験が豊富で、あなたの要求に合うように NotesBench をカスタマイズしてそのプラットフォームで稼動させる、といったことができます。

NotesBench Consortium

NotesMark は、ドミノのさまざまなハードウェア・プラットフォーム上における拡張性を比較する基準で、馬力にたとえられています。NotesBench を使って NoteMark の値を得るには、システムの不具合を Server.Load を使って突き止める場合よりも、多くのセットアップと、より厳密なガイドラインが必要になります。

上に戻る

ベンチマーク・サーバーの役割を理解する

Server.Load や NotesBench、またはサード・パーティーのツールを使ってテストを行うために設定されたドミノサーバーを、ベンチマーク・サーバーと呼びます。これは、テストするシステムにかける重い負荷を格納するための隔離されたドメインに設置されます。

パフォーマンス・テスト・ツールが持つセットアップ・スクリプトとエージェントによって、何千というメール・ファイルが、関係したユーザー文書とともに作成されます。これにより、高い負荷がかかった場合にシステムがどのような反応を示すかが分かるほか、その限界がどのくらいなのかを理解することができます。また、プロダクション・サーバーに発生する問題を、オーバーロードする前に未然に防ぐことが可能になります。

テストを行って得られた情報を分析した後は、ベンチマーク・サーバーはプロダクション・サーバーに戻したり、あるいは他の目的用のテスト・サーバーに変えることができます。

上に戻る

安定した状態とは？

テストを行っているシステムが安定した点に達し、メモリーや CPU、ディスク I/O が増加せず、限界にも達しないで一定時間テストのタスクを実行することができたなら、安定した状態と言えます。

下のグラフは、Server.Load のタスクを一晩起動したサーバーが、安定した状態に達した様子を表しています。上のグラフは Windows NT システムの、下のグラフは RS/6000 システムのものです。主要なシステム・コンポーネントの活動が、始めに上昇した後、一定の値に落ちついていることに注目してください。システム・コンポーネントの活動がテスト中、常に上昇しつづけたなら、それはシステムがまだ安定した状態に達していないということです。

Windows NT steady state graph

上に戻る

システム・モニター・ツールで、パフォーマンスに関するデータを集める

ドミノが稼動するオペレーション・システムは、システム内で起こっていることすべてを監視しています。モニターと呼ばれるプログラムが必要なデータを統計カウンターから集め、それをテキスト・ファイルに出力したり、グラフとして表示します。これらのデータは、どのコンポーネントが、限界に達しつつある、または達しているかを示し、システムに加えた調整が、パフォーマンスにどのような影響を与えているのかを測定することができます。マイクロソフト・ベースのプラットフォームは、Perfmon ユーティリティーによってデータを集め、UNIX プラットフォームでは、IOSTAT や VMSTAT といったコマンドライン・ベースのユーティリティが使われます。ドミノサーバーが稼動するこの2つ以外のプラットフォームにも、他のツールや方法があります。

上に戻る

ドミノ・パフォーマンス・テスト・ツールは、どのように働くか

次の図は、テスト・ドライバーとテスト対象のシステムの間を、データが流れる様子を表しています。青の矢印はユーザーがサーバーに対して出すであろう要求をシミュレーションしたもの、オレンジの矢印はサーバーから取り出された統計データを表し、これは Server.Load メトリクス・ファイルに出力されていきます。Server.Load は、Script Output Monitor ウインドウからテキストを取り出し、結果ファイルに出力します。これは、タイムアウトや、エラー・メッセージを調べるのに使用できます。

How data flows during testing

パフォーマンス・テストを行い、モニター・ツールでデータを集める方法は次の通りです。

Server.Load を、テスト・クライアントにインストールします。
メール・ファイルやテスト・ユーザーのユーザー文書を作成する特定のタスクや、エージェントを使い、パフォーマンス・テストの設定をします。
パフォーマンス・テストのワークロードを実行して、安定した状態に達するまで、テスト対象のシステムに重いワークロードをかけます。
Statrep.nsf データベースで、収集されたサーバー統計を参照、グラフ化します。このデータは、Windows サーバーのプラットフォームでは Perfmon、Windows や Solaris プラットフォームではPlatform Stats から集められます。
テスト・ドライバー・クライアントのメトリクス・ファイルから、レスポンス時間のデータを収集します。
次のセクションで、集めたデータをどのように分析するかを紹介します。

上に戻る

テスト結果を分析する：最もよく見られる問題とは

効率の悪いデータを探すには、システムの中心となるコンポーネントから見ていくのがよいと言えます。渋滞時には、交通の流れが特定の交差点で滞るのと同様に、重い負荷がかかった時には、特定の部分でデータが滞っています。パフォーマンス・テストを行うことによって、Eメールの「渋滞」を作り、システムの弱い部分を詰まらせます。そして、オペレーティング・システムのパフォーマンス統計を、道路にあるカメラのように使い、システムの中を流れるデータを監視します。

ここで重要なのは、全てのシステムはキューに関係していて、監視しなければならないのはキューの長さであるということです。CPU の場合は、システム・プロセッサーのキューの長さで、ディスクの場合は、平均のキューの長さ、というようにです。滞っている部分は、論理的に順番に見つけることができます。

サーバーの CPU
効率の悪い部分を探す上で始めに見るのが、サーバーの CPU です。ディスク・スペースや、RAM が無限にあったとしても、CPU を通るデータの量には限界があります。使用率が 100 パーセントに近いときには、CPU がシステムに制限を加えている可能性があります。しかし、システム・プロセッサーのキューの長さの値が2 (Windows NT の場合) を一定時間超えなければ、CPU の使用率が 100 パーセントであっても、滞る原因にはなりません。 CPU の使用率が 100 パーセントでも構いませんが、その CPU を 100 パーセントの状態で1分以上経過させるべきではない、ということに注意してください。

サーバーにはある程度の余裕を持たせるのが理想的で、プロセッサー時間が 80 パーセントを超えた場合には、サーバーに新しいユーザーを加えたり、タスクを加えるべきではありません。

利用可能なメモリー
次に、利用可能なメモリーをチェックします。ロードする際に、利用可能な RAM が一度でも０に近づく場合は、システムが RAM によって制限されてしまっていると言えます。物理 RAM をチェックして、メモリーに何バイト使用されているかを調べてください。

ディスクのインプットとアウトプット
次に、ディスクのインプットとアウトプットを調べますが、ここが面白いところです。大量の RAM と CPU のサイクルが利用可能なのに、データベースを開くのにとても時間がかかるという場合には、ハードディスクのインプットとアウトプットをチェックします。これには、Windows NT ではドライブキューの長さと、毎秒の平均ディスク読み取り/書き込み時間、そしてPercent Disk Time、Percent Disk Bytes 転送率をチェックします。また、UNIX では、Logical Disk Percent Time と Logical Disk Service Time を調べます。

上に戻る

以上のことを理解したら・・・

ここに、上で紹介したツールを使ってドミノサーバーで効率の悪い部分を発見したり、それを応用してパフォーマンスをチューニングをしたり、許容量を設定する、ということに関連した記事やリソースの一覧を挙げます。

パフォーマンスに関する基本的な記事
Top 10 ways to improve your Domino server performance ドミノ・パフォーマンスについての記事をもう1つ読むのなら、絶対これです。上手くポイントを要約してあります。

Command Performance と Command Performance 2 このインタビュー記事では、Iris ドミノ・パフォーマンス・チームや、その役割、そしてドミノのパフォーマンスの将来について紹介しています。

Optimizing server performance: Handling the curves like a pro この記事では、さまざまなシステム設定でいろいろなテスト・ワークロードを実行した場合の、ドミノのパフォーマンスを検証しています。６つのケースのテスト結果の評価を紹介しており、それぞれの設定がどのような結果を出したか、を見ることができます。

ドミノサーバーのパフォーマンスの最適化について
Optimizing server performance: Port encryption and Buffer Pool settings この記事では、必要なツールのほか、ネットワーク・データの暗号化や NSF_BUFFER_POOL_SIZE がサーバーのパフォーマンスに与える影響を、いくつかのケースでテストをした分析を通して紹介しています。

Optimizing server performance: HTTP Threads settings HTTPスレッドは、キャブレターの中の燃料のようなもので、多すぎても少なすぎてもパフォーマンスに影響を及ぼしてしまいます。ドミノ Web サーバーが、最適な状態で稼動するようにします。

Optimizing server performance: I/O subsystems トランザクション・ログや、複数のメール・ボックスやディスク・ドライブ・コントローラを使うことによって、パフォーマンスを向上させる方法を紹介しています。

Notes.net Exposed: Improving Web site performance 大容量の Web サイトとして実在する Notes.net のパフォーマンスを検証します。アップグレードやシステム設定によって、どのようにパフォーマンスを向上させてきたのかを紹介します。

Notes from Support: Does more memory really help? メモリーの使用が、ドミノサーバーのパフォーマンスに与える影響を紹介します。サーバーでメモリーが不足していると、ディスクの I/O が極度に高まり動きが遅くなってしまう、ということを見ていきます。

Optimizing server performance: Transaction logging この記事では、トランザクション・ログで得られるパフォーマンス上のメリットや、RAID ドライブ設定の詳細、そして R5Mail テスト・ワークロードの概要を紹介します。

セマフォパート1 | Optimizing server performance: Semaphores (Part 1) パート1のこの記事では、なぜセマフォ・タイムアウトが起きるのか、そしてその原因を解消する方法を紹介しています。

セマフォパート2 | Optimizing server performance: Semaphores (Part 2) パート1でのアドバイスに加え、その他のトラブル・シューティングに関するテクニックを、実際にあった話を基に紹介しています。

Maximizing Application and Server Performance in Domino この White Paper では、ドミノのパフォーマンスを最大限に発揮させるためにはどうすればいいかを、Web アプリケーションをアプリケーション開発という視点から見る、という形で説明するほか、サーバー管理という観点から見たサーバーの全体的なパフォーマンスについて紹介しています。

Performance Considerations for Domino Applications この IBM の Redbook は、アプリケーションのパフォーマンスという側面に焦点を置き、同時にサーバーのチューニングに関しての一般的なトピックにも触れています。

ドミノサーバーのクラスター・パフォーマンスの最適化に関連した記事
Optimizing server performance: Domino clusters (Part 1) まずドミノ・クラスターについての基本を、パフォーマンスに関連した側面に焦点を置いて説明し、次にドミノ R4.6 クラスターのパフォーマンス・テストについて紹介しています。

Optimizing server performance: Domino clusters (Part 2 )ドミノ R5 のクラスターのパフォーマンス・テストについて、より広く論じ、インターネット・クラスター・マネージャーや、クラスター・レプリケーションなどのデータも紹介しています。

著者について
ルー・ブラッドバードは、1995 年からアイリスに勤め、ドミノサーバーの品質保証テストや、プログラマビリティ・チームで活躍してきました。1999年の11月にパフォーマンス・チームに加わり、現在はチームで開発したさまざまなパフォーマンス・ツールのテストを手がけています。彼はこよなく Apple のマッキントッシュを愛しているそうです。

上に戻る