|
LiveCycle でパフォーマンスが低下している場合は、以下について確認してください。
同期に関する問題：多数のスレッドがコードの同じ部分で同時に待機している場合は、混雑した状態が解消してからスレッドダンプを取得します。
重要： スレッドダンプによって JVM が無効になることがあります。
外部リソースの処理が遅い：多数のスレッドが外部ソースから返されるメッセージを待機している場合は、スレッドダンプを取得して、データベースや LDAP サーバーなどのソースを待機しているスレッドを探します。
ガベージコレクションの処理が遅い：verbosegc によって圧縮が頻繁に実行されている場合は、オブジェクトのプールまたはキャッシュを導入してアプリケーションによって生成されるガベージの量を減らします。ログが verbosegc で長いガベージコレクションのサイクルを表示している場合、最大サイズを小さくします。
ユーザーの CPU 使用率が高い：CPU 稼働率が 75 ％以上の場合は、次のオプションを検討してください。
Web コンテナまたは ORB スレッドのプールサイズを小さくする。
データベースサーバーのデータベース接続の数を減らす。
CPU 使用率が一貫して高い場合は、処理リソースの追加を検討する。
CPU がデータベースサーバー上にある場合はデータソースの最大接続の設定を小さくする。
高いデータベースリポジトリサイズ：LiveCycle の一部の動作により、データストアリポジトリのサイズが大幅に大きくなる可能性があります。例えば、多数のアセットをパブリッシュするバッチプロセスを実行する場合、Correspondence Management Solution でこの問題が起こります。データストアガベージコレクタを使用し、リポジトリから一時データをすべて消去します。
データストアガベージコレクタを実行するには：
http://<hostname>:<port>/lc/system/console/jmx へ移動して、管理者の資格情報を使用してログインします。
com.adobe.granite (タイプ リポジトリ) を検索してクリックします。
runDataStoreGarbageCollection(java.lang.Boolean delete) を検索してクリックします。
java.lang.Boolean の削除を true に設定します。
「Invoke」をクリックして、ガベージコレクタを実行します。
多数のアセットを持つパッケージのインポート：多数のアセットを含んでいるパッケージをインポートするときに、次の問題が起こる。
Java Heap Space エラー
この問題を解決するには、Java Heap スペースを 4GB に高める必要があります。
Correpondence Management および CRX ユーザーインターフェイスがアクセス不能になる。
規模の大きなインポートプロセスはバッチ操作で実行することをお勧めします。
管理コンソールの使用中にパフォーマンスが低下する、またはトランザクションタイムアウト例外が発生する* 10 で追加*
管理コンソールを使用しているとき、多数のファイルを対象として複数の操作を実行すると、パフォーマンスが低下する場合やタイムアウト例外が発生する場合があります。
この問題を解決するには、お使いのアプリケーションサーバーのトランザクションタイムアウト値を大きくしてください。トランザクションタイムアウト値の設定方法については、アプリケーションサーバー製品のマニュアルを参照してください。
Pure IPv6 環境のアプリケーションサーバーでリモート呼び出しが失敗するLiveCycle サーバーが Pure IPv6 環境にデプロイされている場合は、LiveCycle サーバーでのサービスのリモート呼び出しが失敗する可能性があります。これは、クライアントで使用される Sun JDK に関する問題です。このエラーを回避するには、Pure IPv6 環境のアプリケーションサーバーに LiveCycle をデプロイするときに、クライアントで IBM JDK を使用します。
Oracle 上で Process Management のパフォーマンスが低下するOracle データベース用の Process Management スループットが時間の経過とともに低下することがあります。LiveCycle 開発チームでは、この問題の解決に役立つ SQL*Plus スクリプトをいくつか作成しました。これらのスクリプトを使用すると、ユーザー数が多い状況でのパフォーマンスが改善します。
アドビエンタープライズサポートにお問い合わせいただき、「Oracle 上で Process Management のパフォーマンスが低下する」（ドキュメント ID：cpsid_85089）というタイトルの TechNote に関連するスクリプトを入手してください。
LDAP を使用した Windows Server のパフォーマンスの向上検索のための接続では常に特定のドメインの同じ証明書が使用され、コンテキストと関連オブジェクトが明示的に閉じられるので、この接続に接続プールを使用すると、必要なポート数を 50 ％まで減らせる可能性があります。
接続プールを使用するための Windows Server の設定スタート／ファイル名を指定して実行を選択し、「名前」ボックスに regedit と入力して「OK」をクリックし、レジストリエディターを起動します。
次のレジストリキーに移動します。HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters
レジストリエディターの右側のウィンドウで、TcpTimedWaitDelay という値の名前を探します。値の名前が表示されない場合は、編集／新規／DWORD 値を選択して追加します。
「名前」ボックスに、TcpTimedWaitDelay と入力します。
挿入ポイントおよび「新しい値 #」がボックス内に表示されない場合は、右側のウィンドウ内を右クリックし、メニューから「名前の変更」を選択し、「名前」ボックスに TcpTimedWaitDelay と入力します。
MaxUserPort、MaxHashTableSize、MaxFreeTcbs の各値の名前に対して、手順 4 と 5 を繰り返します。
右側のウィンドウ内をダブルクリックし、TcpTimedWaitDelay 値を設定します。「表記」で「10 進」を選択し、「値のデータ」ボックスに 30 と入力します。
右側のウィンドウ内をダブルクリックし、MaxUserPort 値を設定します。「表記」で「10 進」を選択し、「値のデータ」ボックスに 65534 と入力します。
右側のウィンドウ内をダブルクリックし、MaxHashTableSize 値を設定します。「表記」で「10 進」を選択し、「値のデータ」ボックスに 65536 と入力します。
右側のウィンドウ内をダブルクリックし、MaxFreeTcbs 値を設定します。「表記」で「10 進」を選択し、「値のデータ」ボックスに 16000 と入力します。
重要： レジストリエディターまたは別の方法を使用してレジストリを誤って変更すると、重大な問題が発生する場合があります。問題が発生した場合は、オペレーティングシステムの再インストールが必要になる場合があります。レジストリの変更はユーザーの責任で行ってください。
非デフォルト JNDI URL の Scheduler サービス設定（クラスター化されていない環境のみ）
Scheduler サービスが正しく機能するには、いくつかの設定を追加する必要があります。
JBossJBoss で、JNDI URL がアプリケーションサーバーのデフォルトの JNDI URL（JBoss の場合は jnp://localhost:1099）と異なる場合、アプリケーションサーバーで管理される IDP_DS の JNDI URL は次のとおりです。
org.quartz.dataSource.idp.java.naming.provider.url
dscscheduler.properties という名前の新しいファイルを作成します。
このプロパティの値を、必要に応じてアプリケーションサーバーノード用に設定します。例えば、次のように設定します。
org.quartz.dataSource.idp.java.naming.provider.url =
jnp://localhost:1099/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
JVM 引数 -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties を、アプリケーションサーバーの起動スクリプトまたは起動設定に追加します。
WebSphereWebSphere で、JNDI URL がアプリケーションサーバーのデフォルト JNDI URL（WebSphere の場合は iiop://localhost:2809）とは異なる場合、アプリケーションサーバーにより管理される IDP_DS の JNDI URL は次のとおりです。
org.quartz.dataSource.idp.java.naming.provider.url
dscscheduler.properties という名前の新しいファイルを作成します。
このプロパティの値を、必要に応じてアプリケーションサーバーノード用に設定します。例えば、次のように設定します。
org.quartz.dataSource.idp.java.naming.provider.url =
iop://localhost:2809/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
JVM 引数 -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties を、アプリケーションサーバーの起動スクリプトまたは起動設定に追加します。
WebLogicWebLogic で、JNDI URL がアプリケーションサーバーのデフォルト JNDI URL（WebLogic の場合は t3://localhost:7001）とは異なる場合、アプリケーションサーバーにより管理される IDP_DS の JNDI URL は次のとおりです。
org.quartz.dataSource.idp.java.naming.provider.url
dscscheduler.properties という名前の新しいファイルを作成します。
このプロパティの値を、必要に応じてアプリケーションサーバーノード用に設定します。例えば、次のように設定します。
org.quartz.dataSource.idp.java.naming.provider.url =
t3://localhost:7001/
org.quartz.jobstore.isClustered = true
org.quartz.scheduler.instanceId = AUTO
JVM 引数 -Dadobe.idp.scheduler.properties=[Path to this file]/dscscheduler.properties を、アプリケーションサーバーの起動スクリプトまたは起動設定に追加します。
WebLogic で膨大なログ生成により FileNet API のパフォーマンスが低下するWebLogic Server にインストールされているLiveCycle では、膨大なログの生成が原因で IBM® FileNet API のパフォーマンスが低下することがあります。そのような場合にパフォーマンスを向上させるには、ログレベルを debug から Fatal に変更する必要があります。
FileNet Content Server で、C:¥Program Files¥FileNet¥ContentEngine¥config¥samples ディレクトリに移動します。
log4j.properties.client ファイルを LiveCycle サーバーマシンにコピーし、名前を log4j.properties に変更します。
log4j.properties ファイルを開き、 FileNetTraceAppender と FileNetTraceRollingAppender の appender のエントリを、次のようにコメントアウトします。 #=== FileNetTraceAppender
log4j.appender.FileNetTraceAppender=org.apache.log4j.FileAppender log4j.appender.FileNetTraceAppender.File=/p8_api_trace.log # This is the layout that the TraceLoggingConfiguration framework on the server uses.
# To use this layout , jace.jar must be present in the classpath. #log4j.appender.FileNetTraceAppender.layout=com.filenet.apiimpl.util.TraceLayout # Comment out the following lines if using the FileNet TraceLayout log4j.appender.FileNetTraceAppender.layout=org.apache.log4j.PatternLayout log4j.appender.FileNetTraceAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n #=== FileNetTraceRollingAppender log4j.appender.FileNetTraceRollingAppender=org.apache.log4j.RollingFileAppender log4j.appender.FileNetTraceRollingAppender.File=/p8_api_trace.log log4j.appender.FileNetTraceRollingAppender.MaxFileSize=100MB log4j.appender.FileNetTraceRollingAppender.MaxBackupIndex=1
# This is the layout that the TraceLoggingConfiguration framework on the server uses.
# To use this layout , jace.jar must be present in the classpath.
#log4j.appender.FileNetTraceRollingAppender.layout=com.filenet.apiimpl.util.TraceLayout
# Comment out the following lines if using the FileNet TraceLayout
log4j.appender.FileNetTraceRollingAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.FileNetTraceRollingAppender.layout.ConversionPattern=%d %5p [%t] - %m\r\n
log4j.properties ファイルを保存します。
log4j.properties ファイルを含むフォルダーのパスを、LiveCycle アプリケーションサーバーに配置されている adobe-component-ext.properties ファイル内の FileNet Component ID エントリに追加します。WebLogic Application Server の場合、このファイルは [WL_HOME]/user_projects/domains/<domain name> にあります。
例えば、log4j.properties ファイルが C:/log4j_file/log4j.properties に格納されている場合は、adobe-component-ext.properties ファイルに「C:/log4j_file」を追加します。
アプリケーションサーバーを再起動します。
多数の同時ユーザーが Content Services（非推奨）にアクセスしているときのキャッシュアイテムの有効期限切れ警告注意： アドビは、Adobe® LiveCycle® Content Services ES のお客様に、コンテンツリポジトリへの移行をお願いしています。コンテンツリポジトリはモジュール化された最新の CRX アーキテクチャ上に構築されており、この CRX アーキテクチャは、アドビによる Day Software の吸収合併により利用可能になりました。Content Repository は LiveCycle Foundation に付属し、LiveCycle ES4 リリース以降で利用できます。
多数のユーザーが同時に Content Services にアクセスしていると、アプリケーションサーバーログに次の警告メッセージが出力されることがあります。
ReadWriteCach W org.hibernate.cache.ReadWriteCache handleLockExpiry An item was expired by the cache while it was locked (increase your cache timeout): org.alfresco.repo.domain.hibernate.NodeImpl.properties
この問題を解決するには、アプリケーションサーバーの起動スクリプトの次の JVM 引数を、デフォルトのヒューリスティックアルゴリズムではなく、LRU（Least Recently Used）アルゴリズムを使用するように設定して、ehcache を更新します。
-Dnet.sf.ehcache.use.classic.lru=true
|
|
|
