| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Portal管理者ガイド 11g リリース1 (11.1.1.7.0) B72085-02 |
|
前 |
次 |
この付録には、次のようなトラブルシューティング情報が記載されています。
このドキュメントのロードマップを使用して、Oracle WebCenter Portalのトラブルシューティング情報を参照します。図D-1で、問題を最もよく示す開始点を見つけ図形をクリックするか、表D-1のリンクをクリックして、必要な項に移動します。
表D-1 WebCenter Portalのトラブルシューティングの開始点
| 実行する処理 | ガイド内のトラブルシューティングの項へのリンク |
|---|---|
|
第D.2項「WebCenter Portalの構成に関する問題のトラブルシューティング」 |
|
第D.3項「WebCenter Portal WLSTコマンドの問題のトラブルシューティング」 |
|
第39項「Oracle WebCenter Portalのパフォーマンスの監視」 |
|
第D.4項「WebCenter Portalのパフォーマンスに関する問題のトラブルシューティング」 |
ご使用の環境にインストールされているWebCenter Portalの製品およびコンポーネントのバージョン情報を入手するには、必ずOracleのOPatchユーティリティを使用します。
lsinventoryオプションを指定してOPatchコマンドを実行するには:
Opatch環境変数のWC_ORACLE_HOME、MW_HOMEおよびPATHを設定します。
『Oracle Fusion Middlewareパッチ適用ガイド』のOPatch環境変数に関する項も参照してください。
次のOPatchコマンドを実行します。
opatch lsinventory -details
次のように、インストールされているコンポーネントとそのバージョン番号のリストが出力されます。
Oracle Upgrade Assistant for Webcenter 11.1.1.7.0 Oracle WebCenter Portal Suite 11.1.1.7.0 Oracle WebCenter Portal Suite 11g 11.1.1.7.0 Oracle WebCenter Portal: Activity Graph 11.1.1.7.0 Oracle WebCenter Portal: Analytics Collector 11.1.1.7.0 Oracle WebCenter Portal: Discussions Server 11.1.1.7.0 Oracle Webcenter Portal: Framework 11.1.1.7.0 Oracle Webcenter Portal: Framework Core 11.1.1.7.0 Oracle WebCenter Portal: Pagelet Producers 11.1.1.7.0 Oracle WebCenter Portal: Personalization 11.1.1.7.0 Oracle Webcenter Portal: Portlet Server 11.1.1.7.0 Oracle WebCenter Portal: RCU 11.1.1.7.0 Oracle Webcenter Portal: Spaces 11.1.1.7.0 Oracle WebCenter Portal: Suite Components 11.1.1.7.0 Oracle WebCenter Portal: Wiki 11.1.1.7.0 Oracle WebLogic Communications Service Client Library 11.1.1.7.0
|
注意:
|
『Oracle Fusion Middlewareパッチ適用ガイド』のOPatchの概要に関する項と、Oracle Universal InstallerおよびOPatchユーザーズ・ガイド(WindowsおよびUNIX向け)のスタンドアロンOPatchのLsinventoryコマンドに関する項も参照してください。
|
注意: バージョン番号を入手するには、必ずOPatchを使用してください。Fusion Middleware ControlでWebCenter Portal製品およびコンポーネント名とともに表示されるバージョンは、インストールされている製品の実際のバージョン番号と一致していません。次に例を示します。   |
問題
Fusion Middleware Controlにログインした後、使用しているアプリケーションの「アプリケーションのデプロイ」メニューで、「WebCenterポータル」オプションが見つかりません。
解決策
次のことを確認します。
デプロイ済アプリケーションは、JDeveloperでWebCenter Portal: Frameworkアプリケーションのテンプレートを使用して作成されたWebCenter Portalアプリケーションであること。
「WebCenterポータル」オプションは、JDeveloperでWebCenter Portal: Frameworkアプリケーションのテンプレートを使用して開発されたアプリケーションに対してのみ表示されます。
デプロイ済WebCenter Portalアプリケーションが稼働中であること。
デプロイ済WebCenter Portalアプリケーションには、MDSリポジトリおよびパーティションに関する正確な情報が含まれ、MDSリポジトリはアプリケーションからアクセス可能であること。この情報を確認するには、adf-config.xmlファイルのmetadata-store-usagesセクションをチェックします。MDSの詳細は、『Oracle Fusion Middleware管理者ガイド』のMDSリポジトリの概要に関する項を参照してください。
次の構成をサポートするために、WebCenter Portalアプリケーションが必須アーティファクトと一緒にパッケージ化されていること。
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アプリケーションに対して登録されていること。システムMBeanブラウザを使用して、これらのMBeanが登録されているかどうかを確認できます。
Fusion Middleware Controlで、WebCenter PortalアプリケーションのシステムMBeanブラウザを開きます。次のいずれかを実行します。
Spacesアプリケーションでは、メニュー・オプションの「WebCenterポータル」→「システムMBeanブラウザ」を選択します。
Frameworkアプリケーションでは、メニュー・オプションの「アプリケーションのデプロイ」→「システムMBeanブラウザ」を選択します。
「アプリケーション定義のMBean」→「oracle.adf.mbean.share.connection」の下で、アプリケーションのADFConnection MBeanを見つけます(図D-2を参照)。
同様に、「アプリケーション定義のMBean」→「oracle.adf.mbean.share.config」の下で、アプリケーションのADFConfig MBeanを見つけます(図D-2を参照)。
第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のメッセージを分析し、必要な作業を判断すること。
Spacesアプリケーションの場合、このログ・ファイルがDOMAIN_HOME/servers/ServerName/logsディレクトリで参照可能です。ログ・ファイルは、ServerName-diagnostic.logのネーミング規則に従います。第39.5.1項「Spacesアプリケーションのログ」も参照してください。
Frameworkアプリケーションの場合、このログ・ファイルがDOMAIN_HOME/servers/ServerName/logsディレクトリで参照可能です。ログ・ファイルは、ServerName-diagnostic.logのネーミング規則に従います。第39.5.2項「Frameworkアプリケーションのログ」も参照してください。
問題
Fusion Middleware ControlからWebCenter Portalアプリケーションを構成する場合は、次のメッセージが表示されます。
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サービス構成」画面から接続を構成しようとしています。
解決策
アプリケーションの診断ログを確認します。
Spacesアプリケーションの場合、このログ・ファイルがDOMAIN_HOME/servers/ServerName/logsディレクトリで参照可能です。ログ・ファイルは、ServerName-diagnostic.logのネーミング規則に従います。第39.5.1項「Spacesアプリケーションのログ」も参照してください。
Frameworkアプリケーションの場合、このログ・ファイルがDOMAIN_HOME/servers/ServerName/logsディレクトリで参照可能です。ログ・ファイルは、ServerName-diagnostic.logのネーミング規則に従います。第39.5.2項「Frameworkアプリケーションのログ」も参照してください。
モジュールoracle.adf.mbean.share.connectionおよびoracle.adf.mbean.share.configのメッセージを分析し、必要な作業を判断します。
第D.2.2項「WebCenter PortalのメニューがFusion Middleware Controlに表示されない」も参照してください。
WebCenter Portalアプリケーションでサポートされていないサービスを構成しないようにしてください。ご使用のアプリケーションが使用するように設計されていないサービス、たとえばディスカッションを構成しようとすると、Enterprise ManagerおよびWLSTを使用したWebCenter Portalの構成は失敗します。
Spacesアプリケーションは、WebCenter Portalのすべてのサービスをサポートするように設計されていますが、WebCenter Portal: Frameworkを使用して作成したアプリケーションは、開発者が設計時に特別に追加したサービスに対して、アプリケーションの構成内でのアーティファクトのみを提供します。たとえば開発者がJDeveloperでアプリケーションのディスカッションを追加または構成しなかった場合は、デプロイ後にEnterprise ManagerおよびWLSTでディスカッションを構成できません。
1つ以上のWebCenter Portalサービスの構成または接続に関して問題が発生している場合は、次の適切なトラブルシューティングの項を参照してください。
問題
WebCenter Portalアプリケーションを構成しましたが、これらの構成が別のアプリケーションでも表示されます。
たとえば、MyPortalApp1という名前のアプリケーションのメール接続を作成または編集すると、その接続の変更が別のアプリケーションMyPortalApp2でも表示されます。
解決策
これは複数のアプリケーションがMDSパーティションを同じスキーマで共有する場合に発生します。この問題を解決するには、これらのアプリケーションを再度デプロイして、各アプリケーションが異なるMDSスキーマまたは異なるMDSパーティションを使用するようにします。異なるMDSリポジトリまたはパーティションを使用するために、MDSリポジトリを作成するか、既存のWebCenter Portalアプリケーションを構成する方法の詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Metadataリポジトリの管理に関する項を参照してください。
問題
Spacesアプリケーションまたは独自のポータル・アプリケーションにアクセスできないか、エラー・メッセージが表示されていて、オープン・ファイルが多すぎるという問題があることを診断ログ・ファイルが示しています。
解決策
次の操作を実行します。
各バックエンド・サーバー(主にデータベース)で構成されるファイル・ハンドル数を確認し、必要に応じて数を増やします。
ファイル・ハンドル数を増加した後でも問題が解決されない場合は、/etc/sysctl.confファイルのfs.file-maxの値を確認し、必要に応じて値を増やします。
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
WLSTコマンドをいずれも実行できません。
解決策
次のことを確認します。
WebCenter Portal WLSTコマンドは常に、WebCenter Portal Oracleホーム・ディレクトリ(WC_ORACLE_HOME/common/bin)から実行してください。
間違ったディレクトリからWebCenter Portal WLSTコマンドを起動しようとすると、NameErrorが表示されます。
Python以外のファイルは、WLSTソース・ディレクトリ: WC_ORACLE_HOME/common/bin/wlstには格納されません。このディレクトリには、.py拡張子のみを持つファイルが含まれる必要があります。
この場所のファイルのデフォルト・セットには、Oracleからの適切なPythonファイルが含まれます。ユーザーは、このディレクトリに一部のPython以外のスクリプト、たとえばバックアップ・ファイルや構文エラーのあるテスト用Pythonファイルをコピーしておくことが可能です。
webcenter-wlst.jarは、WC_ORACLE_HOME/common/bin/wlst/libにあります。
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
問題
WLSTコマンドが特定のサービスに対して実行できないため、そのサービスを構成できません。
解決策
最初に、listApplications()またはdisplayMetricTableNames()などの一般的なWebCenter Portal以外のコマンドを実行して、これらのコマンドが機能するかどうか確認します。一般的なコマンドが機能しない場合は、第D.3.1項「WebCenter Portal WLSTコマンドがいずれも機能しない」で説明される解決策を適用してください。
一般的なコマンドが機能する場合は、テスト・コマンドを実行して、WebCenter Portal固有のコマンドに構文エラーがないか確認します。適切なWSLTチェック・コマンドを実行してください(表D-2を参照)。
表D-2 WebCenter Portalサービスのファイル名とWLSTコマンド
| サービス名 | ファイル名 | WLSTコマンド |
|---|---|---|
|
アクティビティ・グラフ |
|
|
|
アクティビティ・ストリーム |
|
|
|
分析 |
|
|
|
ディスカッションおよびお知らせ |
|
|
|
ドキュメント |
|
|
|
外部アプリケーション |
|
|
|
スペース・イベント |
|
|
|
インスタント・メッセージおよびプレゼンス |
|
|
|
メール |
|
|
|
通知 |
|
|
|
個人イベント |
|
|
|
プロデューサ |
||
|
PDK-Javaプロデューサ |
|
|
|
WSRPプロデューサ |
|
|
|
ページレット・プロデューサ |
|
|
|
プロデューサ・ヘルパー |
|
|
|
RSSニュース・フィード |
|
|
|
検索 |
|
|
|
ワークリスト |
|
|
|
エクスポート/インポート: WebCenter Portalアプリケーション |
|
|
|
エクスポート/インポート: スペースおよびテンプレート |
|
|
|
ユーザーの同期化 |
|
|
|
ユーザーの名前変更 |
|
|
|
WebCenter Portal: 一般 |
||
|
サービス・フレームワーク |
|
|
|
一般設定 |
|
|
|
SpacesおよびSOA |
|
|
第1.13.3.1項「Oracle WebLogic Scripting Tool (WLST)コマンドの実行」も参照してください。
WebCenter PortalのWLSTコマンド詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
問題
Connection_Nameという名前の接続を作成できません。次のメッセージが表示されます。
A connection with nameConnection_Namealready exists.
たとえば、WLSTコマンドcreateExtAppConnectionを使用して外部アプリケーション接続を作成しようとしているか、createMailConnectionを使用してメール・サーバーに接続しようとしています。
解決策
接続名は、WebCenter Portalアプリケーションのすべての接続タイプにおいて一意である必要があります。使用中の名前で接続を作成しようとするとエラーが発生します。接続に一意の名前を使用していることを確認してください。
問題
WLSTコマンドを実行する前に、WebCenter Portalの管理サーバーに接続する必要があります。接続しなければ、WebCenter Portal WLSTコマンドは機能しません。
解決策
WLSTシェルを管理対象サーバーに接続するには、次のコマンドを実行してください。
connect(username, password , serverhost:serverport)
第D.3.1項「WebCenter Portal WLSTコマンドがいずれも機能しない」と第1.13.3.1項「Oracle WebLogic Scripting Tool(WLST)コマンドの実行」も参照してください。
問題
WebCenter Portalサービスへの接続の作成やポートレット・プロデューサの登録などの操作をWebCenter Portalアプリケーションで実行しようとすると、次のメッセージが表示されます。
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サービスへの接続の作成やポートレット・プロデューサの登録などの操作をWebCenter Portalアプリケーションで実行しようとすると、次のメッセージが表示されます。
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)コマンドの実行」も参照してください。
この項の情報は、WebCenter Portalのパフォーマンス関連問題の診断に役立ちます。
この項の内容は次のとおりです。
様々なツールを使用して、WebCenter Portal環境でのパフォーマンス問題を監視およびトラブルシューティングできます。
表D-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 11g Grid Control |
|
JConsole |
JavaアプリケーションとJava仮想マシン(JVM)をグラフィカルに監視します。 |
|
|
JRockit Mission Control |
メモリー、CPU使用率および他のランタイム・メトリックに関するライブ・データを取得および表示します。 |
|
|
Eclipse Memory Analyzer |
メモリー・リークを見つけ、メモリー使用率を減らします。 |
|
|
Threadlogic |
スレッド・ダンプを分析します。 |
非常に遅いページ・パフォーマンス、多いスレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成 |
表D-4「システム全体の遅さのトラブルシューティング」に記載されているアクションを使用して、システム全体の遅さをトラブルシューティングします。
表D-4 システム全体の遅さのトラブルシューティング
| アクション | 説明 | 詳細 |
|---|---|---|
|
1 |
主要なシステム・リソースを確認します。 |
|
|
2 |
|
|
|
3 |
Java仮想マシン(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 |
パフォーマンスを測定する前に、システムをウォーム・アップします。 |
|
パフォーマンス問題が発生する場合は、十分なシステム・ハードウェア・リソースがあること、つまり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アプリケーションのパフォーマンスにどのように影響するかを確認することができます。システムが安定している場合は、スワップ・メトリック(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仮想マシン(JVM)は、WebCenter Portalパフォーマンスに大きな影響を及ぼす可能性があります。このため、継続してJVMを監視し次を追跡することをお薦めします。
メモリー使用量
CPU使用率
スレッド・アクティビティ
Fusion Middleware ControlのWebCenter Portalの「最近のWebLogic Serverメトリック」ページから、3つすべてのメトリックを監視できます(図D-3)。詳細は、第39.1.8「WebLogic Serverメトリックの理解」と第39.2「Fusion Middleware Controlを使用したパフォーマンス情報の表示」を参照してください。
メモリーの傾向の監視: JVMは頻繁にメモリーの割当てと解放を行います。メモリー・リークと高いメモリー使用量を検出するには、メモリーの傾向を長期間(1時間また数時間)分析する必要があります。
メモリー・グラフで一番下の傾向線が上昇している場合は、メモリー・リークを示しています。メモリー・グラフの一番下のポイントは、完全ガベージ・コレクションの後にメモリー使用量がどこまで低下する可能性があるかを示します。少なくとも2つのメモリー・ダンプ(1つはメモリーが正常である場合、もう1つはメモリーの完全ガベージ・コレクションで過度の量をリサイクルできない場合)を採取すると、メモリー・ダンプを比較して、メモリーを消費しているコンポーネントを特定できます。
第D.4.4.4項「メモリー・リークとヒープ使用量問題のトラブルシューティング」も参照してください。
CPU使用率の監視: CPU使用率で不定期にスパイクが発生するのは正常ですが、CPU使用率が長期間高い(85-90%)場合は、通常、パフォーマンスに影響を及ぼす可能性のあるCPU問題が発生していることを示します。
CPU使用率が過負荷に見える場合は、定期的(たとえば5秒ごと)にいくつかのスレッド・ダンプを比較すると、CPU使用率の高さの原因を明らかにすることができます。
あるいは、JRockit Flight Recorderのようなプロファイリング・ツールを使用すると、CPU使用率を詳細に把握することができます。
スレッド・アクティビティの監視とスレッド・ダンプの分析(スタックされたスレッド、ブロックされたスレッド、デッドロック): 負荷状態が安定している場合は、スレッド数は一定です。突然のスパイクやスレッド数の増加は、一般的にシステム内に問題があることを示しています。
このような場合、複数のスレッド・ダンプを採取して、スタック/ブロックされたスレッドまたはデッドロックのコール元スタックを把握することができます。スレッド分析ツールを使用すると、余分なスレッドの原因とそれによって何が実行されているかを特定でき、また問題のある領域とパフォーマンスが低下している領域を検出できます。第D.4.4.2項「スタック・スレッドのトラブルシューティング」も参照してください。
第D.4.2.8項「非常に表示が遅いページのパフォーマンス、高スレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成」も参照してください。
|
ヒント: Oracle Fusion Middlewareの診断フレームワークでは、スタックされたスレッド、デッドロックされたスレッドなどの一般的な問題に関する情報を収集して管理し、そのような問題の診断と解決を支援します。あるいは、診断ダンプをOracleサポート・サービスに送信することもできます。詳細は、『Oracle Fusion Middleware管理者ガイド』の問題の診断に関する項を参照してください。 |
Fusion Middleware Control、JConsole、JVisualVM、JRockit Mission Controlなどの様々なツールを使用して、JVMパフォーマンスを監視できます。これらのいずれかのツールを使用して、JVMの現在の状態およびアクティビティ・スレッドとその状態を表示します。『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のJVMの監視とプロファイルに関する項も参照してください。
管理者はまず、Fusion Middleware ControlのWebCenter Portalの「最近のWebLogic Serverメトリック」ページを使用してJVMを監視できます(図D-3参照)。よりアグレッシブなリアルタイム・メトリックが必要な場合は、別の選択肢としてJConsoleを使用します(図D-4参照)。
JConsoleは、HotSpot、JRockit、IBM JVMなどJVMのすべてのタイプで利用できます。
JConsoleの実行可能ファイルは、JAVA_HOME/bin/jconsole.exeにあります。
この項では、次の接続プール設定を確認する方法を説明します。
レスポンス時間が遅く、診断ログ・ファイルに接続/接続プール・メッセージが含まれていたり、最近のスレッド・ダンプに接続プールからの接続の取得を待機しているコール元スタックが含まれていたりする場合に、この項の情報が役に立つことがあります。
WebCenter Portal管理者は、Fusion Middleware Controlを使用してJDBC接続メトリックを監視できます。「WebLogic Serverメトリック」ページ(図D-5)のJDBC使用状況の情報を使用して、JDBCの構成または接続プール・サイズの調整が必要かどうかを評価します。
第39.2項「Fusion Middleware Controlを使用したパフォーマンス情報の表示」も参照してください。
「最近のJDBC使用状況」グラフには、管理対象サーバーで現在オープンになっているJDBC接続数が表示されます。ここで表示されるJDBCセッション数は、JDBCデータ・ソースごとの現在アクティブな接続数メトリックの合計です。
使用状況が高く上昇傾向にある場合は、WebCenter Portal管理者は、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とアイデンティティ・ストア(Oracle Internet Directory、Active Directoryなど)間の接続でSSLが使用される場合は、追加の構成がいくつか必要になります。デフォルトでは、SSLポートを選択すると、JNDI接続がプールされないため、ログインしてユーザー、グループなどのアイデンティティ・ストアのエンティティを検索するときに、レスポンス時間が長くなり、パフォーマンスが低下します。詳細と指示は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のアイデンティティ・ストア構成のチューニングに関する項を参照してください。
データベース・アクセスが遅くなる、たとえば、アクティビティ・ストリームのクエリ、MDSのクエリまたはJPA(Java Persistence API)のクエリがWebCenter Portalアプリケーションでの様々な操作で遅くなる場合は、自動ワークロード・リポジトリ(AWR)レポートを分析して、Oracleデータベースにおけるパフォーマンス関連問題の根本原因を診断できます。
AWRレポートを生成する前に、まず、データベースをホストしているマシンの一般的な状態(CPU/メモリー)を確認します(第D.4.2.2項「システム・リソース使用率の監視」を参照)。システム・リソースの制限がパフォーマンス低下の原因でない場合は、AWRレポートでデータベースのパフォーマンス情報と統計を調べます。
詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のデータベース・パフォーマンスのチューニングに関する項と自動ワークロード・リポジトリ・レポートの生成に関する項を参照してください。
ネットワーク・トラフィックをリスニングおよび取得するネットワーク・ユーティリティであるtcpdumpを使用して、ネットワーク関連問題を調査および診断します。
たとえば、Enterprise ManagerのWebCenter Portalページにあるパフォーマンス・メトリックはサーバーのパフォーマンスが正常であることを示しているが、エンド・ユーザーはパフォーマンスが不安定/遅いことを報告している場合は、ネットワークに問題がある可能性があります。tcpdumpまたは同様のネットワーク・モニタリング・ツールを使用してネットワーク・トラフィックを追跡し、予想外に長い待機時間の原因が(ネットワーク上の)環境問題であるかどうかを確認します。
このユーティリティを実行してネットワーク・データを分析する方法は、tcpdumpのドキュメントを参照してください。
pingを使用してネットワーク待機時間を測定します。
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のSpacesアプリケーションの出力ログは、 出力ファイルはシンプルなテキスト・ファイルで、スレッド情報などの様々なサーバー・メッセージを含みます。 |
WebCenter Portalアプリケーションをホストする管理対象サーバーの診断ログ(<managed_server_name>-diagnostic.log)でエラー、インシデントおよび警告を見つけます。
WebCenter Portalアプリケーションがエラー状態で動作している場合は、パフォーマンスに大きな影響を与える可能性があります。たとえば、WebCenter Content Serverへの接続が一時的に止まるかアクセス不能になった場合、接続を試行中に、コンテンツ関連コンポーネントのあるページのレスポンスが非常に遅くなり、最終的にタイムアウトになることがあります。
タイムアウト、サービス使用不可、キャッシュ・エラーなどが原因のエラー、インシデントおよび警告メッセージは、診断ログ・ファイルに記録されます。この診断ログは、Fusion Middleware Controlから表示できます。詳細は、第39.5項「ログ情報の表示および構成」を参照してください。
|
注意: パフォーマンスの測定時に、デバッグ/トレース・メッセージ、つまりCONFIG(700)より低いレベルは記録されていないことを確認します。普通、詳細または最も詳細メッセージが表示される場合、システムはデバッグ・モードで動作しています。つまり大部分のリクエストが通常よりかなり遅くなっています。より低いレベルのロギングを一時的に構成して問題をデバッグする場合は、パフォーマンスを測定する前に必ずログ・レベルを変更します。 |
DMS Spyサーブレットを使用すると、Webブラウザから内部DMSメトリック・データにアクセスできます。このサーブレットは、長期間システムを監視する場合に有用で、内部システムの動作とパフォーマンスの把握に役立ちます。
通常、WebCenter Portal固有のメトリックの監視にDMS Spyを使用することはありません。これは、WebCenter Portal固有のメトリックには、Fusion Middleware Controlからのほうが簡単にアクセスできるためです。ただし、ADFアプリケーション・モジュール(AM)プールに関する警告/エラー・メッセージの表示などの他の主要なメトリックに関心がある場合は、ここでAMプール・メトリックを調査できます。同様に、Javaオブジェクト・キャッシュ(JOC)に関するメッセージが表示される場合は、JOCのDMS監視機能を有効にしてJOC内のアクティビティを観察できます。
JOC DMS監視を有効にするには、javacache.xmlファイル(通常は<webcenter_domain>/config/fmwconfig/servers/WC_Spaces/javacache.xml)を編集します。
javacache.xmlファイルを開きます。
通常、ファイルの場所は、<webcenter_domain>/config/fmwconfig/servers/<server_name>/javacache.xmlです。
たとえばSpacesアプリケーションの場合は、<webcenter_domain>/config/fmwconfig/servers/WC_Spaces/javacache.xmlです。
次のエントリを変更します。
<dms enabled="false"/>
変更後: <dms enabled="true"/>
WebCenter Portalアプリケーションがデプロイされる管理対象サーバーを再起動します。
たとえば、Spacesアプリケーションの場合は、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アプリケーションがデプロイされている管理対象サーバーのaccess.logを調べて、HTTPキャッシュを分析することもできます。たとえば、ログを参照して、特定のユーザー/IPが同じリソースに対して繰り返しリクエストを行っているかどうかを確認します。繰り返されたリクエストがログに含まれている場合は、リクエストのキャッシュ・ヘッダーが間違っている可能性があり、キャッシュ問題をさらに調査する必要があります。様々な段階を省くために、静的リソースにアクセスすることから始めます。たとえば、wgetまたはcurlコマンドを使用し、ローカル・マシンで同コマンドを発行することにより、WebLogic Serverポートを使用している静的リソースを直接フェッチします。次に、WebCenter PortalアプリケーションをホストしているWebLogic Serverをフロントエンド処理する他のエンティティ(Oracle HTTP ServerやApacheなど)経由で、同じリソースにアクセスします。必要に応じてパケットのトレースを有効にし、WebCenter Portal層からのレスポンスを見つけて、問題がWebCenter Portal側で発生しているのかネットワークで発生しているのかを確認します。
|
注意: Spacesアプリケーションのアクセス・ログは、 |
この項では、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などの静的コンテンツを圧縮します。サイトでパフォーマンス問題が発生している場合は、ブラウザに圧縮されたレスポンスが表示されていることを確認する必要があります。第D.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リクエストのフローとタイミングを理解している場合は、WebCenter Portalアプリケーションのパフォーマンス問題の診断と解決に役立つ可能性があります。たとえばユーザーがログインするたびに、ユーザーのブラウザとサーバー間でいくつかのリダイレクトが発生する可能性があります。ログイン・サーバーに対するリクエストに時間がかかりすぎている場合は、WebLogic Serverではなくログイン・サーバーを調査する必要があることがわかります。同様に、アプリケーションのランディング・ページのロード・リクエストが遅い場合は、ランディング・ページの高速化に取り組むことができます。
なんらかの理由でWebCenter Portalの管理対象サーバーを再起動する場合は、Just-In-Time(JIT)コンパイルのオーバーヘッドを回避するために、必ずシステムをウォーム・アップしてからパフォーマンスを再テストしてください。
システムをウォーム・アップするために、パフォーマンスを後で測定するステップを手動で実行するか、ロード・テスト・ツールを使用してステップの数回の反復を実行することができます。WebLogicの管理対象サーバーを再起動すると、多くの場合、最初のリクエストは通常より遅くなります。つまり、エンド・ユーザーが経験する一般的なパフォーマンスは実現されません。
Fusion Middleware Controlを使用し、WebCenter Portalアプリケーションの最も遅いページを判断します。パフォーマンスが低下したページが頻繁に使用される(起動メトリックが高い)場合、そのようなページのパフォーマンスの向上に集中的に取り組むことは意味のあることです。
最も遅いWebCenter Portalページを見つけるには:
Fusion Middleware Controlにログインし、SpacesまたはFrameworkアプリケーションのホーム・ページに移動します。
次のいずれかを実行します。
WebCenter Portal: Spacesの場合: 「WebCenterポータル」メニューから、「監視」→「最近のページ・メトリック」を選択します。
WebCenter Portal: Frameworkアプリケーションの場合: 「アプリケーションのデプロイ」メニューから、「WebCenterポータル」→「最近のページ・メトリック」を選択します。
pageResponseTimeしきい値よりレスポンスが遅いページ・リクエストは、ページ上部のグラフに赤色で表示されます。
「時間(ミリ秒)」列の「降順ソート」矢印をクリックして、レスポンス時間を基準にページ・リクエストをソートします。
しきい値を超えたページ・レスポンス時間は、表内にオレンジで表示されます。
最も遅いページを特定し、ページが表示されるスペースを書き留めます。
最も遅いページがリクエストされる頻度など、詳細なメトリックについては、次のいずれかを実行します。
WebCenter Portal: Spacesの場合: 「WebCenterポータル」メニューから、「監視」→「全ページ・メトリック」を選択します。
注意: ホーム・スペースにあるページのリクエストは、「全ページ・メトリック」ページから除外されます。
WebCenter Portal: Frameworkアプリケーションの場合: 「アプリケーションのデプロイ」メニューから、「WebCenterポータル」→「全ページ・メトリック」を選択します。
第39.1.5項「ページ・リクエスト・メトリックの理解」と第39.3「WebCenter Portalの主要なパフォーマンス・メトリックのしきい値および収集のカスタマイズ」も参照してください。
この項の情報を使用して、ページ・パフォーマンスの低下に関連する問題を診断します。
実行中の遅いページ・リクエストをトラブルシューティングするには、ユーザー・セッションが動作しているサーバーに対するJRockit Flight Recorder(JFR)レコードを抽出および表示します。第D.4.5項「JRockitフライト記録を使用してリクエストをトラブルシューティングする方法」も参照してください。
または、第D.4.2.8項「表示が非常に遅いページのパフォーマンス、高スレッド数およびシステム・ハングの診断のためのスレッド・ダンプの生成」で説明されているように、等間隔のいくつかのスレッド・ダンプをたとえば1、2秒ごとに採取します。
スレッド・ダンプを比較すると、特定のメソッド・コールに長時間を費やしたスレッドに気付く場合があります。これは、いくつかの連続したスレッド・ダンプ内のコール・スタックが同じであるためです。たとえば、データベース、Oracle WebCenter Content Server、コラボレーション・サーバー、ポートレット・プロデューサ、LDAPサーバーなどに対するメソッド・コールが存在することがあります。この場合は、関連するバックエンド・サーバーを調査して、問題を詳細に診断することができます。
スタック・スレッドは、次のようないくつかの理由で発生することがあります。
サーバーがもう少しでメモリー不足になります。サーバーがメモリー不足状態に近づくと、すべてのリクエストが遅くなります。メモリー不足問題を解決するには、第D.4.4.4項「メモリー・リークとヒープ使用量問題のトラブルシューティング」を参照してください。
デッドロック・スレッド。スレッド・ダンプを採取し、デッドロック・スレッドを検索します。これにより、通常、製品コードの問題が明らかになります。
極度に遅いページ・リクエスト。 等間隔のいくつかのスレッド・ダンプを採取し、実行に時間のかかっているメソッドを見つけます。
リクエストにかかる時間が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&_afrWindowMode=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はエラー・メッセージに記録されるため、第D.4.4.5「コンテンツに対する遅いリクエストのトラブルシューティング」に記載されている、遅いリクエストをトラブルシューティングするステップに従うこともできます。
WebCenter Portalアプリケーションのパフォーマンスが徐々に低下し、ヒープ使用量とガベージ・コレクション・アクティビティが増加しており、さらにOutOfMemoryErrorsが表示される場合は、アプリケーション内でメモリー・リークが発生し、JVMの空きメモリー容量が連続して減少する可能性があります。
図D-6は、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コマンドライン・リファレンス(http://docs.oracle.com/cd/E15289_01/doc.40/e15062/title.htmで入手可能)を参照してください。
管理対象サーバーを再起動します。
問題が解決しない場合は、ステップ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 WebCenter Content Content Serverシステム管理者ガイドのシステム監査情報に関する項を参照してください。
データベースに送信されるクエリごとにパフォーマンス情報を確認できるように、systemdatabaseトレース・オプションが選択されていることを確認します。詳細は、Oracle WebCenter Content Content Serverシステム管理者ガイドのサーバー全体のトレースに関する項を参照してください。
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からアクセスできます。
