Oracle® Fusion Middleware Oracle WebCenter Portalの管理 11gリリース1 (11.1.1.8.3) E51441-03 |
|
前 |
次 |
この付録では、Oracle WebCenter Portalのトラブルシューティング情報について説明します。
この付録には次のトピックが含まれます:
このドキュメントのロードマップを使用して、Oracle WebCenter Portalのトラブルシューティング情報を参照します。図G-1で、問題を最もよく示す開始点を見つけ図形をクリックするか、表G-1のリンクをクリックして、必要な項に移動します。
図G-1 Oracle WebCenter Portalのトラブルシューティングのロードマップ
表G-1 WebCenter Portalのトラブルシューティングの開始点
実行する処理 | ガイド内のトラブルシューティングの項へのリンク |
---|---|
|
第G.2項「Oracle WebCenter Portalの構成に関する問題のトラブルシューティング」 |
|
第G.3項「Oracle WebCenter Portal WLSTコマンドの問題のトラブルシューティング」 |
|
第27項「Oracle WebCenter Portalのパフォーマンスのモニタリング」 第28項「Oracle WebCenter Portalログの管理」 |
|
第G.4項「Oracle WebCenter Portalのパフォーマンスに関する問題のトラブルシューティング」 |
この項には次のサブセクションが含まれます:
ご使用の環境にインストールされているOracle WebCenter Portalの製品およびコンポーネントのバージョン情報を入手するには、必ずOracleのOPatchユーティリティを使用します。
lsinventory
オプションを指定してOPatchコマンドを実行するには:
Opatch環境変数のWCP_ORACLE_HOME
、MW_HOME
およびPATH
を設定します。
『Oracle Fusion Middlewareパッチ適用ガイド』のOracle OPatchを使用したOracle Fusion Middlewareへのパッチの適用に関する項を参照してください。
次のOPatchコマンドを実行します。
opatch lsinventory -details
次のように、インストールされているコンポーネントとそのバージョン番号のリストが出力されます。
... Oracle Upgrade Assistant for Webcenter 11.1.1.8.0 Oracle WebCenter Portal Suite 11.1.1.8.0 Oracle WebCenter Portal Suite 11g 11.1.1.8.0 Oracle WebCenter Portal: Activity Graph 11.1.1.8.0 Oracle WebCenter Portal: Analytics Collector 11.1.1.8.0 Oracle WebCenter Portal: Discussions Server 11.1.1.8.0 Oracle Webcenter Portal: Framework 11.1.1.8.0 Oracle Webcenter Portal: Framework Core 11.1.1.8.0 Oracle WebCenter Portal: Pagelet Producers 11.1.1.8.0 Oracle WebCenter Portal: Personalization 11.1.1.8.0 Oracle Webcenter Portal: Portlet Server 11.1.1.8.0 Oracle WebCenter Portal: RCU 11.1.1.8.0 Oracle Webcenter Portal: Spaces 11.1.1.8.0 Oracle WebCenter Portal: Suite Components 11.1.1.8.0 Oracle WebCenter Portal: Wiki 11.1.1.8.0 ...
注意:
|
『Oracle Fusion Middlewareパッチ適用ガイド』のOracle OPatchを使用したOracle Fusion Middlewareへのパッチの適用に関する項およびOracle Universal InstallerおよびOPatchユーザーズ・ガイド for Windows and UNIXのOUIベースのOracleホーム用のLsinventoryコマンドに関する項を参照してください。
図G-2 Fusion Middleware ControlでのWebCenter Portalの正しくないバージョン番号の表示
図G-3 Fusion Middleware Controlでの他のアプリケーションの正しくないバージョン番号の表示
問題
Fusion Middleware Controlにログインした後、使用しているアプリケーションの「アプリケーションのデプロイ」メニューで、「WebCenterポータル」オプションが見つかりません。
解決策
次のことを確認します。
デプロイ済アプリケーションは、JDeveloperでWebCenter Portal Frameworkアプリケーションのテンプレートを使用して作成されたPortal Frameworkアプリケーションであること。
「WebCenterポータル」オプションは、JDeveloperでWebCenter Portal Frameworkアプリケーションのテンプレートを使用して開発されたアプリケーションに対してのみ表示されます。
デプロイ済Portal Frameworkアプリケーションが稼働中であること。
デプロイ済Portal Frameworkアプリケーションには、MDSリポジトリおよびパーティションに関する正確な情報が含まれ、MDSリポジトリはアプリケーションからアクセス可能であること。この情報を確認するには、adf-config.xml
ファイルのmetadata-store-usages
セクションをチェックします。MDSの詳細は、『Oracle Fusion Middleware管理者ガイド』のMDSリポジトリの理解に関する項を参照してください。
次の構成をサポートするために、Portal Frameworkアプリケーションが必須アーティファクトと一緒にパッケージ化されていること。
adf-jndi-config
ネームスペースは、アプリケーションのadf-config.xml
ファイルで構成されます。これは、設計時にプロビジョニングされます。次はadf-jndi-config
ネームスペースの例(太字のテキスト)です。
<adf-config xmlns="http://xmlns.oracle.com/adf/config"
xmlns:jndiC="http://xmlns.oracle.com/adf/jndi/config"
xmlns:ns2="http://xmlns.oracle.com/mds/config"
xmlns:ns3="http://xmlns.oracle.com/adf/mds/config">
...
...
</adf-config>
MBeansを登録するために、適切なリスナーがweb.xml
ファイルに存在します。これは、設計時にプロビジョニングされます。たとえば、web.xml
ファイルの次のスニペットで太字のテキストを表示します。
<listener> <description>ADF Config MBeans</description> <display-name>ADF Config MBeans</display-name> <listener-class>oracle.adf.mbean.share.config.ADFConfigLifeCycleCallBack</listener-class> </listener> <listener> <description>ADF Connection MBeans</description> <display-name>ADF Connection MBeans</display-name> <listener-class>oracle.adf.mbean.share.connection.ADFConnectionLifeCycleCallBack</listener-class> </listener>
ADFConfig
およびADFConnection
MBeanが、WebCenter PortalまたはPortal Frameworkアプリケーションに対して登録されていること。システムMBeanブラウザを使用して、これらのMBeanが登録されているかどうかを確認できます。
Fusion Middleware Controlで、アプリケーションのシステムMBeanブラウザを開きます。次のいずれかを実行します。
WebCenter Portalでは、メニュー・オプションの「WebCenterポータル」→「システムMBeanブラウザ」を選択します。
Portal Frameworkアプリケーションでは、メニュー・オプションの「アプリケーションのデプロイ」→「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」→「oracle.adf.mbean.share.connection」の下で、アプリケーションのADFConnection
MBeanを見つけます(図G-4を参照)。
同様に、「アプリケーション定義のMBean」→「oracle.adf.mbean.share.config」の下で、アプリケーションのADFConfig
MBeanを見つけます(図G-4を参照)。
第1.13.4項「システムMBeanブラウザ」も参照してください。
adf-connections.xml
およびadf-config.xml
で最新の構成を見直し、内容が正しいかどうかを確認すること。よくある問題は次のとおりです。
構成ファイルがXMLスキーマに準拠していません。たとえば、スキーマで許可されている構成要素の出現回数が1回のみの場合に、重複した構成要素が存在します。
ファイル内で参照される構成にXMLネームスペースがありません。
XML要素がXMLネームスペースで修飾されていません。
付録Aの「MDSカスタマイズが含まれている構成ファイルのエクスポート」も参照してください。
アプリケーションの診断ログを確認して、モジュールoracle.adf.mbean.share.connection
およびoracle.adf.mbean.share.config
のメッセージを分析し、必要な作業を判断すること。
WebCenter Portalの場合、このログ・ファイルがDOMAIN_HOME
/servers/
ServerName
/logs
ディレクトリで参照可能です。ログ・ファイルは、ServerName
-diagnostic.log
の命名規則に従います。第28.2.1項「WebCenter Portalログの表示および構成」も参照してください。
Portal Frameworkアプリケーションの場合、このログ・ファイルがDOMAIN_HOME
/servers/
ServerName
/logs
ディレクトリで参照可能です。ログ・ファイルは、ServerName
-diagnostic.log
の命名規則に従います。第28.2.2項「Portal Frameworkアプリケーション・ログの表示および構成」も参照してください。
問題
Fusion Middleware ControlからWebCenter PortalまたはPortal Frameworkアプリケーションを構成する場合は、次のメッセージが表示されます。
Configuration options currently unavailable. The application application_name might be down, did not start-up properly, or is incorrectly packaged.
Check the log files for further details.
たとえば、Fusion Middleware Controlで、「アプリケーション設定」画面から利用できるオプションを変更しようとしているか、「WebCenter Portalサービス構成」画面から接続を構成しようとしています。
解決策
アプリケーションの診断ログを確認します。
WebCenter Portalの場合、このログ・ファイルがDOMAIN_HOME
/servers/
ServerName
/logs
ディレクトリで参照可能です。ログ・ファイルは、ServerName
-diagnostic.log
の命名規則に従います。第28.2.1項「WebCenter Portalログの表示および構成」も参照してください。
Portal Frameworkアプリケーションの場合、このログ・ファイルがDOMAIN_HOME
/servers/
ServerName
/logs
ディレクトリで参照可能です。ログ・ファイルは、ServerName
-diagnostic.log
の命名規則に従います。第28.2.2項「Portal Frameworkアプリケーション・ログの表示および構成」も参照してください。
モジュールoracle.adf.mbean.share.connection
およびoracle.adf.mbean.share.config
のメッセージを分析し、必要な作業を判断します。
第G.2.2項「WebCenter PortalのメニューがFusion Middleware Controlに表示されない」も参照してください。
アプリケーションでサポートされていないサービスを構成しないようにしてください。ご使用のアプリケーションが使用するように設計されていないサービス、たとえばディスカッションを構成しようとすると、Enterprise ManagerおよびWLSTを使用したWebCenter Portalの構成は失敗します。
即時利用可能なアプリケーションであるWebCenter Portalは、すべてのツールとサービスをサポートするように設計されていますが、JDeveloperを使用して作成したPortal Frameworkアプリケーションは、開発者が設計時に特別に追加したサービスに対して、アプリケーションの構成内でのアーティファクトのみを提供します。たとえば開発者がJDeveloperでアプリケーションのディスカッションを追加または構成しなかった場合は、デプロイ後にEnterprise ManagerおよびWLSTでディスカッションを構成できません。
1つ以上のツールまたはサービスの構成または接続に関して問題が発生している場合は、次の適切なトラブルシューティングの項を参照してください。
問題
WebCenter PortalまたはPortal Frameworkアプリケーションを構成しましたが、これらの構成が別のアプリケーションでも表示されます。
たとえば、MyPortalApp1という名前のPortal Frameworkアプリケーションのメール接続を作成または編集すると、その接続の変更が別のアプリケーションMyPortalApp2でも表示されます。
解決策
これは複数のアプリケーションがMDSパーティションを同じスキーマで共有する場合に発生します。この問題を解決するには、これらのアプリケーションを再度デプロイして、各アプリケーションが異なるMDSスキーマまたは異なるMDSパーティションを使用するようにします。異なるMDSリポジトリまたはパーティションを使用するために、MDSリポジトリを作成するか、既存のアプリケーションを構成する方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のメタデータ・リポジトリの管理に関する項を参照してください。
問題
WebCenter PortalまたはPortal Frameworkアプリケーションにアクセスできないか、エラー・メッセージが表示されていて、オープン・ファイルが多すぎるという問題があることを診断ログ・ファイルが示しています。
解決策
次の操作を実行します。
各バックエンド・サーバー(主にデータベース)で構成されるファイル・ハンドル数を確認し、必要に応じて数を増やします。
ファイル・ハンドル数を増加した後でも問題が解決されない場合は、/etc/sysctl.conf
ファイルのfs.file-max
の値を確認し、必要に応じて値を増やします。
この項には次のサブセクションが含まれます:
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
WLSTコマンドをいずれも実行できません。
解決策
次のことを確認します。
Oracle WebCenter Portal WLSTコマンドは常に、WebCenter Portal Oracleホーム・ディレクトリ(WCP_ORACLE_HOME
/common/bin
)から実行してください。
間違ったディレクトリからOracle WebCenter PortalのWLSTコマンドを起動しようとすると、NameError
が表示されます。
Python以外のファイルは、WLSTソース・ディレクトリ: WCP_ORACLE_HOME
/common/bin/wlst
には格納されません。このディレクトリには、.py
拡張子のみを持つファイルが含まれる必要があります。
この場所にあるデフォルトのセットのファイルには、法律に関するオラクル社のPythonファイルが含まれています。ユーザーは、このディレクトリにPython以外のスクリプトをコピーすることは可能です(たとえば、バックアップ・ファイル、構文エラーを含むテストPythonファイルなど)。
webcenter-wlst.jar
は、WCP_ORACLE_HOME
/common/bin/wlst/lib
にあります。
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
WLSTコマンドが特定のツールまたはサービスに対して実行できないため、そのツール/サービスを構成できません。
解決策
最初に、listApplications
またはdisplayMetricTableNames
などの一般的なOracle WebCenter Portal以外のコマンドを実行して、これらのコマンドが機能するかどうかを確認します。一般的なコマンドが機能しない場合は、第G.3.1項「Oracle WebCenter Portal WLSTのどのコマンドも機能しない」で説明される解決策を適用してください。
一般的なコマンドが機能する場合は、テスト・コマンドを実行して、Oracle WebCenter Portal固有のコマンドに構文エラーがないか確認します。適切なWSLTチェック・コマンドを実行してください(表G-2を参照)。
表G-2 Oracle WebCenter Portalツールおよびサービスのファイル名とWLSTコマンド
サービス名 | ファイル名 | WLSTコマンド |
---|---|---|
アクティビティ・グラフ |
|
|
アクティビティ・ストリーム |
|
|
分析 |
|
|
ディスカッションおよびお知らせ |
|
|
ドキュメント |
|
|
外部アプリケーション |
|
|
ポータル・イベント |
|
|
インスタント・メッセージおよびプレゼンス |
|
|
メール |
|
|
通知 |
|
|
個人イベント |
|
|
プロデューサ |
||
PDK-Javaプロデューサ |
|
|
WSRPプロデューサ |
|
|
ページレット・プロデューサ |
|
|
プロデューサ・ヘルパー |
|
|
RSSニュース・フィード |
|
|
検索 |
|
|
ワークリスト |
|
|
エクスポート/インポート: WebCenter Portalアプリケーション |
|
|
エクスポート/インポート: ポータルおよびテンプレート |
|
|
ユーザーの同期化 |
|
|
ユーザーの名前変更 |
|
|
WebCenter Portal: 一般 |
||
サービス・フレームワーク |
|
|
一般設定 |
|
|
WebCenter PortalおよびSOA |
|
|
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
Oracle WebCenter PortalのWLSTコマンドの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「WebCenter PortalのカスタムWLSTコマンド」を参照してください。
問題
Connection_Name
という名前の接続を作成できません。次のメッセージが表示されます。
A connection with nameConnection_Name
already exists.
たとえば、WLSTコマンドcreateExtAppConnection
を使用して外部アプリケーション接続を作成しようとしているか、createMailConnection
を使用してメール・サーバーに接続しようとしています。
解決策
接続名は、WebCenter PortalまたはPortal Frameworkアプリケーションのすべての接続タイプにおいて一意である必要があります。使用中の名前で接続を作成しようとするとエラーが発生します。接続に一意の名前を使用していることを確認してください。
問題
WLSTコマンドを実行する前に、Oracle WebCenter Portalの管理サーバーに接続する必要があります。接続しなければ、Oracle WebCenter Portal WLSTコマンドは機能しません。
解決策
WLSTシェルを管理対象サーバーに接続するには、次のコマンドを実行してください。
connect(username, password , serverhost:serverport
)
第G.3.1項「Oracle WebCenter Portal WLSTのどのコマンドも機能しない」および第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
サービスの接続の作成やポートレット・プロデューサの登録などの操作をWebCenter PortalまたはPortal Frameworkアプリケーションで実行しようとすると、次のメッセージが表示されます。
Another application named "YourApplicationName
" exists. Specify the Server on which your application is deployed. Use: server="YourServerName".
同じ名前の複数のアプリケーションがドメインに存在している場合に、このメッセージが表示されます。これは通常、同じアプリケーションが複数の管理対象サーバーにデプロイされる、クラスタ環境で発生します。
たとえば、次のWLSTコマンドを使用してMyAppというアプリケーションのポートレット・プロデューサを登録する場合があります。
registerWSRPProducer(appName='myApp', name='MyWSRPSamples', url='http://myhost.com:9999/ portletapp/portlets/wsrp2?WSDL')
解決策
WLSTコマンドを実行する管理対象サーバーを指定します。つまり、server
引数を追加します。例:
registerWSRPProducer(appName='myApp', name='MyWSRPSamples', url='http://myhost.com:9999/portletapp/portlets/wsrp2?WSDL', server=WC_CustomPortal2)
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
サービスの接続の作成やポートレット・プロデューサの登録などの操作をWebCenter PortalまたはPortal Frameworkアプリケーションで実行しようとすると、次のメッセージが表示されます。
Another application named "application_name
" exists on the servermanagedServerName
.
このメッセージは、指定された管理対象サーバーに同じ名前の複数のアプリケーションが存在していることを示します。これは通常、アプリケーションが別のバージョンを割り当てられている場合に発生します。
たとえば、次のWLSTコマンドを使用してMyAppというアプリケーションのポートレット・プロデューサを登録する場合があります。
registerWSRPProducer(appName='myApp', name='MyWSRPSamples', url='http://myhost.com:9999/portletapp/portlets/wsrp2?WSDL')
解決策
WLSTコマンドを実行するアプリケーションのバージョンを指定します。つまり、server
引数とapplicationVersion
引数を追加します。例:
registerWSRPProducer(appName='myApp', name='MyWSRPSamples', url='http://myhost.com:9999/portletapp/portlets/wsrp2?WSDL', server=WC_CustomPortal1, applicationVersion=2)
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
この項の情報は、Oracle WebCenter Portalのパフォーマンス関連問題の診断に役立ちます。
この項には次のサブセクションが含まれます:
様々なツールを使用して、Oracle WebCenter Portal環境でのパフォーマンス問題をモニタリングおよびトラブルシューティングできます。
表G-3 パフォーマンスのモニタリングとトラブルシューティング・ツール
ツール | 使用目的 | 参照先 |
---|---|---|
Enterprise Manager |
||
Fusion Middleware Control |
単一のOracle Fusion Middlewareファームに関するWebCenter Portalのメトリックとログ・ファイルをリアルタイム・モードでモニターします。 WebCenter Portalデプロイメント用のMDSとパーティションなどのサービス構成を確認します。 |
Enterprise Manager Fusion Middleware Controlの起動 |
Grid Control |
傾向を分析するために、WebCenter Portalメトリックをリアルタイムかつ履歴的観点からモニターします。また基礎となるホストおよびオペレーティング・システム、データベースなどもモニターします。 Oracle Enterprise Manager 11g Grid Controlは、Oracle Fusion Middleware 11gインストールに属していないため、個別にインストールする必要があります。Grid Controlを使用すると、複数のOracle Fusion MiddlewareファームとWebLogicドメインを一元的に管理できます。 |
Oracle Enterprise Manager Grid Control |
WebCenterポータル・ページ・パフォーマンス・アナライザ |
WebCenter Portalのポータル・ページのパフォーマンスを分析します。WebCenter Portalでページを表示すると、このツールによって、個々のページ・コンポーネントのパフォーマンスが動的に測定および表示されます。 |
|
JConsole |
JavaアプリケーションとJava仮想マシン(JVM)をグラフィカルにモニターします。 |
|
JRockit Mission Control |
メモリー、CPU使用率および他のランタイム・メトリックに関するライブ・データを取得および表示します。 |
|
Eclipse Memory Analyzer |
メモリー・リークを見つけ、メモリー使用率を減らします。 |
|
Threadlogic |
スレッド・ダンプを分析します。 |
非常に遅いページ・パフォーマンス、多いスレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成 |
表G-4に記載されているアクションを使用して、システム全体の遅さをトラブルシューティングします。
表G-4 システム全体の遅さのトラブルシューティング
アクション | 説明 | 詳細 |
---|---|---|
1 |
主要なシステム・リソースを確認します。 |
|
2 |
|
|
3 |
Java Virtual Machine (JVM)のパフォーマンスをモニターします。 |
Java Virtual Machine (JVM)の使用状況のモニタリング |
4 |
OIDおよびデータベースの接続プール設定を確認します。 |
|
5 |
Oracleデータベースの自動ワークロード・リポジトリ(AWR)レポートを生成し、データベース関連の問題を診断します。 |
データベースの自動ワークロード・リポジトリ(AWR)レポートの生成 |
6 |
|
|
7 |
|
|
8 |
スレッド・ダンプを収集します。 |
非常に遅いページ・パフォーマンス、多いスレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成 |
9 |
|
|
10 |
DMS Spyを使用して、Javaオブジェクト・キャッシュ内のアクティビティなど、内部DMSメトリック・データをモニターします。 |
DMS Spyを使用した内部パフォーマンス・メトリックの表のモニター |
11 |
WebLogic Serverの HTTP圧縮設定を確認します。 |
|
12 |
HTTPモニタリング・ツールを使用して、リクエストおよびレスポンス時間を分析します。 |
|
13 |
パフォーマンスを測定する前に、システムをウォーム・アップします。 |
|
パフォーマンス問題が発生する場合は、十分なシステム・ハードウェア・リソースがあること、つまりOracle WebCenter Portalインストール用のCPUと物理メモリー容量が適切かどうかを確認することが重要です。
システム・リソースが不足していると、多くの様々な問題が発生する可能性があります。システム・リソースは、個々のサービスによって使用されます。システムの使用状況を定期的にモニタリングおよび記録すると、システム・ハードウェアのアップグレードが必要かどうか、または一部のサービスを別のマシンに移動する必要があるかどうかを判断する際に役立ちます。
システムのCPUとメモリーを確認するには:
Linuxでは、次のファイルでCPUとメモリーの情報を確認します。
/proc/cpuinfo
cpuinfo
ファイルには、モデル、CPUコア、CPU MHz、キャッシュ・サイズなどの重要なCPU情報と、プロセッサで利用できる命令セットを示すフラグが含まれています。複数のプロセッサまたは複数のコアのあるシステムには、それぞれ異なるエントリがあります。
/proc/meminfo
meminfoファイルで参照する重要なフィールドには、MemTotal
、MemFree
、Cached
およびSwapTotal
などがあります。
Windowsでは、タスク・マネージャ(「パフォーマンス」→「リソース・モニター」)からCPUとメモリーの情報にアクセスします。
Linuxでは、top
およびvmstat
ユーティリティを使用して、システムの遅さの原因がCPU、メモリーまたはI/O競合の問題であるかどうかを確認します。システム・リソースの低下を検出した場合は、次の操作を行うことができます。
プロセスを別のマシンに移動するか、未使用のプロセス/プログラムを停止して、物理メモリーまたはCPUサイクル、あるいはその両方を開放します。
システム・ハードウェア・リソースをアップグレードします。
詳細は、次を参照してください。
注意: Windowsでは、タスク・マネージャを使用してシステム・リソースをモニターするか、未使用のプロセスおよびプログラムを停止します。詳細は、Windowsのドキュメントを参照してください。 |
top
ユーティリティは、システム・リソース使用率の継続的な更新レポートを表示するため、システムにおけるメモリーおよびCPUの上位コンシューマを特定できます。
レポートのtop部分には、システム時間、起動時間、CPU使用率、物理およびスワップ・メモリー使用量、プロセス数などの情報が表示されます。次に示すのは、CPU使用率を基準にソートされたプロセスのリストです。
注意: メモリー使用量でソートするには、 |
# top 2:10:49 up 8 day, 3:47, 20 users, load average: 0.34, 0.19, 0.10 75 processes: 20 sleeping, 2 running, 8 zombie, 0 stopped CPU states: 5.1% user 1.1% system 0.0% nice 0.0% iowait 93.6% idle Mem: 512216k av, 506176k used, 6540k free, 0k shrd, 21888k buff Swap: 1044216k av, 161672k used, 882544k free 199388k cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 2330 admin 15 0 161M 70M 2132 S 4.9 14.0 1000m 0 oracle 2605 lin 15 0 8240 6340 3804 S 0.3 1.2 1:12 0 oracle 3413 harvey 15 0 6668 5324 3216 R 0.3 1.0 0:20 0 oracle
トラブルシューティングのヒント - top:
free
メモリーが100MB未満、およびキャッシュされたメモリーが1GB未満の場合は、システム・メモリーが低下しています。
%wa
(I/O待機)が常に10%を超えている場合は、システムは物理I/Oによってブロックされるため遅くなる可能性があります。
システムに負荷がないときは、idle
値が100%に近く、system
/user
のCPU使用率が0%に近いことを確認します。
top
のメモリー表示で、各プロセス(PID
)のメモリー使用率(%MEM
)を特定します。メモリーに余裕がなく、スワップ領域使用率が高い場合は、次のことを検討します。
- メモリー使用量の高いプロセスを別のマシンに移動します
- 仮想マシンへのメモリー割当てを増やします
- 物理メモリーを追加します
vmstat
ユーティリティは、システムの様々な部分(システム・プロセス、メモリー、スワップ、I/O、CPU、Virtual Memory Managerなど)に関する現行の統計を表示します。これらの統計は、コマンドが最後に実行されたときから現在までのデータを使用して生成されます。コマンドを初めて実行すると、最後の再起動から現在までのデータが表示されます。
vmstat
を実行するとき、vmstat <リフレッシュ率(秒)>
という形式を使用して、統計をリフレッシュする頻度(秒)を指定できます。
例: vmstat 3
システム・リソース使用率を頻繁に更新すると、CPU/メモリー使用率の傾向と、使用率の傾向がWebCenter PortalまたはPortal Frameworkアプリケーションのパフォーマンスにどのように影響するかを確認することができます。システムが安定している場合は、スワップ
・メトリック(si
およびso
)がほぼゼロに登録されます。
# vmstat 3 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 3 0 144 1058184 868324 12343056 0 0 220 83 33 14 10 1 88 1 0 0 144 1058184 868324 12343056 0 0 0 117 478 656 5 1 94 0 0 0 144 1058192 868324 12343056 0 0 0 69 696 860 9 1 90 0 2 0 144 1058264 868324 12343056 0 0 0 0 914 1127 5 2 93 0 0 0 144 1057864 868324 12343316 0 0 0 184 857 1021 7 1 92 0 2 0 144 1057592 868324 12343316 0 0 0 155 1596 1646 5 4 91 0 0 0 144 1057592 868324 12343316 0 0 0 0 737 839 5 2 94 0 0 0 144 1057592 868324 12343316 0 0 0 57 694 743 8 2 91 0 2 0 144 1057592 868324 12343316 0 0 0 0 358 437 2 0 98 0
トラブルシューティングのヒント - vmstat:
スワップ
・メトリック(si
およびso
)が頻繁にゼロ以外になる場合は、システム・メモリーに余裕がなくなり、システムがスラッシング・モードになる可能性があります。システム・メモリーの低下は、パフォーマンスに大きな影響を与えます。つまりシステムで実行されているプログラムが非常に遅くなります。頻繁にシステム・メモリーが低下する場合は、マシン上のメモリーを増やしてください。
CPUアイドル時間(id
)が常に10%未満の場合は、CPUは最大能力または過剰能力で動作しています。そのような状況では、システムにさらに負荷がかかると、パフォーマンスが著しく低下します。
Java Virtual Machine (JVM)は、Oracle WebCenter Portalパフォーマンスに大きな影響を及ぼす可能性があります。このため、継続してJVMをモニターし次を追跡することをお薦めします。
メモリー使用量
CPU使用率
スレッド・アクティビティ
Fusion Middleware Controlのアプリケーションの「最近のWebLogic Serverメトリック」ページから、3つすべてのメトリックをモニターできます(図G-5)。詳細は、第27.1.8項「WebLogic Serverメトリックの理解」および第27.2項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」を参照してください。
メモリーの傾向のモニター: JVMは頻繁にメモリーの割当てと解放を行います。メモリー・リークと高いメモリー使用量を検出するには、メモリーの傾向を長期間(1時間また数時間)分析する必要があります。
メモリー・グラフで一番下の傾向線が上昇している場合は、メモリー・リークを示しています。メモリー・グラフの一番下のポイントは、完全ガベージ・コレクションの後にメモリー使用量がどこまで低下する可能性があるかを示します。少なくとも2つのメモリー・ダンプ(1つはメモリーが健全である場合、もう1つはメモリーの完全ガベージ・コレクションで過度の量をリサイクルできない場合)を採取すると、メモリー・ダンプを比較して、メモリーを消費しているコンポーネントを特定できます。
第G.4.5.4項「メモリー・リークとヒープ使用量問題のトラブルシューティング」も参照してください。
CPU使用率のモニター: CPU使用率で不定期にスパイクが発生するのは正常ですが、CPU使用率が長期間高い(85-90%)場合は、通常、パフォーマンスに影響を及ぼす可能性のあるCPU問題が発生していることを示します。
CPU使用率が過負荷に見える場合は、定期的(たとえば5秒ごと)にいくつかのスレッド・ダンプを比較すると、CPU使用率の高さの原因を明らかにすることができます。
あるいは、JRockit Flight Recorderのようなプロファイリング・ツールを使用すると、CPU使用率を詳細に把握することができます。
スレッド・アクティビティのモニターとスレッド・ダンプの分析(スタックされたスレッド、ブロックされたスレッド、デッドロック): 負荷状態が安定している場合は、スレッド数は一定です。突然のスパイクやスレッド数の増加は、一般的にシステム内に問題があることを示しています。
このような場合、複数のスレッド・ダンプを採取して、スタック/ブロックされたスレッドまたはデッドロックのコール元スタックを把握することができます。スレッド分析ツールを使用すると、余分なスレッドの原因とそれによって何が実行されているかを特定でき、また問題のある領域とパフォーマンスが低下している領域を検出できます。第G.4.5.2項「スタック・スレッドのトラブルシューティング」も参照してください。
第G.4.2.8項「非常に表示が遅いページのパフォーマンス、高スレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成」も参照してください。
ヒント: Oracle Fusion Middlewareの診断フレームワークでは、スタックされたスレッド、デッドロックされたスレッドなどの一般的な問題に関する情報を収集して管理し、そのような問題の診断と解決を支援します。あるいは、診断ダンプをOracleサポート・サービスに送信することもできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の「問題の診断」を参照してください。 |
Fusion Middleware Control、JConsole、JVisualVM、JRockit Mission Controlなどの様々なツールを使用して、JVMパフォーマンスをモニターできます。これらのいずれかのツールを使用して、JVMの現在の状態およびアクティビティ・スレッドとその状態を表示します。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のJava仮想マシン(JVM)のチューニングに関する項も参照してください。
管理者はまず、Fusion Middleware Controlのアプリケーションの「最近のWebLogic Serverメトリック」ページを使用してJVMをモニターできます(図G-5を参照)。よりアグレッシブなリアルタイム・メトリックが必要な場合は、別の選択肢としてJConsoleを使用します(図G-6を参照)。
JConsoleは、HotSpot、JRockit、IBM JVMなどJVMのすべてのタイプで利用できます。
JConsoleの実行可能ファイルは、JAVA_HOME/bin/jconsole.exe
にあります。
この項では、次の接続プール設定を確認する方法を説明します。
レスポンス時間が遅く、診断ログ・ファイルに接続/接続プール・メッセージが含まれていたり、最近のスレッド・ダンプに接続プールからの接続の取得を待機しているコール元スタックが含まれていたりする場合に、この項の情報が役に立つことがあります。
管理者は、Fusion Middleware Controlを使用してWebCenter PortalまたはPortal FrameworkアプリケーションのJDBC接続メトリックをモニターできます。「WebLogic Serverメトリック」ページ(図G-7)のJDBC使用状況の情報を使用して、JDBCの構成または接続プール・サイズの調整が必要かどうかを評価します。
第27.2項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」も参照してください。
「最近のJDBC使用状況」グラフには、管理対象サーバーで現在オープンになっているJDBC接続数が表示されます。ここで表示されるJDBCセッション数は、JDBCデータ・ソースごとの「現在アクティブな接続数」メトリックの合計です。
使用状況が高く上昇傾向にある場合は、管理者は、WebLogic Server管理コンソールを使用してデータ・ソースの接続プール設定を表示および構成したり、個々のデータ・ソースの使用状況パターンを詳細にモニターしたりすることができます。一定期間データ・ソースの使用状況をモニターすると、次のことを行うことができます。
特定のデータベース接続に対する最適な接続プール・サイズの決定。
負荷がなければデータ・ソース接続数が減少しない場合の接続プールのリークの検出と解決。
ヒント: 接続プールのモニタリング時に「表のカスタマイズ」を選択して、次のような追加のメトリックを表示します。
|
同時実行性の高いシステムでは、プール内の最大接続数(「最大接続数」設定)を変更することもできます。ここでは、様々なWebCenter Portalデータ・ソースの初期設定の最大値を示します。
WebCenter Portal データ・ソース |
接続プールの デフォルトの最大接続数 |
---|---|
WebCenterDS |
50 |
ActivitiesDS |
25 |
mds-SpacesDS |
50 |
mds-owsmDS |
15 |
mds-PageletProducerDS |
50 |
mds-ServicesProducerDS |
50 |
mds-wcpsDS |
50 |
PersonalizationDS |
25 |
Portlet-ServicesProducerDS |
50 |
PortletDS |
50 |
WC-ServicesProducerDS |
25 |
注意: 各接続ではWebLogic Server内のメモリーが使用され、データベース内のプロセスが消費されます。そのため不必要に大きな接続プール値を指定しないでください。 |
特定のデータ・ソースをモニターするには、WebLogic Server管理コンソールにログインし、「サービス」→「データ・ソース」を選択し、データ・ソース名をクリックして、「モニタリング」タブをクリックします。
特定のデータ・ソースの接続プールを変更するには、WebLogic Server管理コンソールにログインし、「サービス」→「データ・ソース」を選択し、データ・ソース名をクリックして、「接続プール」タブをクリックします。
『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のデータ・ソース接続プールのチューニングに関する項を参照してください。
通常、JNDI接続プールは常に有効になっています。ただし、WebCenter Portal/Portal Frameworkアプリケーションとアイデンティティ・ストア(Oracle Internet Directory、Active Directoryなど)間の接続でSSLが使用される場合は、追加の構成がいくつか必要になります。デフォルトでは、SSLポートを選択すると、JNDI接続がプールされないため、ログインしてユーザー、グループなどのアイデンティティ・ストアのエンティティを検索するときに、レスポンス時間が長くなり、パフォーマンスが低下します。詳細と指示は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のアイデンティティ・ストア構成のチューニングに関する項を参照してください。
データベース・アクセスが遅くなる、たとえば、アクティビティ・ストリームの問合せ、MDSの問合せまたはJPA(Java Persistence API)の問合せがWebCenter Portalアプリケーションでの様々な操作で遅くなる場合は、自動ワークロード・リポジトリ(AWR)レポートを分析して、Oracleデータベースにおけるパフォーマンス関連問題の根本原因を診断できます。
AWRレポートを生成する前に、まず、データベースをホストしているマシンの一般的なヘルス(CPU/メモリー)を確認します(第G.4.2.2項「システム・リソース使用率のモニタリング」を参照)。システム・リソースの制限がパフォーマンス低下の原因でない場合は、AWRレポートでデータベースのパフォーマンス情報と統計を調べます。
詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のデータベース・パラメータのチューニングに関する項および『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』の自動ワークロード・リポジトリ・レポートの生成に関する項を参照してください。
ネットワーク・トラフィックをリスニングおよび取得するネットワーク・ユーティリティであるtcpdump
を使用して、ネットワーク関連問題を調査および診断します。
たとえば、Enterprise ManagerのWebCenter Portalページにあるパフォーマンス・メトリックはサーバーのパフォーマンスが正常であることを示しているが、エンド・ユーザーはパフォーマンスが不安定/遅いことを報告している場合は、ネットワークに問題がある可能性があります。tcpdump
または同様のネットワーク・モニタリング・ツールを使用してネットワーク・トラフィックを追跡し、予想外に長い待機時間の原因が(ネットワーク上の)環境問題であるかどうかを確認します。
このユーティリティを実行してネットワーク・データを分析する方法は、tcpdump
のドキュメントを参照してください。
ping
を使用してネットワーク待機時間を測定します。
Oracle WebCenter Portalのインストールは、様々なバックエンド・コンポーネントとサービス(Oracle HTTP Server、Oracle WebCenter Content Server、LDAPサーバー、インスタント・メッセージおよびプレゼンス・サーバー、メール・サーバー、ポートレット・サーバー、データベースなど)によって変わります。必要なコンポーネントがすべて同じマシンに存在しない場合は、ネットワーク待機時間を最小にするためにコンポーネントを密接して配置すること、可能な場合は同じサブネットに配置することをお薦めします。
あるマシンから別のマシンに対してping
を使用し、ネットワーク待機時間が1ミリ秒未満であることを確認します。
専用のスレッド・ダンプ・ファイルにスレッド・ダンプを生成し、次にThreadLogicやシンプルなテキスト編集ツールなどのスレッド分析ツールを使用して、スレッド実行ロジックおよび進捗状況の把握と関連付けを行うことをお薦めします。
Sun JVM(HotSpot)のスレッド・ダンプを1つのファイルに生成するには:
>jstack <pid> > threaddump.txt
Oracle JRockit JVMのスレッド・ダンプを1つのファイルに生成するには:
>jrcmd print_threads <pid> > threaddump.txt
一定のサンプリング間隔で一連のスレッド・ダンプを生成しておくと、非常に遅いメソッド・コール、スタック・スレッド、デッドロックなどの問題を確認する際に役立つ場合があります。たとえば、ダンプを毎秒生成する単純なスクリプトを作成できます。また遅いリクエストを診断する場合は、遅いリクエストの長さに対応する適切な期間を選択できます。
この例では、スレッド・ダンプを毎秒生成します。
#!/bin/bash
for i in {1..20}
do
JAVA_HOME/bin/jstack <pid> > thread_dump_$i.txt
sleep 1
done
ThreadLogicなどのスレッド分析ツールの機能の詳細は、適切な製造元のドキュメントを参照してください。
注意: WebLogic Serverがデッドロックやスタック・スレッドを検出すると、関連するスレッド・ダンプが、次の場所にあるサーバーの出力ログ・ファイルに自動的に生成されます。 DOMAIN_NAME\servers\SERVER_NAME\logs\SERVER_NAME.out たとえば、初期設定のアプリケーションであるWebCenter Portalの出力ログは、 出力ファイルはシンプルなテキスト・ファイルで、スレッド情報などの様々なサーバー・メッセージを含みます。 |
WebCenter PortalまたはPortal Frameworkアプリケーションをホストする管理対象サーバーの診断ログ(<managed_server_name>
-diagnostic.log
)でエラー、インシデントおよび警告を見つけます。
アプリケーションがエラー状態で動作している場合は、パフォーマンスに大きな影響を与える可能性があります。たとえば、WebCenter Content Serverへの接続が一時的に止まるかアクセス不能になった場合、接続を試行中に、コンテンツ関連コンポーネントのあるページのレスポンスが非常に遅くなり、最終的にタイムアウトになることがあります。
タイムアウト、サービス使用不可、キャッシュ・エラーなどが原因のエラー、インシデントおよび警告メッセージは、診断ログ・ファイルに記録されます。この診断ログは、Fusion Middleware Controlから表示できます。第28.2.1項「WebCenter Portalログの表示および構成」も参照してください。
注意: パフォーマンスの測定時に、デバッグ/トレース・メッセージ、つまりCONFIG(700)より低いレベルは記録されていないことを確認します。普通、詳細または最も詳細メッセージが表示される場合、システムはデバッグ・モードで動作しています。つまり大部分のリクエストが通常よりかなり遅くなっています。より低いレベルのロギングを一時的に構成して問題をデバッグする場合は、パフォーマンスを測定する前に必ずログ・レベルを変更します。 |
DMS Spyサーブレットを使用すると、Webブラウザから内部DMSメトリック・データにアクセスできます。このサーブレットは、長期間システムをモニターする場合に有用で、内部システムの動作とパフォーマンスの把握に役立ちます。
通常、Oracle WebCenter Portal固有のメトリックのモニターにDMS Spyを使用することはありません。この情報へは、Fusion Middleware Controlを使用するほうがより簡単にアクセスできるためです。ただし、ADFアプリケーション・モジュール(AM)プールに関する警告/エラー・メッセージの表示などの他の主要なメトリックに関心がある場合は、ここでAMプール・メトリックを調査できます。同様に、Javaオブジェクト・キャッシュ(JOC)に関するメッセージが表示される場合は、JOCのDMSモニタリング機能を有効にしてJOC内のアクティビティを観察できます。
JOC DMSモニタリングを有効にするには、javacache.xml
ファイル(通常は<webcenter_portal_domain>/config/fmwconfig/servers/WC_Spaces/javacache.xml
)を編集します。
javacache.xml
ファイルを開きます。
通常、ファイルの場所は、<webcenter_domain>/config/fmwconfig/servers/<server_name>/javacache.xml
です。
たとえばWebCenter Portalの場合、ファイルの場所は、<webcenter_domain>/config/fmwconfig/servers/WC_Spaces/javacache.xml
です。
次のエントリを変更します。
<dms enabled="false"/>
変更後: <dms enabled="true"/>
WebCenter PortalまたはPortal Frameworkアプリケーションがデプロイされている管理対象サーバーを再起動します。
たとえば、WebCenter Portalの場合は、WC_Spacesを再起動します。
有効後は、左のパネルに2つの新しいエントリ(java_cache_regionとjoc)が表示されます。
java_cache_regionは、各領域にどれくらいのキャッシュ・メモリーが割り当てられているかを示します。表示される値は、キャッシュ・サイズ設定の判断に役立ちます。たとえばMDSキャッシュ・サイズは、デフォルトでは、adf-config.xml
内で100MBに設定されています。
<max-size-kb>100000</max-size-kb>
Region Name: ADFApplication<N>とADFApplication<N>/main_regionは、どちらもMDSキャッシュによって使用されます。ADFApplication<N>とADFApplication<N>/main_regionメモリーの合計が100MBに近く、JVMに十分な未使用ヒープ・メモリーがある場合は、MDSキャッシュ・サイズ(<max-size-kb>)を増やすことができるため、MDSキャッシュがいっぱいになることがなく、MDSキャッシュの効率性が向上します。
詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のSpyサーブレットを使用したパフォーマンス・メトリックの表示に関する項を参照してください。
大部分のWebページには、イメージ、CSSファイル、JavaScriptファイルなどの頻繁に変更されないリソースが含まれています。そのようなリソースはネットワーク経由のダウンロードに時間がかかるため、Webページのロード時間が増加します。HTTPキャッシュを使用すると、そのようなリソースをブラウザまたはプロキシで保存またはキャッシュできます。リソースがキャッシュされると、Webページへの次回アクセス時に、ブラウザまたはプロキシはリソースを再度ダウンロードするかわりに、ローカルにキャッシュされたコピーを参照できます。キャッシュでは、必要なリソースに対するHTTPリクエストを削除することにより、ラウンド・トリップ時間を短縮します。これは、次回ユーザー・アクセス時のページ・ロード時間の大幅な短縮に役立つばかりでなく、サイトの帯域幅とホスティングのコストを低減します。
デフォルトでは、WebCenter Portalによって処理される静的リソースは、ADFCachingFilter
を使用して、ブラウザが静的コンテンツをキャッシュできるようにする必須レスポンス・ヘッダーを追加します。サイトでパフォーマンス問題が発生している場合は、ブラウザが静的リソースをキャッシュしていることを確認する必要があります。キャッシュが適切に機能していない場合は、静的なWebCenter Portalリソースは、ブラウザにキャッシュされるのではなくサーバーから繰り返しフェッチされるため、パフォーマンスに影響を与える可能性があります。静的ポータル・リソースのキャッシュ問題の考えられる理由として、WebCenter Portalとブラウザ間に配置されたプロキシまたはネットワーク・コンポーネントによるなんらかの損失の可能性があります。
注意:
|
Firebug (Firefox)またはhttpWatch (Internet ExplorerおよびFirefox)などのHTTPリクエストのモニタリング・ツールを使用して、ブラウザとサーバーとの間のHTTPトラフィックをモニターします。このようなツールを使用すると、キャッシュに問題があるかどうか、つまり静的リソース(JavaScript、CSSファイルなど)がリクエストごとにフェッチされるか、長期間キャッシュされないか、あるいはまったくキャッシュされないかを確認できます。このようなモニタリング・ツールを使用するときは、レスポンス内にブラウザ・キャッシュ関連のタグ(たとえば適切なmax-age
値が設定されたCache-Control
ヘッダーや、適切なキャッシュ有効期間が設定されたExpires
タグ)があることを確認します。
WebCenter PortalまたはPortal Frameworkアプリケーションがデプロイされている管理対象サーバーのaccess.log
を調べて、HTTPキャッシュを分析することもできます。たとえば、ログを参照して、特定のユーザー/IPが同じリソースに対して繰り返しリクエストを行っているかどうかを確認します。繰り返されたリクエストがログに含まれている場合は、リクエストのキャッシュ・ヘッダーが間違っている可能性があり、キャッシュ問題をさらに調査する必要があります。様々な段階を省くために、静的リソースにアクセスすることから始めます。たとえば、wget
またはcurl
コマンドを使用し、ローカル・マシンで同コマンドを発行することにより、WebLogic Serverポートを使用している静的リソースを直接フェッチします。次に、アプリケーションをホストしているWebLogic Serverをフロントエンド処理する他のエンティティ(Oracle HTTP ServerやApacheなど)経由で、同じリソースにアクセスします。必要に応じてパケットのトレースを有効にし、WebCenter Portal層からのレスポンスを見つけて、問題がOracle WebCenter Portal側で発生しているのかネットワークで発生しているのかを確認します。
注意: WebCenter Portalのアクセス・ログは、 |
この項では、WebCenter Portalによって処理される静的リソースについて説明しますので、ご使用の環境の静的リソースに関する同様の問題も検討してください。たとえば、ユーザー独自の静的リソースを共通ページが参照するリッチUIを使用している場合は、そのようなコンテンツがどのようにキャッシュされるかを確認する必要があります。ApacheのHeader
ディレクティブを使用して、ファイル・タイプ(イメージ、CSSなど)またはURLパス・パターンのどちらかを基準に静的リソースのキャッシュを実行することを検討します。たとえばApacheの次の構成では、レスポンス・ヘッダーをブラウザに戻し、URLパス/my_images/
下のすべてのコンテンツを30日間キャッシュします(2592000は、30日を秒数で表した数)。
<Location /my_images/> Header set Cache-Control "max-age=2592000, public" </Location>
HTTPキャッシュに加えて、レスポンスに対するHTTP圧縮の特性を確認することが重要です。HTTP圧縮は、Webサーバーからブラウザに転送されるコンテンツ(大部分はテキスト)を圧縮するための、パブリックに定義された方法です。圧縮により、送信されるバイト数が軽減し、パフォーマンスが向上します。HTTP圧縮では、パブリックなドメイン圧縮アルゴリズムを使用して、サーバー側でHTML、XML、JavaScript、CSSなどのファイル形式をエンコードします。圧縮されたコンテンツを配信する標準ベースのこの方法は、HTTP/1.1に組み込まれており、現在のすべてのWebブラウザではHTTP/1.1プロトコルがサポートされています。つまり、圧縮されたファイルをクライアント側で自動的にデコードすることができます。そのため、クライアント側でソフトウェアの追加やユーザー操作を行う必要はありません。
デフォルトでは、WebCenter Portalによって処理される静的リソースは、ADFCachingFilter ()
を使用して、CSSやJavaScriptなどの静的コンテンツを圧縮します。サイトでパフォーマンス問題が発生している場合は、ブラウザに圧縮されたレスポンスが表示されていることを確認する必要があります。第G.4.2.11項「HTTPリクエストのキャッシュの確認」で説明した、HTTPリクエストのモニタリング・ツールの1つを使用して、値gzip
が設定されたContent-Encoding
レスポンス・ヘッダーのレスポンスをスキャンできます。Content-Encoding
レスポンス・ヘッダーは、クライアント(つまりブラウザ)が圧縮コンテンツをサポートしている場合にかぎり送信されます。
注意:
|
ブラウザがリクエスト・ヘッダーAccept-Encoding: gzip
を送信する場合は、ブラウザは圧縮されたコンテンツを処理できるということです。圧縮されたレスポンスが表示されない場合は、圧縮されたコンテンツを処理できることを示すAccept-Encoding
ヘッダーがクライアントによって送信されることを確認します。
通常圧縮を必要とするファイル形式には、HTML、CSS、XML、JavaScriptがあります。大部分のイメージ、音楽およびビデオはすでに圧縮されているため、圧縮に対応するようにこれらのファイル形式を構成する必要はありません。
Apacheのmod_deflate
またはmod_gzip
を使用して、MIMEタイプ(text/cssなど)またはファイル拡張子(*.htmlなど)のどちらかを基準にリソースの圧縮を実行することを検討します。たとえば、Apacheの圧縮リソースの構成がAddOutputFilterByType
ごとに次のように表示されます。
<Location /> SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/atom_xml AddOutputFilterByType DEFLATE application/x-javascript SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.(?:pdf|doc?x|ppt?x|xls?x)$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary </Location>
Firebug (Firefox)またはhttpWatch (Internet ExplorerおよびFirefox)などのHTTPリクエストのモニタリング・ツールを使用して、ブラウザとサーバーとの間のHTTPトラフィックをモニターします。一般的なユーザー・アクションのHTTPリクエストのフローとタイミングを理解している場合は、アプリケーションのパフォーマンス問題の診断と解決に役立つ可能性があります。たとえばユーザーがログインするたびに、ユーザーのブラウザとサーバー間でいくつかのリダイレクトが発生する可能性があります。ログイン・サーバーに対するリクエストに時間がかかりすぎている場合は、WebLogic Serverではなくログイン・サーバーを調査する必要があることがわかります。同様に、アプリケーションのランディング・ページのロード・リクエストが遅い場合は、ランディング・ページの高速化に取り組むことができます。
なんらかの理由でOracle WebCenter Portalの管理対象サーバーを再起動する場合は、Just-In-Time (JIT)コンパイルのオーバーヘッドを回避するために、必ずシステムをウォーム・アップしてからパフォーマンスを再テストしてください。
システムをウォーム・アップするために、パフォーマンスを後で測定するステップを手動で実行するか、ロード・テスト・ツールを使用してステップの数回の反復を実行することができます。WebLogicの管理対象サーバーを再起動すると、多くの場合、最初のリクエストは通常より遅くなります。つまり、エンド・ユーザーが経験する一般的なパフォーマンスは実現されません。
Fusion Middleware Controlを使用し、WebCenter PortalまたはPortal Frameworkアプリケーションの最も遅いページを判断します。パフォーマンスが低下したページが頻繁に使用される(起動メトリックが高い)場合、そのようなページのパフォーマンスの向上に集中的に取り組むことは意味のあることです。
最も遅いページを見つけるには:
Fusion Middleware Controlにログインし、WebCenter PortalまたはPortal Frameworkアプリケーションのホームページに移動します。
次のいずれかを実行します。
WebCenter Portalの場合: 「WebCenterポータル」メニューから、「モニタリング」→「最近のページ・メトリック」を選択します。
WebCenter Portal Frameworkアプリケーションの場合: 「アプリケーションのデプロイ」メニューから、「WebCenterポータル」→「最近のページ・メトリック」を選択します。
pageResponseTime
しきい値よりレスポンスが遅いページ・リクエストは、ページ上部のグラフに赤色で表示されます。
「時間(ミリ秒)」列の「降順ソート」矢印をクリックして、レスポンス時間を基準にページ・リクエストをソートします。
しきい値を超えたページ・レスポンス時間は、表内にオレンジで表示されます。
最も遅いページを特定し、ページが表示されるポータルを書き留めます。
最も遅いページがリクエストされる頻度など、詳細なメトリックについては、次のいずれかを実行します。
WebCenter Portalの場合: 「WebCenterポータル」メニューから、「モニタリング」→「全ページ・メトリック」を選択します。
注意: ホーム・ポータルにあるページのリクエストは、「全ページ・メトリック」ページから除外されます。
Portal Frameworkアプリケーションの場合: 「アプリケーションのデプロイ」メニューから、「WebCenterポータル」→「全ページ・メトリック」を選択します。
第27.1.5項「ページ・リクエスト・メトリックの理解」および第27.3項「主要なパフォーマンス・メトリックのしきい値および収集のカスタマイズ」も参照してください。
WebCenter PortalのPage Performance Analyzerを使用すると、ポータル・ページに個々のコンポーネントを表示するのにかかった時間、および1つのページを表示するのにかかった全体時間を簡単に確認できます。有効になっている場合、ポータル・ページを表示するたびに、このツールによって、個々のページ・コンポーネントのパフォーマンスが動的に測定および表示されます。
Portal Page Performance Analyzerは、第1レベルのパフォーマンス分析を実行する開発者、独自のページを構築する顧客、およびWebCenter Portalでページをカスタマイズするユーザーにとって有用な機能です。
この項には次のサブセクションが含まれます:
Portal Page Analyzerでは、表示の遅いページの診断を簡単に、かつ最小限の設定と構成で行えます。この機能が有効な場合、上位レベルのページ・コンポーネントの表示に要した時間が計算されて表示されるため、どのコンポーネントがページ表示の遅れの原因になっているかを一目で確認できます。ページの表示に要した全体時間も、ページの左上に表示されます(図G-8を参照)。
ページ・コンポーネントのタイミングについて
WebCenter Portalでは、上位レベルのページ・コンポーネントがShowDetailFrameで囲まれているため、これらのコンポーネントを移動したり、ページ上で表示または非表示にしたり、Oracle コンポーザで編集することができます。ここで表示されるのは、各ShowDetailFrameの全体時間です。
ページの全体時間について
ページの全体時間は、個々のページ・コンポーネントのタイミングの合計に、セッション・レプリケーション、ページ状態の保存およびリストア、ページ・レベルのセキュリティ・チェックなど、ページ・レベルの各操作の処理時間を加えたものです。
カラー・コーディング
問題領域への注意を喚起するため、パフォーマンス・タイミングは様々な色で表示されます。次の表を参照してください。
色 | 表示時間 |
---|---|
緑 |
< 100ミリ秒 |
緑/黄 |
100 - 500ミリ秒 |
黄 |
500ミリ秒 - 1秒 |
オレンジ |
1 - 3秒 |
赤 |
> 3秒 |
Portal Page Performance Analyzerは、初期状態では無効です。この機能を使用するには、管理者がその使用を明示的に有効化する必要があります。このツールを実行することによるページ・パフォーマンスへの影響は最小限ですが、いくつかの追加のページ処理が必要になります。
本番環境では、追加のパフォーマンス・データ収集と処理が行われないように、通常はAnalyzerを無効化しておいて、特定のページのパフォーマンスの問題が報告されたときに動的に有効化することをお薦めします。
Analyzerをほとんどの時間、無効にする別の理由として、本番環境のパフォーマンス・データがエンド・ユーザーに対して非表示になることがあげられます。
WebCenter PortalインスタンスのPortal Page Analyzerを有効化または無効化するには:
WLSTコマンドexportMetadata
を使用して、MDSからwebcenter-config.xml
ベース・ファイルをエクスポートします。
例:
exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/tmp/mydata', docs='/oracle/webcenter/webcenterapp/metadata/webcenter-config.xml')
MDSからエクスポートされたwebcenter-config.xml
をテキスト・エディタで開いて、perfdebug-enabled
属性をtrue
またはfalse
に設定して、この機能を有効化または無効化します。
例:
<webcenter:perfdebug-enabled>true</webcenter:perfdebug-enabled>
webcenter-config.xml
を保存して閉じます。
更新したwebcenter-config.xml
ファイルをMDSにインポートします。
例:
importMetadata(application='webcenter', server='WC_Spaces', fromLocation='/tmp/mydata', docs='/oracle/webcenter/webcenterapp/metadata/webcenter-config.xml')
この変更を反映するのにWebCenter Portalの再起動は不要です。
この機能を有効化しても、ページ・パフォーマンス情報は自動的には表示されません。ポータル・ページにタイミング情報を表示する場合は、その情報の表示を明示的にリクエストする必要があります。詳細は、第G.4.4.3項「現在のセッションのページ・タイミング情報の表示および非表示」を参照してください。
管理者がWebCenter PortalインスタンスでPage Performance Analyzerを有効化すると、そのWebCenter Portalインスタンスにアクセスできるすべてのユーザーは、次のようにページURLにperfDebug
パラメータを追加することで、現在のユーザー・セッションでページ・タイミング情報を表示するか、非表示にするかを指定できます。
目的 | ページURLへのperfDebugパラメータの追加 |
---|---|
ポータル・ページでのタイミング情報の表示 |
|
ページ・パフォーマンス情報の表示の中止 |
|
ポータル・ページでタイミング情報を表示するには:
管理者が、WebCenter PortalインスタンスでPage Performance Analyzerを有効化していることを確認します。
第G.4.4.2項「ポータル・ページのパフォーマンス分析の有効化および無効化」も参照してください。
WebCenter Portalにログインし、調査対象のポータル・ページに移動します。
このページがパブリック・ページである場合は、ログインする必要はありません。
ページURL (図G-9)の最後に&perfDebug=on
を追加します。
例:
http://mycompany.com/webcenter/portal/MySalesPortal?_adf.ctrl-state=mji8314i6_4&_afrLoop=474789135539036&perfDebug=on
「実行」をクリックするか、[Enter]を押して、タイミング情報ありでページを再表示します(図G-8)。
それ以降に表示するすべてのページでもタイミング情報が示されます。
ページ・タイミング情報の表示を中止するには:
ブラウザで、ページURL (図G-9)の最後に&perfDebug=on
を追加します。
例:
http://mycompany.com/webcenter/portal/MySalesPortal?_adf.ctrl-state=mji8314i6_4&_afrLoop=474789135539036&perfDebug=off
「実行」をクリックするか、[Enter]を押して、タイミング情報なしでページを再表示します。
この項の手順では、WebCenter Portalの各ツールを使用して、表示の遅いページをトラブルシューティングする方法について説明します。
ユーザーにより、特定のページのパフォーマンスの問題が報告された場合は、表示の遅いページに移動して、パフォーマンス低下がいつも発生することを確認してください。
または、Fusion Middleware Controlを使用して、アプリケーション内の表示が一番遅いページをプロアクティブに特定します。第G.4.3項「表示の遅いページを特定する方法」を参照してください。
ページURLに&perfDebug=on
を追加して、そのページのタイミング情報を表示します。
第G.4.4.3項「現在のセッションのページ・タイミング情報の表示および非表示」も参照してください。
注意: ページ・タイミング情報が表示されない場合は、管理者にPage Performance Analyzerの有効化を依頼してください。詳細は、第G.4.4.2項「ポータル・ページのパフォーマンス分析の有効化および無効化」を参照してください。 |
表示が一番遅いページ・コンポーネントを特定し、さらに問題をトラブルシューティングします。
たとえば、表示が遅いコンポーネントに次のものが含まれる場合、
ドキュメント、wikiまたはコンテンツ・プレゼンタ: バックエンドContent ServerのパフォーマンスとContent Serverが使用するデータベースをチェックします。
アクティビティ・ストリーム: AWRレポートを使用してデータベース・パフォーマンスをチェックし、アクティビティ・ストリームによって使用されているデータベース表をチューニングできるかどうかを調べます。
コラボレーション機能: 関連付けられたバックエンド・サーバーのパフォーマンスをチェックします。たとえば、お知らせまたはディスカッションの場合、ディスカッション・サーバーのパフォーマンスをモニターします。
ポートレット: Fusion Middleware Controlを使用して、ポートレット・リクエストのタイミング情報、エラー、ポートレット・プロデューサのパフォーマンスなどをモニターします。
必要に応じて、表示の遅いページ・コンポーネントを別の空白ページに追加して、さらにプロファイリングを行います。
たとえば、JRockitフライト記録を使用してボトルネックを特定します。
Page Performance Analyzerは、WebCenter Portal 11.1.1.8.0以降で作成したポータル・ページで最適に機能します。それより前のリリースでは、一部のページ・テンプレートにコンポーネントの時間とページの全体時間の表示に必要なタグが含まれていなかったり、一部のタスク・フローにactivation=deferred
が構成されていませんでした。
この項の情報を使用して、ページ・パフォーマンスの低下に関連する問題を診断します。
実行中の遅いページ・リクエストをトラブルシューティングするには、ユーザー・セッションが動作しているサーバーに対するJRockit Flight Recorder(JFR)レコードを抽出および表示します。第G.4.6項「JRockitフライト記録を使用してリクエストをトラブルシューティングする方法」も参照してください。
または、第G.4.2.8項「表示が非常に遅いページのパフォーマンス、高スレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成」で説明されているように、等間隔のいくつかのスレッド・ダンプをたとえば1、2秒ごとに採取します。
スレッド・ダンプを比較すると、特定のメソッド・コールに長時間を費やしたスレッドに気付く場合があります。これは、いくつかの連続したスレッド・ダンプ内のコール・スタックが同じであるためです。たとえば、データベース、Oracle WebCenter Content Server、コラボレーション・サーバー、ポートレット・プロデューサ、LDAPサーバーなどに対するメソッド・コールが存在することがあります。この場合は、関連するバックエンド・サーバーを調査して、問題を詳細に診断することができます。
スタック・スレッドは、次のようないくつかの理由で発生することがあります。
サーバーがもう少しでメモリー不足になります。サーバーがメモリー不足状態に近づくと、すべてのリクエストが遅くなります。メモリー不足問題を解決するには、第G.4.5.3項「JFR記録を使用した遅いリクエストのトラブルシューティング」を参照してください。
デッドロック・スレッド。スレッド・ダンプを採取し、デッドロック・スレッドを検索します。これにより、通常、製品コードの問題が明らかになります。
極度に遅いページ・リクエスト。等間隔のいくつかのスレッド・ダンプを採取し、実行に時間のかかっているメソッドを見つけます。
リクエストにかかる時間が10分を超える場合は、スタック・スレッドが、次のディレクトリにあるOracle WebLogic Serverのserver_name
.out
に報告されます。
(UNIX) DOMAIN_HOME/servers/server_name/logs (Windows) DOMAIN_HOME\servers\server_name\logs
例:
<Mar 4, 2012 7:44:08 AM PST> <Error> <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "600" seconds working on the request "weblogic.servlet.internal.ServletRequestImpl@18986012[ GET /server_name/faces/PimDashboardUiShellPage?_afrLoop=1398820150000&_afrWindowMod e=0&_adf.ctrl-state=a44e7uxcc_13 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: fr UA-CPU: x86 ... ]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds . Stack trace: Thread-164 "[STUCK] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'" <alive, in native, suspended, priority=1, DAEMON> { jrockit.net.SocketNativeIO.readBytesPinned(SocketNativeIO.java:???) jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:24) java.net.SocketInputStream.socketRead0(SocketInputStream.java:???) java.net.SocketInputStream.read(SocketInputStream.java:107) ...
スタック・スレッドの診断
スレッドが別のサーバーからのレスポンスを待機していることをスタックが示す場合は、他のサーバーのステータスを確認し、次のステップに進む前に、サーバーにパフォーマンス上の問題がないかどうかを調べます。
スタック・スレッドが、スタックされる前に行っていたことを判断するには、次のステップを実行します。
server_name
.out
にある次のいくつかのログ・メッセージで、インシデントが作成されたことを示すメッセージを確認します。例:
<Mar 4, 2012 7:44:10 AM PST> <Alert> <Diagnostics> <BEA-320016>
<Creating diagnostic image in DOMAIN_HOME/servers
/server_name/adr/diag/ofm/MyDomain/
server_name_1/incident/incdir_394 with a lockout minute
period of 1.>
前述のメッセージは、各スタック・スレッドが報告された後に必ず表示されるとはかぎりません。出力されるのは、1時間に最大でも4回です。メッセージが表示されない場合は、次のディレクトリの下のサブディレクトリにあるreadme
ファイルを確認して、手動でincident
ディレクトリを見つけてください。
(UNIX) DOMAIN_HOME/servers/server_name/adr/diag/ofm/domain_name/server_name/incident (Windows) DOMAIN_HOME\servers\server_name\adr\diag\ofm\domain_name\server_name\incident
incidentディレクトリには、JFR記録を含むWLDF診断イメージとスレッド・ダンプを含むファイルがあります。
インシデントの診断の詳細は、『Oracle Fusion Middleware管理者ガイド』の「問題の診断」を参照してください。
スレッド・ダンプを確認して、スレッドのコール・スタックを見つけます。スレッドがブロックされロックを待機中の場合は、ロックを保持しているスレッドが何を実行しているかを確認します。
JDBCコールに長時間を要していることをコール・スタックが示す場合は、データベースにAWRレポートを生成し、問合せと検索および調整する表を見つけます。
JRockitフライト記録ファイルJRockitFlightRecorder.jfr
で詳細を確認します。さらに、incidentディレクトリのreadme.txt
ファイルに記録されるリクエストのECIDと、Oracle WebLogic Serverログも必要になります。
スタック・スレッドの原因となったリクエストのECIDは、エラー・メッセージに記録されます。
WebCenter PortalまたはPortal Frameworkアプリケーションのパフォーマンスが徐々に低下し、ヒープ使用量とガベージ・コレクション・アクティビティが増加しており、さらにOutOfMemoryErrors
が表示される場合は、アプリケーション内でメモリー・リークが発生し、JVMの空きメモリー容量が連続して減少する可能性があります。
図G-10は、JConsoleに表示される一般的なメモリー・リークの傾向を示しています。
この問題を解決するには:
OutOfMemoryErrors
エラーの原因を判断します。
server_name.out
ファイルで、OutOfMemoryErrors
エラーを確認します。
server_name.out
ファイルは、次の場所にあります。
(UNIX) DOMAIN_HOME/servers/server_name/logs (Windows) DOMAIN_HOME\servers\server_name\logs
OutOfMemoryErrors
エラーが発生したときに、メモリー・ダンプを採取します。
例:
Sun HotSpotの場合: jmap -dump:live,format=b,file=<path>/heap.hprof <pid>
JRockitの場合: jrcmd <pid> hprofdump filename=<path>/heap.hprof
OutOfMemoryErrors
が発生するたびに、HPROFバイナリ形式(.hprof
ファイル)で自動的にヒープ・ダンプを生成するようにJRockitを構成できます。構成するには、JRockit JVMオプション-XX:+HeapDumpOnOutOfMemoryError
を設定します。詳細は、Oracle JRockitコマンド行リファレンスを参照してください。
管理対象サーバーを再起動します。
問題が解決しない場合は、ステップ3に進みます。
HPROF
バイナリ形式を処理できるヒープ・ダンプ分析ツール(Eclipse Memory Analyzerなど)で、heap.hprof
ファイルを開きます。
大部分のメモリーを保持しているオブジェクトとクラスを判断します。
必要に応じて、いくつかのヒープ・ダンプを採取し、メモリーを消費および増加させているオブジェクトまたはクラスを判断します。
少なくとも2つのメモリー・ダンプを採取します。
システムがウォーム・アップし安定したときに、1番目のダンプを採取します。
システムのメモリーが不足しつつあるとき、つまり完全ガベージ・コレクションによって最大ヒープ・サイズから取得されるのが300MB未満になったときに、2番目のダンプを採取します。
Sun HotSpot(jmap
)またはJRockit(jcrcmd
)を使用してヒープ・ダンプを採取する手順は、ステップ1で説明しています。
Oracle JRockit JDKツール・ガイドの「診断コマンドの実行」を参照してください。Eclipse Memory Analyzerなどの多くのメモリー・ヒープ・ダンプ分析ツールを使用すると、2つのヒープ・ダンプを比較してメモリー増加領域を特定できます。
ヒープ・ダンプは、メモリーが保持される(保持ヒープ)原因に関する情報を提供します。メモリーの割当て方法を知り、問題のさらなる解決が必要になる場合があります。このような場合は、ステップ6に進みます。
JRockit Mission Control Clientに属するJRockit Memory Leak Detectorツールを使用して、メモリーの割当て方法を理解します。
詳細は、JRockit Mission Controlのオンライン・ヘルプを参照してください。
ページ・パフォーマンスが遅い原因がコンテンツ/ドキュメント関連のコンポーネント、たとえばドキュメント・サービス・タスク・フロー、コンテンツ・プレゼンタ・タスク・フロー、Wikiまたはブログの場合は、バックエンドOracle WebCenter Content Server(「システム監査情報」ページ)のパフォーマンス・メトリックを参照することをお薦めします。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のシステム監査情報の表示に関する項を参照してください。
データベースに送信される問合せごとにパフォーマンス情報を確認できるように、systemdatabaseトレース・オプションが選択されていることを確認します。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のサーバー全体のトレースに関する項を参照してください。
JRockit Flight Recorder(JFR)ファイルには、時間を費やす様々なイベントの記録が含まれています。リクエストが遅い場合は、JRockit Flight Recorder(JFR)ファイルを分析して、リクエストに時間のかかる原因を探ることができます。
JFRファイルを作成するには:
次のコマンドを実行して、Oracle WebLogic ServerからJFRファイルを抽出します。
UNIX) JROCKIT_HOME/bin/jrcmd jrockit_pid dump_flightrecording recording=1 copy_to_file=path compress_copy=true (Windows) JROCKIT_HOME\bin\jrcmd.exe jrockit_pid dump_flightrecording recording=1 copy_to_file=path compress_copy=true
jrcmd
コマンド行ツールの詳細は、Oracle JRockit JDKツール・ガイドの診断コマンドの実行に関する項を参照してください。
ファイルを表示するには、次のディレクトリからJRockit Mission Control Clientを開始します。
(UNIX) JAVA_HOME/bin/bin/jrmc (Windows) JAVA_HOME\bin\jrmc.exe
「ファイル」→「ファイルを開く」を選択して、JFRファイルを選択します。
最も遅いリクエストを見つけるか、特定のリクエストを調査します。
最も遅いリクエストを特定するには: | 特定のリクエストを調査するには: |
---|---|
|
|
開始時間とリクエストを処理したスレッドを特定したら、「ログ」タブに移動し、リクエストの期間の時間枠のみを含めるように、画面上部の時間セレクタをドラッグします。
「イベント・ログ」セクションで、次のように検索を実行します。
「操作セットのみ表示」の選択を解除します。
検索ボックスにスレッド名を入力します。
「列のフィルタ処理」リストから、「スレッド」を選択します。
[Enter]を選択します。
左側の「イベント・タイプ」ナビゲーション・ペインで、目的のイベントをクリックします。通常これらのイベントは、「ダイナミック・モニタリング・システム」、「Javaアプリケーション」、および「WebLogic」→「JDBC」の下にあります。
選択済イベントは、「イベント・ログ」セクションの表に表示されます。
「開始時間」列をクリックして、これらのイベントが発生した時間をソートするか、「期間」列をクリックして最も時間のかかったイベントを表示します。
「JDBC文実行」イベントは、SQL実行に対応しています。遅いSQL文がある場合は、イベントの詳細にSQLテキストが表示されます。これらのイベントには、コール・スタックはありません。
遅いSQL文のコール・スタックを確認するには、「JDBC文実行」イベント直後に発生した「ソケット読取り」イベントを表示します。
このイベントは、SQL結果が返されるのを待機しているOracle WebLogic Serverに対応し、イベントの詳細にコール・スタックが含まれています。
長い「Javaブロック」および「Java待機」イベントのコール・スタックを参照し、パフォーマンス低下の原因を特定できるかどうかを確認します。
Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用のJRockit Mission ControlのFlight Recorderデータの分析に関する項を参照してください。
デフォルトのレコードで取得されるものより詳細な情報が必要であり、遅いリクエストを再現できる場合は、明示的なレコードを開始できます。
Oracle JRockit Flight Recorderランタイム・ガイドの明示的なレコードの開始に関する項を参照してください。
My Oracle Support(以前はMetaLink)を使用して、Oracle WebCenter Portal問題を解決することができます。My Oracle Supportには、次のような有用なトラブルシューティング・リソースが含まれています。
ナレッジ・ベース記事
コミュニティのフォーラムとディスカッション
パッチとアップグレード
動作保証情報
注意: My Oracle Supportを使用して、サービス・リクエストを記録することもできます。 |
My Oracle Supportには、https://support.oracle.com
からアクセスできます。
WebCenter Portalワークフローで問題が発生する場合、次の項を参照してください。
『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』には、WebCenter Portalワークフローのインストール方法と構成方法が記載されています。詳細は、WebCenter Portalワークフローのバックエンド要件に関する項を参照してください。ワークフローの構成は、次のように検証できます。
WebCenter Portalにログインします。
ポータルを作成し、「メンバー」タブに移動します(「管理」リンク→「セキュリティ」→「メンバー」をクリックします)。
任意のロールを持つ新しいメンバー(たとえば、User2
)を招待します。
ログアウトした後、User2
としてログインします。
「ワークリスト」タスク・フローに移動します。
招待通知を開いて、「承認」ボタンをクリックします。
ポータルを開きます。
WebCenter Portalワークフローが正常に機能している場合は、新しく作成したポータルをUser2
が使用できます。ポータルが使用できない場合やリストされていない場合は、その構成に問題があります。
WebCenter Portalワークフローが正常に機能していない場合は、次の手順で問題をトラブルシューティングします。
次の手順で、WebCenter PortalワークフローがOracle SOAサーバーにデプロイされていることを確認します。
Fusion Middleware Controlにログインします。
WebCenterWorklistDetailApp.ear
がデプロイされていることを確認します。
sca_CommunityWorkflows.jar
がデプロイされていることを確認します。
詳細は、『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』のOracle SOA Server - ドメインの拡張に関する項を参照してください。
次の手順で、Oracle SOAサーバーとWebCenter Portalアプリケーション間のWebサービス接続がセキュアであることを確認します。
Oracle SOAサーバーのキーストア・ファイル内の別名をチェックします。
たとえば、次のコマンドを使用して、Oracle SOAサーバーのキーストア・ファイルの内容をリストします。
keytool -list -v -keystore bpel.jks -storepass <password>
次の内容のエントリがあるはずです。
Alias name: webcenter_portals_ws
『Oracle Fusion Middleware Oracle WebCenter Portalインストレーション・ガイド』のSOAドメインの設定に関する項を参照してください。
WebCenter PortalとOracle SOAサーバーの資格証明ストアが、両方とも正しく構成されていることを確認します。
接続の両端に、次のようなキーストアが存在することを確認します。
- webcenter.jks
(WebCenter Portalサーバー側にコピーされる)
- bpel.jks
(Oracle SOAサーバー側にコピーされる)
たとえば、次のコマンドでwebcenter.jks
およびbpel.jks
が生成されます。
keytool -genkeypair -keyalg RSA -dname "cn=webcenter,dc=us,dc=oracle,dc=com" -alias webcenter -keypass mypassword -keystore webcenter.jks -storepass mypassword -validity 360
keytool -exportcert -v -alias webcenter -keystore webcenter.jks -storepass mypassword -rfc -file webcenter.cer
keytool -importcert -alias webcenter_spaces_ws -file webcenter.cer -keystore bpel.jks -storepass mypassword
keytool -genkeypair -keyalg RSA -dname "cn=bpel,dc=us,dc=oracle,dc=com" -alias bpel -keypass mypassword -keystore bpel.jks -storepass mypassword -validity 360
keytool -exportcert -v -alias bpel -keystore bpel.jks -storepass mypassword -rfc -file bpel.cer
keytool -importcert -alias bpel -file bpel.cer -keystore webcenter.jks -storepass mypassword
『Oracle Fusion Middleware Oracle WebCenter Portalの管理』の「SOAドメイン・キーストアの作成」を参照してください。
Oracle SOAサーバー(soa-infra
)で、BPMWorkflowAdmin
アプリケーション・ロールのロール・メンバーを構成します。
weblogic
ユーザーを含まないアイデンティティ・ストアにドメインを関連付ける場合は、それ以外の有効なユーザーをアプリケーション・ロールBPMWorkflowAdmin
に割り当てる必要があります。この作業は、SOA OracleホームからWLSTコマンドを使用して実行します。たとえば、LDAPに存在するmontyという名前のユーザーを割り当てるには、次のように実行します。
cd $SOA_ORACLE_HOME/common/bin/ wlst.sh connect('<admin username>','<admin password>', 'mysoahost.example.com:7001') revokeAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="oracle.security.jps.service.policystore.ApplicationRole", principalName="SOAAdmin") grantAppRole(appStripe="soa-infra", appRoleName="BPMWorkflowAdmin", principalClass="weblogic.security.principal.WLSUserImpl", principalName="monty")
『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTセキュリティ・コマンドの概要に関する項を参照してください。
この項には次のサブセクションが含まれます:
問題
すべてのポータルまたはWebCenter Portalインスタンス全体をエクスポートしようとすると、次のResourceLimitException
エラーが表示されます。
Weblogic.common.resourcepool.ResourceLimitException
解決策
JDBC接続プールで最大容量を増加します。接続プールを再構成するには、WLS管理コンソールにログインします。「サービス」から、「データ・ソース」、「WebCenterDS」、「接続プール」タブを選択します。
問題
WebCenter Portalインスタンス全体またはポータルをインポートまたはエクスポートしようとすると、次のようなLockRefreshTask
警告が表示されます。
[WARNING] [][oracle.webcenter.lifecycle.operation.LockRefreshTask]
インポートまたはエクスポート操作を再度試行すると、次のようなエラーが表示されます。
Starting WebCenter Portal application import...
WebCenter Portal application import started.
Error occurred while performing import
None
Check the WebCenter Portal log files for additional details.
Unable to contact MBeanServer for
oracle.webcenter.lifecycle:ApplicationName=webcenter,Location=WC_Spaces,name=Lifec
ycleManager,type=LifecycleManager,Application=webcenter,ApplicationVersion=11.1.1.
4.0
Error occurred while destroying MBean
The lock hasnt been released from the previous failed import.
解決策
予期しない異常なインポートまたはエクスポート操作の失敗が原因で作成され、破棄されなかったMDSの不要なロックをdeleteMetadata
WLSTコマンドを使用して削除します。失敗した操作に応じて、次のいずれかのコマンドを実行します。
WebCenter Portalアプリケーションのインポートに失敗した場合、次のコマンドを実行します。
deleteMetadata(application='webcenter', server='WC_Spaces', docs='/oracle/webcenter/lock/applicationImport/applicationImport.xml')
WebCenter Portalアプリケーションのエクスポートに失敗した場合、次のコマンドを実行します。
deleteMetadata(application='webcenter', server='WC_Spaces', docs='/oracle/webcenter/lock/applicationExport/applicationExport.xml')
ポータルのインポートに失敗した場合、次のコマンドを実行します。
deleteMetadata(application='webcenter', server='WC_Spaces', docs='/oracle/webcenter/lock/scopeImport/**')
ポータルのエクスポートに失敗した場合、次のコマンドを実行します。
deleteMetadata(application='webcenter', server='WC_Spaces', docs='/oracle/webcenter/lock/gsExportImport/**')
問題
インポート操作後にWebCenter Portalに最初にログインすると、移行したポータルおよびポータル・テンプレートが予期したとおりに使用できません。これは、ポータルまたはポータル・テンプレート・キャッシュが適切にリフレッシュできない場合に発生することがあります。
解決策
refreshGroupSpaceCache
およびrefreshSpaceTemplateCache
WLSTコマンドを使用して、ポータルまたはポータル・テンプレート・キャッシュを手動でリフレッシュします。
キャッシュ(すべてのポータル)を完全にクリアするには:
refreshGroupSpaceCache(appName='webcenter', spaceNames='', syncMode=1,updateType='all', cleanCache=1)
キャッシュ(すべてのポータル・テンプレート)を完全にクリアするには:
refreshSpaceTemplateCache(appName='webcenter', spaceTemplateNames='',syncMode=1, updateType='all', cleanCache=1)
コマンド構文の詳細と例は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のrefreshGroupSpaceCacheに関する項およびrefreshSpaceTemplateCacheに関する項を参照してください。
WLSTコマンドの実行方法の詳細は、第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」を参照してください。
同じContent Serverを共有している2つの異なるWebCenter Portalインスタンス間でポータルまたはポータル・テンプレートを移行できません。
この項には次のサブセクションが含まれます:
ポータルのエクスポートまたはインポート操作時にエラーが発生した場合は、一部のポータルがブロックされている可能性があります。ポータルのブロックを解除するには、一時的にポータルをオンラインの状態に戻してから、再度オフラインの状態にし、エクスポートまたはインポート操作を実行してください。オンライン・モードとオフライン・モードを切り替えることにより、ポータルのブロックが解除されます。詳細は、第46.11項「任意のポータルのオフライン化」および第46.12項「任意のポータルの再オンライン化」を参照してください。『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドsetSpaceState
も参照してください。
インポート操作後に初めてWebCenter Portalにログインするときに、最後にアクセスしたページまたはポータルが存在しない場合、「ページが見つかりません」または「ポータルが見つかりません」というメッセージが表示される場合があります。最後にアクセスしたページの情報はインポート操作中に保持されるため、このようなメッセージが表示されることがあります。
問題
WebCenter Portalにコンテンツをアップロードするには、ファイル・サイズ制限があります。エクスポートのアーカイブが最大アップロード・サイズを超える場合、WebCenter Portal管理からのインポート操作が失敗します。
解決策
WLSTを使用してポータル・アーカイブをインポートします。詳細は、第40.1.2.4.3項「WLSTを使用したポータルのアーカイブからのインポート」を参照してください。
または、webcenter-config.xml
の最大アップロード・サイズを変更します。デフォルトの最大アップロード・サイズは2GBです。第9.12項「最大ファイル・アップロード・サイズの変更」を参照してください。
問題
エクスポートできるポータルの最大数は、MDSデータ・ソースに対して指定する接続プール・サイズの80%以下である必要があります。エクスポートしようとするポータルの数が多すぎると、次のResourceLimitException
エラーが表示される場合があります。
Weblogic.common.resourcepool.ResourceLimitException
解決策
エクスポートするポータルの数を減らします。または、接続プールの設定を変更します。詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。
問題
リストが、ソースおよびターゲット・システムのリスト定義の相違により、適切にインポートされていません。
解決策
リスト・データをエクスポートおよびインポートすることを検討してください。これにより、リスト・データがインポートされるリスト定義と一貫性を持つようになります。
データなしにインポートする場合は、ターゲット・システムのリスト・データはインポートされたリスト定義と一貫性を持つように移行されます。リスト列データ・タイプが変更される場合、可能な場合は、列の値はターゲット・データ・タイプからインポートされたデータ・タイプに変換されます。リスト列がインポート時に削除される場合、列の値は削除されます。
問題
ツールとサービスが構成されているポータルをエクスポートし、これらのツールやサービスの一部またはすべてが構成されていないインスタンスから同じポータルをインポートしようとすると、次のエラー・メッセージが表示されます。
The following services are not configured: <list of tools and services>. Please configure these services and try again.
解決策
ツールとサービスをターゲットに追加するか、または次に示すアーカイブのdata.xml
ファイルからサービス関連の情報を削除して、この問題を解決することができます。
サービス関連の情報を削除する操作は、次のとおりです。
アーカイブを抽出します。
アーカイブには、2つのファイル(policy-store.xml
およびtransport.mar
)が含まれます。
ディレクトリにtransport.mar
を展開します。
data.xmlファイルは、oracle\webcenter\lifecycle\importexport
ディレクトリにあります。
エラー・メッセージでリストされるターゲットに存在しないすべてのツールとサービスのサービス・タグを削除します。
前述のエラー・メッセージ例では、次を削除する必要があります。
<service id="oracle.webcenter.collab.forum" version="11.1.1.0"> <metadataUsages> <metadataUsage includeBaseDocuments="YES" includeSystemCustomizations="YES"> <paths> <include path="/oracle/webcenter/collab/forum/scopedMD/s516227ec_dde1_4991_9e18_28d487cb3bce/**"/> </paths> </metadataUsage> </metadataUsages> </service> <service id="oracle.webcenter.collab.rtc" version="11.1.1.0"/>
トップレベルのディレクトリOracle
およびpagedefs
をtransport.mar
という名前のファイルに圧縮することにより、transport.mar
をリパックします。
新しく作成したtransport.marおよびpolicy-store.xml
ファイルをアーカイブに圧縮することにより、export
アーカイブをリパックします。
新しいアーカイブをインポートします。
問題
ポータルのインポート後に、ポータル管理で直接「ツールとサービス」タブに移動すると、ソース・ポータルで有効化されている場合でも、すべてのツールとサービスが無効化されます。
これは、インポートするアーカイブに、WebCenter Portal 11.1.1.8より前のリリースからエクスポートされたポータルが含まれる際に発生する場合があります。
解決策
必要に応じて、ツールとサービス用の「有効化」チェック・ボックスを選択します。
または、インポート後にポータル管理に移動するかわりに、ポータルを開きます。ポータルに初めてアクセスするときに、ツールとサービスが自動的に有効化されます。
問題
「ポータル」ページからポータルをインポートする場合、インポートしたポータルが現在のポータルのサブポータルに自動的になることはありません。新たにインポートされたポータルは、「ポータル」スイッチャ・メニュー、ポータル・ブラウザ・タスク・フローまたは「ポータル」ページに表示されます。これらは、使用可能なすべてのポータルを表示しています。
解決策
アーカイブをインポートする前に「ポータル」ページで親ポータルを選択すると、サブポータルとしてポータルをインポートできます。
同じContent Serverを共有している2つの異なるWebCenter Portalアプリケーション間でポータルまたはポータル・テンプレートをエクスポート/インポートできません。
同様に、同じContent Serverを共有している2つの異なるWebCenter Portalアプリケーション間でドキュメント移行ユーティリティを使用してポータル・ドキュメントを移行できません。
問題
Linuxでは、名前付け制限により、マルチバイト言語で作成された1つ以上のポータルに対して、個々のポータルのエクスポートまたはインポートが失敗します。ポータル名は、英数字およびポータル文字("a" - "z"、"A" - "Z"、"0" - "9"、およびWebCenter Portalが"_"(アンダースコア)で置き換えるシングルバイト・ポータル文字)に制限されます。他の文字がポータル名で使用される場合、エクスポートまたはインポートは失敗します。
解決策
Oracle WebCenter Portalがデプロイされるサーバー上で名前付け制限を強制します。これを行うには、環境変数LC_ALL
をutf-8
に設定します。