| Oracle Collaboration Suiteサイジングおよびパフォーマンス・チューニング リリース2（9.0.4） 部品番号: B15725-01 |
|
 戻る |
Copyright © 2004 Oracle.All rights reserved.
OracleはOracle Corporationおよびその関連会社の登録商標です。その他の名称は、Oracle Corporationまたは各社が所有する商標または登録商標です。
サイジングおよびパフォーマンス・チューニング
リリース2（9.0.4）
部品番号: B15725-01
原典情報: B15608-01 Oracle Collaboration Suite Sizing and Performance Tuning Release 2 (9.0.4)
2005年3月
このドキュメントでは、Oracle Collaboration Suiteの配置の計画、サイジングおよびチューニングについて説明します。このドキュメントには、新しい情報およびOracle Collaboration Suiteのドキュメント・ライブラリ内の情報へのリンクが含まれています。
このドキュメントでは、次の内容について説明します。
この項では、Oracle Collaboration Suiteコンポーネントの容量計画およびサイジング情報について説明します。この項の内容は次のとおりです。
次のガイドラインは、Oracle Collaboration Suite全体に適用されます。
Oracle Collaboration Suiteのサイジング要件を決定する場合は、ユーザー数のみでなく、使用パターンおよびユーザーが存在するタイムゾーンも考慮する必要があります。Oracle Collaboration Suiteサーバーからユーザーまでの距離は、システム・パフォーマンスに大きな影響を与えます。
オラクル社では、Oracle Collaboration Suiteのピーク時の使用量レベルを次のように想定しています。
Oracle EmailおよびOracle Calendarの場合は、最大タイムゾーン内の全ユーザー数の50から75%
Oracle Filesの場合は、最大タイムゾーン内の全ユーザー数の5から10%
『Oracle Calendar管理者ガイド』には、Oracle Calendarの容量計画およびサイジング情報が含まれています。『Oracle Calendar管理者ガイド』の付録A「ディスク領域およびメモリー」を参照してください。
この項では、Oracle EmailおよびOracle Webmailの初期計画に関する考慮事項およびハードウェア要件について説明します。
この項では、次の内容について説明します。
この項では、Oracle Emailをインストールして構成する場合に決定する必要がある配置の基本事項の概要について説明します。
単一インスタンス配置
単一インスタンス配置は、インストールおよび管理する場合の最も基本的な配置です。Oracle Internet DirectoryによってユーザーXがインスタンスY、ユーザーAがインスタンスBに対応付けられる、複数の単一インスタンス・コンピュータで構成された配置にすることができます。ただし、インスタンスYおよびBにはそれぞれ独自のローカル・コピーが必要なため、すべての共有メッセージ（会社全体宛てのメールなど）の冗長コピーが存在することになります。
中間層配置
中間層は、任意のサーバー数まで水平方向にスケーリングできます。中間層の数を決定することによって、n個の大きいボックスを管理した場合の低コストと、n個のボックスと同じ処理能力を持つ多数の安くて小さいボックスの価格性能比を平衡化します。価格性能比と管理コストの組合せとしては、デュアルCPUのLinux Boxが最も一般的です。
中間層コンピュータ上のOracle Emailに必要な合計コンピュータ・メモリーを決定するには、次の計算式を使用します。
(480 + peak native users * .25) + peak web users
Oracle Webmailには、容量計画に関する次の推奨事項が適用されます。
OC4J_UM Java仮想マシンの数とサーバー・コンピュータのCPUの数は、同じである必要があります。
LDAPサーバーは、Oracle Webmailサーバーに物理的に近接している必要があります。この場合、ラウンドトリップTCP/IP時間を短くします。
システムのピーク時のCPUボトルネックを監視します。
データベース側のメッセージのソートを無効にします。データベース側のソートは、msg_id順でのメッセージのフェッチより大幅に遅く、高コストな問合せとなります。
Oracle Web Cacheを有効にする場合、クラスタ環境には構成しないでください。Oracle Web Cacheの個別のインスタンスを、各中間層コンピュータに構成します。
Apache Webサーバー（gzipモジュールとして）またはOracle Web Cacheのいずれかで、HTTP圧縮を有効にします。
サイジングの詳細は、『Oracle Ultra Searchユーザーズ・ガイド』の第2章「Ultra Searchのインストールと構成」を参照してください。
Oracle Voicemail & Faxのサイジング要件は、メッセージの記録、メッセージの取得およびFaxの受信を行うことが予想される同時コール元の数に基づいています。表1に、ハードウェアを構成する場合のガイドラインを示します。
表1 推奨されるユーザーとポートの比率
| ユーザー数 | ユーザーとポートの比率 |
|---|---|
| 100未満 | 20:1 |
| 100 - 300 | 30:1 |
| 300 - 500 | 40:1 |
| 500 - 1000 | 50:1 |
| 1000以上 | 75-100:1 |
実際の要件は、エンド・ユーザーの役割および職責によって異なります。たとえば、多くのボイスメール・メッセージを受信するコール・センター・ユーザーが存在するサイトの場合は、コール・アクティビティがほとんど行われないバックオフィス・サイトより低い比率が必要なことがあります。
次の考慮事項が適用されます。
通常の使用例では、ボイスメール・メッセージごとの2回のコール（メッセージを残すためのコールとメッセージを取得するためのコール）に基づいて、システムをサイジングします。Oracle Voicemail & FaxとOracle Emailをともに配置すると、コール数は、通常、ボイスメール・メッセージごとに1.25から1.5の間の値に削減されます。これは、一部のユーザーが、電子メール・クライアントを使用してボイスメールを取得するためです。
Intel Dialogic/82JCTUテレフォニー・カードでは、カードごとに8個のポートが提供されます。
カードは、任意のサーバー番号で使用可能な空きスロットの数まで構成に追加できます。使用可能なスロット数は、サーバー・ハードウェアによって異なります。
次の表に、CPUおよびテレフォニー・カードのハードウェア構成に関する推奨事項を、サイトごとの予想ユーザー数に基づいて示します。
表2 ユーザーが500人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 1 | 1 |
| デュアルCPUサーバー | 0 | 0 |
| Intel Dialogic/82JCTUカード | 2 | 2 |
| VFX/PCIカード | 1 | 1 |
表3 ユーザーが1000人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 0 | 0 |
| デュアルCPUサーバー | 1 | 1 |
| Intel Dialogic/82JCTUカード | 4 | 4 |
| VFX/PCIカード | 1 | 1 |
表4 ユーザーが2000人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 1 | 0 |
| デュアルCPUサーバー | 1 | 1 |
| Intel Dialogic/82JCTUカード | 7 | 5 |
| VFX/PCIカード | 2 | 1 |
表5 ユーザーが3000人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 0 | 0 |
| デュアルCPUサーバー | 2 | 1 |
| Intel Dialogic/82JCTUカード | 8 | 5 |
| VFX/PCIカード | 2 | 1 |
表6 ユーザーが4000人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 1 | 0 |
| デュアルCPUサーバー | 2 | 1 |
| Intel Dialogic/82JCTUカード | 11 | 5 |
| VFX/PCIカード | 3 | 1 |
表7 ユーザーが5000人のサイト
| リソース | プライマリ・システム | セカンダリ・システム |
|---|---|---|
| シングルCPUサーバー | 0 | 0 |
| デュアルCPUサーバー | 3 | 1 |
| Intel Dialogic/82JCTUカード | 13 | 5 |
| VFX/PCIカード | 3 | 1 |
この項では、Oracle Collaboration Suiteコンポーネントのパフォーマンス・チューニング情報について説明します。この項の内容は次のとおりです。
Oracle Calendarのパフォーマンス・チューニングの詳細は、『Oracle Calendar管理者ガイド』の付録B「Calendarカーネル・パラメータの調整」を参照してください。
この項では、Oracle Emailアーキテクチャの概要、チューニング可能な主なコンポーネントの詳細およびシステムのスケーリングのガイドラインを示します。また、パフォーマンス上の問題の一般的な症状、ボトルネックになっているコンポーネントの識別方法および問題の解決方法についても説明します。
Oracle Emailプロセスの監視の詳細は、『Oracle Email管理者ガイド』を参照してください。
この項の内容は次のとおりです。
この項では、Oracle Emailアーキテクチャおよびプロセスの概要について簡単に説明します。この情報は、この項で説明するチューニングに関する推奨事項の理解に有効です。
Oracle Emailプロセス
表10に、Oracle Emailプロセスを示します。
表10 Oracle Emailプロセス
| プロセス | 説明 |
|---|---|
ESSMI
|
インバウンドSMTPプロセス |
ESSMO
|
アウトバウンドSMTPプロセス |
ESIMAPDS
|
IMAPプロセス |
ESLS
|
リスト・サーバー・プロセス |
OJMA
|
Webクライアントおよびその他のアプリケーションでメッセージ・ストアへのアクセスに使用される、基礎となる技術ベース。サーバーではありません。 |
ESGC
|
Oracle Emailスキーマ内のすべての一時表をクリーン・アップするハウスキーピング・プロセス |
図1に、Oracle Emailプロセスおよびデータベースとそれらのプロセスの相互作用の概要を示します。
図1では、ESSMIプロセスが「送信のみ」モードで動作中です。これによって、アウトバウンドSMTPプロセスESSMOでメッセージ配信を実行できます。LDAPサーバーであるOracle Internet Directoryは、図には示されていません。Oracle Internet Directoryサーバーをユーザー認証に使用するコンシューマは、リスト・サーバーであるSMTP配信モジュール（ESSMO）とIMAPプロセスです。
メール・フロー
次の手順では、メッセージがシステムに着信する場合のフローの概要について説明します。
ESSMIによって、キュー表ES_QUEUEおよびES_RECIPIENT、コンテンツとメタデータを処理する表ES_HEADER、ES_EXT_HEADER、ES_SHELLおよびES_BODYに着信メッセージが挿入されます。
ESSMOプロセスによって、LDAP検索が実行され、メッセージの受信者がローカル・ユーザーであるかどうかが確認されます。
受信者がローカル・ユーザーの場合は、ESSMOによって、ポインタ表ES_INSTANCEにレコードが挿入され、ES_USERおよびES_FOLDER表での受信者の使用状況が更新されます。
受信者がローカル・ユーザーでない場合は、ESSMOによって、メール・メッセージが転送されます。
次の手順では、ユーザーがメッセージを読み取る場合のフローについて説明します。
Webクライアント、POP3クライアントまたはIMAPクライアントを使用して、特定のメッセージの読取りをリクエストします。
サーバーによって、ES_BODY表からメッセージ本文が収集され、次に、ES_SHELL、ES_HEADERおよびES_EXT_HEADER表から本文のメタデータ（添付ファイル数、送信者など）が検索されます。
メッセージは、プロトコルに適した形式で構成され、ユーザー側での表示用にネットワークを介して送信されます。
Oracle Emailシステムのコストは、高、中および低の3つの層に分けることができます。これらのコスト値は、システムでの他の操作に関連しています。次に、ユーザー動作またはアプリケーション設計での変更が、ハードウェア層に与える影響について説明します。
高コストの操作
データベースの場合: フォルダのオープン。ユーザーのすべてのメッセージのリストは、データベースから取得する必要があります。コストは、フォルダのサイズに比例して増加します。このコストは、表が索引構成表として再構成されている場合はそれほど高くありません。
中間層の場合: IMAPによる新規ヘッダーのフェッチ操作。ヘッダーの新規リストをクライアントからフェッチするには、ESIMAPDSプロセスで各メッセージ・シェルを解析する必要がありますが、これは高コストなCPU操作になります。この操作は、ユーザーが受信ボックスを開き、すべての未読ヘッダーをダウンロードする場合に行います。初めて使用するユーザーがこの操作を行うと、ユーザーのフォルダ内のすべてのメッセージがダウンロードされます。これ以降のフォルダのオープン・コールでは、新規メッセージのみがダウンロードされます。
中コストの操作
データベースの場合:
メール・メッセージの配信。新規レコードは、適切な索引を保持したまま、7つ以上の表に挿入する必要があります。メッセージが様々な状態に遷移するため、キュー表のいくつかは複数回更新されます。
メール・メッセージの読取り。メッセージを構成するには、ES_BODY内のラージ・オブジェクト（LOB）のフェッチおよびその他のメタ表の問合せを行う必要があります。
ハウスキーピング・プロセス。ESGCプロセスによって、キュー表およびインスタンス表がクリーン・アップされるのみでなく、間接参照される本文のメール・ストア全体がマークされてから空にされます。この操作は低コストではありませんが、ハウスキーピング・プロセスの対象がバッファ・キャッシュ内にある可能性は低いため、ボトルネックとなる要因が物理的な入出力制約である場合があります。
get new mailまたはnoop:コールの実行。この操作によって、特定のフォルダ識別子の新規インスタンスのチェックが行われます。
低コストの操作
データベースの場合:
メール・メッセージのフラグの変更。これは、メール・メッセージを既読または削除とマークする操作などの実行中に行われます。
すでにバッファ・キャッシュ内にあるメール・メッセージの読取り。メッセージがすでにバッファ内にあるため、追加の取得を行う必要はありません。
複数の受信者へのメッセージの配信。単一の受信者にメッセージを配信する場合に実行する必要がある大量のメール・データベース作業がすでに実行されています。追加の受信者への配信は、特に配布リストを使用すると、新規ES_INSTANCEレコードのみが作成されるため、非常に低コストになります。
中間層の場合:
SMTPによるメール・メッセージの受取り。Net8 ListenerおよびOracle Email SMTPコードの効率性を考慮すると、メール・メッセージの挿入に、ESSMIコンポーネントの処理能力はほとんど必要ありません。
SMTPによるメッセージ配信の実行。この場合のコストは、データベースではなく、中間層プロセスによるものです。たとえば、300Mhzプロセッサを2つ搭載した単一のE250では、1時間当たり75000件のメッセージの配信を簡単に処理できます。
データベース接続の制限は、システム・パフォーマンスに大きな影響を与えます。制限を低く設定しすぎると、不要なクライアント障害が発生する可能性があります。制限を高く設定しすぎると、中間層のメモリーが浪費され、シャドウ・プロセスのサイズが原因でバックエンド・データベースにおける物理メモリーの消費効率が低下する可能性があります。
データベース接続に関するメトリック・データを取得するには、oesmonユーティリティを使用します。次のコマンドを使用して、IMAPインスタンスごとのデータベース接続の使用率を確認します。次に例を示します。
oesmon get rgmum4:um_system:imap.DUMP.DBconnections.dump
データベース接続プール・アルゴリズムでは、使用可能な接続が検出されるまで、各リクエストのプールの最上位からリストを下方向に移動します。このため、データベース接続の使用率は、ピラミッド形になります。つまり、最初の接続ではロードの大部分が処理され、次の接続ではより少ない割合が処理されるなどのようになります。このピラミッドの傾斜度は、データベースがリクエストを処理する速度を示しています。傾斜度が高い場合はレスポンスが速いことを示し、傾斜度が低い場合はレスポンスが遅いことを示しています。このデータを評価する場合は、実行数が0（ゼロ）になる接続を検索します。これは、このポイントでのプールが要求の受入れに十分な大きさであることを示しています。最大データベース接続プールは、この値以上にサイズ変更してください。
LDAP接続プールの利用状況を確認する場合は、最小プール設定を小さい数値に設定して1ずつ増加し、次のコマンドを使用して、作成されたLDAP接続の数を確認する方法をお薦めします。
netstat -a | grep ldap | grep ESTABLISHED | wc -l
一部のオペレーティング・システムでは、コマンドでldapのかわりにLDAPポートを指定する必要があります。デフォルトのLDAPポートは389です。
表11に、Oracle Emailのパフォーマンスに影響を与えるパラメータを示します。これらのパラメータに対しては、Oracle Enterprise Managerを使用してアクセスおよび編集を行うことができます。これらのパラメータは、サーバー・ページの「Unified Messaging」に表示されます。
表11 Oracle Emailで推奨されるパラメータ
| パラメータ | 説明 | 推奨値 |
|---|---|---|
| LDAP接続プールの最大数 | LDAP接続の最大数を決定します。 | 20 |
| LDAP接続プールの最小数 | LDAP接続の最小数を決定します。
ピーク・ロードの60%の処理に必要な接続数を指定します。 |
5 |
| LDAP接続プールの増分 | LDAP接続のプールを増加する場合のサイズ増分。
多くのリクエストが同時に着信すると、プールの増加が間に合わず、一部の接続が拒否される場合があります。 |
1 |
| LDAP接続再試行間隔 | LDAP接続の試行の間にスリープする時間（マイクロ秒）。
値が大きすぎると、LDAP接続が使用可能な場合で、プロセスのスリープ時間が長くなりすぎるため、レスポンス時間が遅くなることがあります。 |
100000 |
| エラーになる前の再試行回数 | 問合せを終了するまでにLDAP接続を試行する回数。
プールが一杯になると、プロセスは、LDAP接続再試行間隔パラメータに指定した値の時間スリープします。 |
10 |
| 新規メールを取得する間隔(秒) | データベースに管理統計を入力するまでにスリープする時間（秒）。
値が小さすぎると、データベースへの書込みが頻繁に行われるため、システム・パフォーマンスが低下します。 |
600
（ハウスキーピング・プロセスの場合は7200） |
| プロトコル・サーバー最大スレッド | クライアント接続の処理に使用可能なスレッドの最大数。 | 50 |
| プロトコル・サーバー最小スレッド | クライアント接続の処理に使用可能なスレッドの最小数。 | 10 |
| プロトコル・サーバー増加スレッド | クライアント接続プールに追加するスレッドの数。 | 1 |
| クライアントの最大数 | 同時接続の最大数。
値が大きすぎると、IMAPは、リスナーが拒否している接続の処理を試行します。 値が小さすぎると、不要な数のIMAPプロセスの構成が必要になります。 |
1000 |
| タイムアウト間隔(秒) | サーバーによってアイドル・ソケットが切断されるまでの時間（秒）。 | 1800 |
| 送信のみ | SMTPインバウンド・サーバーの配信動作。
この値をFALSEに設定すると、インバウンドOracle Emailサーバーでの挿入時間が長くなる場合があります。 |
TRUE |
10分間の値を平均してCPUロードを確認するには、sarまたはvmstatオペレーティング・システム・ユーティリティを使用します。CPUリソースは、90%を超えて使用しないようにする必要があります。プラットフォームによっては、Java仮想マシンで他のプロセッサ上のスレッドをスケジューリングできない場合があります。このため、Java仮想マシンをデュアルCPUコンピュータ上で実行している場合、CPU使用率が50%とのみ表示されることがあります。ただし、いずれかのCPUがこのJava仮想マシンによって100%使用されている可能性があります。
時間データを表示するには、oracle.mail.sdk.esmail.timingパラメータをTRUEに設定します。この情報を使用して、データベースまたはLDAPの接続時間が遅いかどうかを確認します。時間データおよびIMAPクライアントの監視情報に、データベース接続のレスポンス時間が遅いことが示されている場合は、データベースのパフォーマンスをチューニングする必要があります。
LDAPの接続時間が遅い場合は、Oracle Internet Directory統計収集ツール（oidstats.sh）を使用して、LDAP操作に相当する問合せの実行に最適な計画を選択する場合にOracle Optimizerで必要なデータを生成します。LDAPの接続時間が遅いままの場合は、マシンのCPU使用率を監視し、ネットワークのラウンドトリップ時間を確認します。
Oracle Webmailのログ・ファイルにActiveとマークされた行を生成するには、Oracle Webmailパラメータのoracle.mail.sdk.esmail.dbpool_timingをTRUEに設定します。このパラメータを特定の1日に対してのみTRUEに設定し、ログ・ファイル内のActive行を検索すると、1日当たりのアクティブなデータベース接続の数を確認できます。この情報をタイムスタンプと相関させると、使用されたデータベース接続のピーク数を確認できます。この情報を使用して、データベース接続プールが正しく設定されているかどうかを確認します。
表13に、変更するとシステムのパフォーマンスに影響を与えるOracle Webmailプロセス・パラメータを示します。これらの値は、OC4J_UMコンテナのoc4j.propertiesファイルにあります。
表13 Oracle Webmailで推奨されるパラメータ
| パラメータ | 説明 | 推奨値 |
|---|---|---|
client.mail.defaultsort
|
TRUEに設定すると、ユーザーが最初にログインしたときに、Oracle Webmailクライアントによって、デフォルトのソート・フィールドおよび順序で自動的にソートが行われます。
|
FALSE |
client.esdsconnpoolparam.incrementsize
|
ESDSクライアント接続プールに追加する接続の数。
|
5 |
client.esdsconnpoolparam.initialsize
|
ESDSクライアント接続プールの初期接続数。
|
30 |
client.esdsconnpoolparam.maxsize
|
ESDSクライアント接続プールの最大接続数。
|
60 |
client.esdsconnpoolparam.minsize
|
ESDSクライアント接続プールの最小接続数。
|
30 |
client.esdsconnpoolparam.shrinkingtimeoutinterval
|
ESDSクライアント接続プールを縮小できるようになるまでの遅延時間。
|
1800 |
client.esdsconnpoolparam.timeoutinterval
|
ESDSクライアントがプール内に空き接続ができるまで待機する最大秒数。この時間内にプールに接続が解放されない場合は、ディレクトリ・サーバー・コードによって例外がスローされます。
|
30 |
jdbc.connection.debug
|
JDBC接続のデバッグを有効または無効にします。 | FALSE |
mail.debug
|
Oracle EmailのOJMA APIのデバッグを有効または無効にします。
有効にすると、パフォーマンスに悪影響を与えます。 |
FALSE |
oracle.mail.ldap.reconnecttime
|
LDAPサーバーが使用不可の場合、サーバーがLDAPサーバーに再接続するまでに待機する時間（秒） | 4 |
oracle.mail.sdk.esmail.timing
|
時間データを出力します。このパラメータは、速度の遅いLDAPおよびデータベース・アクセスを判別する場合に使用します。 | FALSE
パフォーマンスに関する問題をデバッグしている場合にのみ、TRUEに設定します。詳細は、2.2.8「Oracle WebmailのJavaMail APIのレスポンス時間の監視」を参照してください。 |
oracle.mail.sdk.esmail.ldap_debug
|
LDAPのOJMA APIのデバッグを有効または無効にします。 | FALSE |
oracle.mail.sdk.esmail.dbpool_timing
|
アクティブなデータベース接続およびその合計数を出力します。この情報を使用して、データベース・プールが正しくサイジングされているかどうかを確認します。 | FALSE
データベース接続プールをサイジングしている場合は、TRUEに設定します。詳細は、「Oracle Webmailの最適なデータベース・プール・サイズの確認」を参照してください。 |
oracle.mail.sdk.esmail.cache_inactivity_timeout
|
ESDSクライアント接続プールがタイムアウトするまでに接続を待機する秒数
|
600 |
oracle.mail.sdk.esmail.connpool_max_limit
|
Oracle mail sdk esmail接続プールの最大接続数
|
20 |
oracle.mail.sdk.esmail.connpool_min_limit
|
接続プールに作成される接続の初期接続数または最小接続数を決定します。
未使用のデータベース接続が保持されないように、この制限はできるかぎり低くしておくことをお薦めします。 |
5 |
oracle.mail.sdk.esmail.cache_scheme
|
データベース接続プールのキャッシュ・スキームを決定します。
値を3にすると、パラメータが |
3 |
この項では、発生する可能性がある一般的なスケーリングの問題、その症状および解決方法について説明します。データベース関連の説明では、データベース管理者のスキルとStatspackに関する知識があることを想定しています。解決方法についての説明では、関連する中間層のCPUおよびメモリー・リソースが推奨されているものであることを想定しています。
配信キュー内のメッセージ数が多いままになる
ES_QUEUE表にstate=1（未処理）のレコードが多くある場合は、次のいずれかが問題である可能性があります。
配信を実行しているESSMOプロセスの数が十分ではない
名前解決で問題が発生している（LDAP）
ES_INSTANCE表への挿入を実行しているプロセス間で競合が発生している
この問題を解決するには、次の手順を実行します。
ESSMOログ・ファイルで、エラー（データベースでの記憶域容量の問題など）を確認します。
ESSMOログにエラーが記録されていない場合は、2から4の新規ESSMOプロセスを追加して、キュー処理における変更を監視します。
未処理のES_QUEUEレコードの数が一貫して多い（配信待機中メッセージが1000を超えている）場合は、名前解決に使用されているLDAPサーバーのCPU使用率を確認します。また、ESSMOで作成可能な数のソケット接続を受け入れるようにLDAPサーバーが構成されていることも確認します。LDAPサーバーがボトルネックでない場合は、ピーク時にデータベースでStatspackスナップを実行します。表ES_INSTANCE、ES_QUEUE、ES_RECIPIENT、ES_EXT_HEADER、ES_HEADER、ES_SHELLおよびES_BODYへの挿入時の競合を確認します。
ハウスキーピング・プロセスで古いメールすべてをクリーン・アップできない
パフォーマンス上の理由から、ハウスキーピング・プロセスは、夜間にのみ実行することをお薦めします。ES_QUEUEからのクリーン・アップ待機中のmsg_state=3内のメッセージの数、あるいはES_INSTANCEのfolder_id=3（保留中のプルーニング対象）またはfolder_id=4（保留中の収集対象）内のメッセージの数が増加し続ける場合は、日中にもハウスキーパーを実行する必要があります。ハウスキーパーによる処理が間に合わない場合は、システムによるメール・メッセージのプルーニングまたは収集が遅れていないかどうかを確認します。システムの処理が間に合わないタスクのみを処理するように設定した、追加のハウスキーパー・プロセスを作成してください。
メッセージの送信に時間がかかる
ネットワークが混雑しているか、またはネットワークに関する他の問題が発生している可能性があります。ESSMIプロセスがsubmit_only=falseに設定されている場合は、ESSMIでメール・メッセージの挿入の前に名前解決が実行されるため、LDAPまたはデータベースの挿入でレスポンス時間が遅くなる可能性があります。
ESSMIがsubmit_only=falseに設定されている場合は、次の手順を実行します。
ログ・ファイルで、LDAP接続プール制限を超えていることを示すエラーがないかどうかを確認します。また、LDAPサーバーが、CPUの限界ではなく、ESSMIで要求可能な最大接続数を受け入れるように構成されているかどうかを確認します。
メール・メッセージの送信のシミュレーションを実行して、名前解決の実行にかかった時間を調べ、解決時間を確認することもできます。サーバーでrcpt to:コールに応答する場合にかかる時間が、LDAP検索の実行に必要な時間です。次に例を示します。
telnet localhost 25 220 rgmum12.us.oracle.com ESMTP Oracle Email SMTP Inbound Server Ready helo test mail from: me@yahoo.com 250 2.1.0 Sender OK rcpt to: tuser1@oracle.com 250 2.1.5 Recipient ok
LDAPレスポンス時間が許容可能な値の場合は、データベースへのメールの挿入に時間がかかっている可能性があります。メール・メッセージがシステムに挿入される場合は、1つ以上の行が表ES_QUEUE、ES_RECIPIENT、ES_EXT_HEADER、ES_HEADER、ES_SHELL、ES_BODYおよびES_INSTANCEに挿入されます。これらの表のいずれかで競合が発生すると、挿入に時間がかかる場合があります。データベースでStatspackのレベル7レポートを実行して、これらの表および関連付けられた索引でエンキュー競合が発生していないかどうかを確認してください。競合が発生している場合は、表をパーティション化します。競合がES_INSTANCE表のmsg_id索引で発生している場合は、索引を逆キー索引に変更します。ただし、Oracle Emailに関連しないその他の特定のデータベースの問題（多くのセッションがディスクに対する書込みまたはディスクからの索引読取りの実行を待機している場合など）が発生している場合は、まず、これらの問題を解決する必要があります。
ESSMIプロセスがsubmit_only=trueに設定されている場合、ESSMIでは、データベースへの挿入の前にLDAP検索が実行されません。このため、メール・メッセージの送信に時間がかかる場合は、ネットワークまたはデータベースで問題が発生しています。データベースがボトルネックであるかどうかを確認するには、前述の項の手順を実行します。データベースがボトルネックの場合は、必要に応じて表をパーティション化します。
IMAPまたはPOP3の認証に時間がかかる
認証中、データベースでの作業は実行されません。LDAP問合せのみが実行されます。そのため、これは、ネットワークまたはLDAPのいずれかの速度が遅いことが原因と考えられます。LDAPサーバーおよびデータベースでリソースの競合が発生していないかどうかを確認してください。また、大規模なデータ変更以降にOIDStats.shが実行されたかどうかを確認してください。
受信ボックスを開く場合に時間がかかる
受信ボックスを開くための問合せでは、ES_INSTANCE表が調べられ、特定のフォルダ識別子のすべての行が収集されます。受信ボックス・フォルダのサイズが大きくなると、フェッチする必要があるブロック数も増加します。データベース問合せは、次のとおりです。
SELECT msg_id, msg_uid, msg_size, flags, unread, to _char(internal_date, 'DD-Mon-YYYY HH24:MI:SS'), msg_type FROM es_instance WHERE folder_id = :b1 ORDER BY msg_uid ASC
実行ごとのバッファ取得数が200を超える場合は、同じフォルダ識別子を一連の類似ブロックにクラスタ化する索引構成表を使用することを検討してください。また、表をfolder_idでソートして物理的に再構成すると、一時的にパフォーマンスを向上させることができます。ただし、この最適化は、時間の経過とともに効果が失われます。問合せが非常に高コスト（実行ごとのバッファ取得数が3000を超える）で、フォルダの受信ボックス・サイズが小さい（受信ボックスごとのメッセージ数が2000未満）場合は、実行計画が適切でない可能性があるため、ES_INSTANCE表を分析する必要があります。
電子メール・メッセージの読取りに時間がかかる
メール・メッセージの読取りの問合せでは、ES_BODY表のBLOB本体、ES_SHELL表のシェルおよびヘッダー・データがフェッチされた後、変更日付きでフォルダが更新されます。いずれかの選択項目の処理が遅い場合は、最後に読み取られる項目も遅くなります。Statspackでこれらのオブジェクトの待機イベントがないかどうかを確認して、問題を表示します。ディスクの入出力スループットなどのリソースの制限がないかぎり、ほとんどの場合、読取り処理が遅くなることはありません。
ピーク時に有効なユーザーが「ユーザー名またはパスワードが不正です」エラーを受信する
これは、誤ったエラー・メッセージです。実際は、LDAPプールが制限を超えていることが問題となっています。使用可能なCPUリソースがLDAPサーバー上にある場合は、IMAPプロセスのLDAPプール・パラメータの値を増やしてください。
Oracle ListenerプロセスTNSLSNRがコア・ファイルなしで終了し、ソケットへのそれ以降のすべてのリクエストが失敗する
これは、リスナーが保持するファイル記述子の数が1024を超えた場合に発生します。リスナーは、ソケット接続を受け入れた後、ファイル記述子をOracle Emailサーバー・プロセスに渡します。また、Oracle Emailプロセスに渡すまでファイル記述子を保持します。Oracle Emailプロセス・サーバーですぐに受入れができない場合は、リスナーが保持するファイル記述子の数が増加します。通常、これは、中間層に十分なCPUリソースがない場合にのみ発生します。
『Oracle Files管理者ガイド』には、Oracle Filesのパフォーマンス・チューニング情報が含まれています。次の章を参照してください。
第7章「ドメイン、ノードおよびサービスのパフォーマンスの監視」
第9章「メンテナンスおよびチューニング」
第11章「トラブルシューティング」
パフォーマンス・チューニングの詳細は、『Oracle Ultra Searchユーザーズ・ガイド』の付録A「Webクロール・プロセスのチューニング」および付録B「問合せパフォーマンスのチューニング」を参照してください。
最小システム要件の詳細は、『Oracle Web Conferencing Administration Troubleshooting』を参照してください。このドキュメントは、OTN（Oracle Technology Network）の次のURLで入手できます。
http://www.oracle.com/technology/products/ortc/pdfs/webconferencing_troubleshooting.pdf
Oracle Web Conferencingが中間層コンピュータにインストールおよび構成されている場合は、デフォルトで、1つのWeb Conferencingリスナーと4つのWeb Conferencingサーバー・プロセスが起動されます。ご使用のコンピュータがこれらの要件を上回っている場合は、プロセス数を増やしてパフォーマンスを向上させることができます。
リスナー・プロセスの数と中間層コンピュータのCPUの数は、同じである必要があります。
推奨されるサーバー・プロセス数を判別するには、次の計算式を使用してください。
Number of server processes = (amount of physical memory) / 256
