Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Portal Server 6 2005Q4 配備計画ガイド 

第 6 章
本稼働環境

この章では、Sun Java System Portal Server Secure Remote Access 製品を含む Sun JavaTM System Portal Server ソフトウェアを監視およびチューニングする方法について説明します。

この章で説明する内容は次のとおりです。


本稼働環境への移行

本稼働環境への移行は、ポータルをよくテストしてから、試験的な配備で稼働させて設計をテストおよび改良したあとに行います。

監視とチューニング

ポータル配備の監視とチューニングは、常に定期的に実行される処理であり、この処理で障害やパフォーマンスに関するその他の問題を検出します。

ポータルを監視およびチューニングする場合、次の点を注意してください。

ポータルの文書化

ポータルの機能の包括的な文書は、システムをサポートしやすくする重要な手段です。サポート可能なソリューションを作成するために文書化する必要がある領域を次に示します。

運用書には、障害追跡の方法や配備のライフサイクルが要約されています。プロジェクトのトレーニングおよび知識の移譲段階でこのブックを利用できるようにします。


ヒント

通常、配備プロジェクトでは時間も費用も足りなくなるため、配備プロジェクトの終わりまで待たずに文書化を開始してください。ポータルの文書化は、配備過程全体を通して行う必要がある活動です。



Portal Server の監視

ここでは、ポータルのパフォーマンスに影響する可変要素、また実行可能なポータルの監視について説明します。監視対象には次のものが含まれます。

次々と新しくなる技術によって Portal Server サービスの詳細な監視を実行できるようになりますが、ここではポータル配備の全体的なパフォーマンスを決定する基本的かつ広範なハードウェアおよびソフトウェアに焦点を合わせます。

特に、ポータルのパフォーマンスは、一定の期間にわたるスループットおよび応答時間の性能によって決まります。できるだけ早くパフォーマンスの基準の分析を行う必要があります。パフォーマンスの基準の分析では、ポータルが公開されたパフォーマンスの数値に実際に適合していることを確認します。パフォーマンスの基準の設定は、本稼働ポータルのパフォーマンスに重大な影響を及ぼすことがあるインフラストラクチャーの問題を理解するのに役立ちます。

それでもやはり、ポータルを継続して適切に稼働させるには、広範な問題を考慮する必要があります。次に、ポータルのパフォーマンスにおける可変要素の観点から問題について説明し、ポータルの効率を判断する際の指針を示します。


それらの規則は、パフォーマンス、スケーラビリティー、および負荷テストにも適用されます。


メモリーの消費とガベージコレクション

このセクションを読む前に、Java 仮想マシン、バージョン 1.4.2 でのガベージコレクションのチューニングについての次のドキュメントを読んでください。

http://java.sun.com/docs/hotspot/gc1.4.2/index.html

Portal Server では、可能なかぎり最高のスループットを実現するために、かなりの量のメモリーが必要になります。初期化時に、最大アドレス領域が実質的に確保されますが、必要でないかぎり物理メモリーは割り当てられません。オブジェクトメモリー用に確保したアドレス領域全体は新世代と旧世代に分割できます。

ほとんどのアプリケーションでは新世代用にヒープ全体のかなりの割合を使用するように勧めていますが、Portal Server では、Portal Server が使用するメモリーの大半は長期的に使用されるので、新世代用の領域の 1/8 のみを使用するのが適切です。メモリーを旧世代にコピーするのが早いほど、ガベージコレクション (Garbage Collection、GC) のパフォーマンスは向上します。

ヒープのサイズが大きい場合でも、ポータルインスタンスが中程度の負荷で数日間実行されたあとは、GC の遅れによりほとんどのヒープが使用されたように見えます。GC は、常駐セットサイズ (Resident Set Size、RSS) がヒープ領域全体の約 85 パーセントに達するまで完全なガベージコレクションを実行します。85 パーセントに達すると、ガベージコレクションがパフォーマンスにある程度の影響を及ぼすことがあります。

たとえば、900MHz UltraSPARCIIITM では、2G バイトのヒープに対するフル GC には 10 秒を超えることがあります。その間、システムは Web 要求に応答できません。信頼性のテスト時に、フル GC は応答時間の急激な上昇としてはっきり目に見えるようになります。フル GC のパフォーマンスに対する影響と頻度を理解する必要があります。本稼働時には、ほとんどの場合フル GC が認識されることはありませんが、システムのパフォーマンスを測定する監視スクリプトはフル GC が発生する可能性があることを考慮する必要があります。

フル GC の頻度を測定するのが、システムにメモリーリークが発生していることを確認する唯一の手段である場合があります。(基準システムの) 予測頻度を示す分析を行い、その結果を観測したフル GC の頻度と比較します。GC の頻度を記録するには、vebose:gc JVMTM パラメータを使用します。

CPU の使用率

構築モジュール概念 (第 5 章「ポータルの設計」で説明) を使用して配備する場合、Portal Server のアーキテクチャーは高性能でスケーラブルな CPU アーキテクチャーになりますが、このアーキテクチャーでは高負荷時にパフォーマンスが徐々に低下します。

ただし、本稼働サイトを監視する場合は、CPU の使用率を一定の期間追跡します。通常、負荷は急に上昇し、上昇が発生する前に対策を講じるためには利用可能な機能の慎重な評価が必要です。

ほとんどの組織はポータルサイトが「スティッキー」な性質を持つことを認識しています。つまり、ユーザーのコミュニティーのサイズが固定されていても、ユーザーがそのサイトに慣れてくると、サイトの使用率が時間の経過とともに増加することを意味します。また、ユーザーのコミュニティーのサイズが時間の経過とともに増加する場合も、成功しているポータルサイトでは短期間に CPU 要件が高まる場合があります。

ポータルサーバーの CPU の使用率を監視する場合、負荷のピーク時における平均ページ待ち時間を確認し、それが平均の待ち時間とどれだけ異なるかを確認します。

ピーク時の負荷は、短期間ではありますが、平均の負荷の 4 〜 8 倍の負荷であると予測します。

Access Manager のキャッシュとセッション

ポータルシステムのパフォーマンスは、Access Manager キャッシュのキャッシュヒット率の影響をかなり受けます。このキャッシュは高度にチューニング可能ですが、このキャッシュが使用するメモリーとヒープの残りの利用できるメモリーのどちらかを選択する必要があります。

amSSO および amSDKStats ログを有効にして、サーバー上のアクティブなセッションの数と Directory Server キャッシュの効率を監視できます。それらのログは、デフォルトで /var/opt/SUNWam/debug ディレクトリにあります。ロギング間隔を設定するには、com.iplanet.am.stats.interval パラメータを使用します。5 秒未満の値を使用しないでください。30 〜 60 秒の値を使用すると、パフォーマンスに影響を与えずに良い結果が得られます。

com.iplanet.services.stats.directory パラメータを使用して、ファイルまたはコンソールのどちらかのログの場所を指定し、またログを無効にします。変更を有効にするには、サーバーを再起動する必要があります。ログは、システムがアクティビティーを検出するまで、作成されません。


複数の Web コンテナインスタンスが、同じファイルにログを書き込みます。


amSDKStats ファイルに表示されるキャッシュヒット率は、サーバーが起動されてからの内部の値と全体的な値の両方を示します。ユーザーがログインすると、ユーザーのセッション情報はキャッシュに無期限に、またはキャッシュが一杯になるまで残ります。キャッシュが一杯になると、もっとも古いエントリが先に削除されます。サーバーがユーザーのエントリを削除する必要がない場合は、数日後にログインするときに、ユーザーの情報がキャッシュから取得されることがあります。ヒット率が高いと、パフォーマンスがかなり向上します。最低 80 パーセントのヒット率を目標にします。この値は良い目標ですが、可能であればそれよりも高いヒット率を目標にすることが望まれます。

スレッドの使用

Web コンテナツールを使用して、要求を処理するために使用するスレッドの数を監視します。一般に、実際に使用されるスレッドの数は多くの場合予測した数よりも少なく、特に CPU の使用率が通常 100 パーセントよりもかなり低い本稼働サイトではそのようになります。

ポータルの使用情報

Portal Server には、ポータルのユーザーがポータルの使用情報を監視するための組込みの報告メカニズムがありません。これには、アクセスされるチャネル、チャネルがアクセスされた期間、またポータルのユーザーの行動様式を作成する能力が含まれます。ただし、Portal Server Desktop の要求を代行受信し、SSO トークンを抽出し、ユーザークセス情報をログに保存してから、ユーザーを目的の URL にリダイレクトする Java サーブレットを作成することはできます。そのような構成は、Access Mangaer スキーマへのカスタム属性の拡張に基づきます。



前へ      目次      索引      次へ     


Part No: 819-4618.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.