2.6.1 ログ

ユーザアプリケーションでは、Novell Auditによるログと、オープンソースのApache log4jフレームワークによるログが可能です。デフォルトではNovell Auditによるログは無効になっています。これに対し、log4jによるファイルとコンソールのログはデフォルトで有効になっています。

log4jの環境設定は、次のファイルに保存されています:

jboss-log4j.xmlファイルの下部にある、次のエントリを探してください。

<root>
    <priority value="INFO" /> 
      <appender-ref ref="CONSOLE" /> 
      <appender-ref ref="FILE" /> 
  </root>

rootに値を割り当てると、レベルが明示的に割り当てられていないログアペンダはすべてrootレベル(この場合はINFO)を継承します。たとえば、デフォルトではFILEアペンダにはしきい値レベルが割り当てられていないため、rootのしきい値レベルを引き継ぎます。

log4jで使用されるログレベルはDEBUG、INFO、WARN、ERROR、およびFATALで、これはorg.apache.log4j.Levelクラスで定義されています。これらの設定を適切に使用しなかった場合、パフォー\'83\'7dンスの面で問題が発生する可\'94\'5c性があります。

経験則から言うと、INFOやDEBUGは特定の問題をデバッグするときだけ使用してください。

ルートに含まれるアペンダに特定のしきい値レベルが設定されていない場合、デバッグを行うとき以外はしきい値をERROR、WARN、またはFATALに設定する必要があります。

ログレベルが高いときのパフォーマンスは、メッセージの冗長性とはほとんど関係なく、log4jではコンソールとファイルのログが同時書き込みに関与しているという単純な事実に影響されます。AsyncAppenderクラスを使用できますが、このクラスを使用してもパフォーマンスの向上が保証されるわけではありません。この問題(Apache log4jの周知の問題で、Identity Managerの問題ではありません)については、http://logging.apache.org/log4j/docs/api-1.2.8/org/apache/log4j/performance/Logging.htmlを参照してください。

ユーザアプリケーションのログ設定ファイルのデフォルトのレベルであるINFO(前述)は、多くの環境で問題になりませんが、パフォーマンスが重要な環境では先ほどのjboss-log4j.xmlのエントリを次のように変更する必要があります。

<root>
      <priority value="ERROR"/>
      <appender-ref ref="FILE"/>
</root>

つまり、CONSOLEを削除し、ログレベルをERRORに設定します。完全にテストおよびデバッグされた運用環境では、INFOレベルでのログは必要ありません。また、CONSOLEのログを有効にしておく必要もありません。これらのログを無効にするとパフォー\'83\'7dンスが大きく向上します。

log4jの詳細については、http://logging.apache.org/log4j/docsにある資料を参照してください。

Identity ManagerでNovell Auditを使用する際の詳細については、『Novell Identity Manager:管理ガイド』を参照してください。

2.6.2 識別ボールト

利用頻度の高いディレクトリサーバ環境では、LDAPクエリがボトルネックになる可能性があります。Novell eDirectory (Identity Managerのアイデンティティボールトのベース)は、オブジェクトが多数でも高いレベルのパフォーマンスを維持するために、頻繁に要求される情報を記録し、インデックスに保存します。インデックス化された属性を持つオブジェクトに対して複雑なクエリを実行すると、クエリは高速に返されます。

eDirectoryは最初から次の属性がインデックス化されています。

Aliased Object Name
cn 
dc 
Equivalent to Me
extensionInfo
Given Name 
GUID 
ldapAttributeList 
ldapClassList
Member
NLS: Common Certificate
Obituary
Reference
Revision
Surname 
uniqueID 
uniqueID_SS 

Identity Managerをインストールすると、デフォルトのディレクトリスキーマが、ユーザアプリケーションに関する新しいオブジェクトクラスタイプと新しい属性で拡張されます。デフォルトでは、ユーザアプリケーション固有の属性はインデックス化されません。パフォーマンスを向上させるため、特に5,000以上のオブジェクトがユーザコンテナに含まれる場合には、こうした属性の一部(また必要に応じて従来のLDAP属性のいくつか)をインデックス化できます。

一般的には、定期的にクエリされる属性のみをインデックス化しますが、運用環境によりそのような属性は異なる可能性があります。どの属性が頻繁に使用されるかを見極める唯一の方法は、ランタイム時に述語統計を収集することですただし、収集プロセス自体がパフォーマンスを低下させてしまいます。

述語統計の収集プロセスの詳細については、『eDirectory管理ガイド』を参照してください。このガイドはインデックス化についても詳しく解説しています。一般的には、次の作業が必要です。

インデックス化する属性がわかっている場合は、ConsoleOneを使用する必要はありません。インデックスを作成し管理するには、iManagerで［eDirectoryの保守］>［インデックス］の順にクリックします。たとえば、組織図のユーザがisManager属性に基づいて検索することがわかっている場合は、その属性をインデックス化し、パフォーマンスが向上するかどうかを確かめることができます。

属性のインデックス化とパフォーマンスの詳細については、Peter KuoとJim Henderson共著の『Novell’s Guide to Troubleshooting eDirectory』(QUE Books, ISBN 0-7897-3146-0)の「Tuning eDirectory」を参照してください。

また、『eDirectory管理ガイド』の、パフォーマンスのチューニングに関する項目も参照してください。

2.6.3 JVM

Java仮想マシンに割り当てられるヒープメモリの量はパフォーマンスに影響することがあります。最小メモリ値や最大メモリ値の設定値が低すぎたり高すぎたりすると(「高すぎる」とはコンピュータの物理メモリより多いことを意味します)、ページファイルのスワッピングが過剰に発生する可能性があります。

JBossサーバの場合、テキストエディタを使って[IDM]/jboss/bin/にあるrun.confまたはrun.batファイル(前者はLinuxの場合、後者はWindowsの場合)を編集して、最大JVM^*サイズを設定できます。「-Xmx」を128mから512mまたはそれ以上に増やします。ご使用の環境に最適な設定が見つかるまで、調整を繰り返さなければならない場合があります。

2.6.4 セッションタイムアウト値

セッションタイムアウト(ユーザがWebブラウザのページを表示したままにしてから、サーバによってセッションタイムアウトの警告ダイアログが表示されるまでの時間)は、IDM.warアーカイブのweb.xmlファイルで変更できます。この値は、アプリケーションが実行されるサーバおよび使用環境に合わせて調整する必要があります。一般にセッションタイムアウト値は、実用上問題のない範囲でできるだけ小さくする必要があります。5分間のセッションタイムアウトを指定すれば、タイムアウト値を10分間に設定した場合と比べて倍の早さで、未使用のリソースが解放されます。こうすることによってWebアプリケーションのパフォーマンスとスケーラビリティが向上します。

セッションタイムアウトの値を調整する場合は、次の事項に留意してください。

アプリケーションサーバによっては、セッションタイムアウト値を指定する方法が用意されている場合があります。代わりに、IDM.warアーカイブを開いてweb.xmlファイルを探し、ファイルの次の部分を編集してセッションタイムアウト値を調整することもできます(数値の20はデフォルト値で、20分を表します)。

<session-config>
    <session-timeout>20</session-timeout> 
</session-config>

次に、ファイルとアーカイブを保存して、サーバを再起動します。

2.6.5 JBossのチューニング

デフォルトでは、JBoss配備スキャナは5秒間隔で実行されます。運用環境では、一般にJBoss配備スキャナは不要であり、パフォーマンスに悪影響を及ぼすおそれがあります。配備スキャナの実行頻度を減らすか、または配備スキャナを完全に停止させることを検討してください。配備スキャナの環境設定については、『ConfiguringTheDeploymentScannerInConfjbossSystem』を参照してください。

運用環境におけるJBossチューニングの詳細は、『JBossASTuningSliming』を参照してください。

2.6.6 ユーザアプリケーションのアイデンティティボールトへの接続へのセキュアソケットの使用

デフォルトでは、ユーザアプリケーションサーバとアイデンティティボールト間の通信には、セキュアソケットが使用されます。ただし、環境によっては、すべての通信を保護する必要がない場合もあります。たとえば、ユーザアプリケーションサーバとアイデンティティボールトサーバが独立したネットワーク内にあり、外部から利用できるポートがHTTPポートだけの場合は、これらのサーバ間の通信の一部を保護しない通信にできることがあります。アプリケーションの一部の機能では、セキュアな接続を使用しないように設定されていても、常にセキュアな接続を使用するものがあります(例:パスワードの変更など)。セキュアな接続を無効にすると(特にユーザ接続)、パフォーマンスとスケーラビリティを大幅に向上することができます。同時に多数のユーザがログインするような環境で、ネットワーク設定でユーザアプリケーションサーバとアイデンティティボールトサーバ間の通信が保護されている場合、ユーザ接続の保護を無効にすると、処理できる同時ログイン数が大幅に増加します。この選択肢は、環境内のスケーラビリティ／パフォーマンスに関する問題の原因が明白で、新たなeDirectoryサーバを追加することができない場合にのみ実行することをお勧めします。

また、管理者接続の保護を無効にすることもできます。このようなの接続は、ユーザ資格情報を必要としない、アイデンティティボールトサーバへの一般的なクエリに対して使用します。これらの接続は、ラウンドロビン方式でプールされ、使用されます。セキュアな接続経由のバインドは、アプリケーションのスタートアップ時に1回のみ行われます(または、後ほど接続が応答不能になった場合にも)。そのため、ユーザ接続に関するスケーラビリティの問題にはなりません。ただし、終端間で行われる暗号化と複号化にかかる時間がオーバヘッドになってしまいます。特にパフォーマンスを向上する必要がない限り、デフォルトの設定を使用することをお勧めします。

管理者接続とユーザ接続の保護を解除する場合は、ユーザアプリケーションとiManagerの両方で設定を変更する必要があります。管理者接続とユーザ接続の保護を解除する方法については、次の手順を参照してください。