IBM Campaign のパフォーマンスのトラブルシューティング

Web アプリケーション・サーバー

• WebSphere を使用している場合は、WebSphere のプロファイルで指定される JVM ヒープ・サイズを確認します。通常は、初期設定の 512 と最大値 1024 (またはサーバー構成に応じて異なる値) で十分です。
• WebLogic を使用している場合は、JVM メモリーのヒープ・サイズ・パラメーターを 1024 に設定します。それには、次の行を setDomainEnv スクリプトに追加します。Set MEM_ARGS=-Xms1024m -Xmx1024m -XX:MaxPermSize=256m

• 特定の環境では、古い既存の対話式チャネルまたは多数の配置履歴がある対話式チャネルを配置すると、システムに負荷がかかる場合があり、2048MB 以上のキャンペーン設計時間および/または対話式ランタイム Java ヒープ・スペースが必要になる可能性があります。

  システム管理者は、以下の JVM パラメーターを使用して配置システムで使用できるメモリー量を調整できます。

  -Xms####m -Xmx####m -XX:MaxPermSize=256m

  文字 #### は 2048 以上 (システム負荷により異なります) にする必要があります。2048 より大きい値にする場合は、通常 64 ビット・アプリケーション・サーバーおよび JVM が必要です。

• WebLogic を使用している場合は、実行している Campaign のバージョンに応じて、パッチを適用しなければならないことがあります (Weblogic 10gR3 の場合)。また、WebLogic 11gR1 の場合は、キャンペーンの war ファイルを探して、特定の変更を加え、war ファイルを再ビルドしなければならないことがあります。詳しくは、実行しているバージョンの IBM Campaign のインストール・ガイドまたはアップグレード・ガイドを参照してください。また、「IBM Marketing Software 推奨されるソフトウェア環境および最小システム要件」の資料も参照してください。

データベース

• データベースがその他のアプリケーションによって高負荷になっていないか、DBA に確認してください。
• 「IBM Campaign チューニング・ガイド」で説明されているデータベースのチューニングを実行します。
• 「IBM Campaign 管理者ガイド」で説明しているデータベース・ロード・ユーティリティーを構成します。
• 新しいオーディエンス・レベルを作成するときには、そのオーディエンス・レベルに関するレスポンス履歴を保管するために、DBA が IBM Campaign システム・データベース内にテーブルを作成する必要があります。パフォーマンスを向上させるために、この新しいテーブルには索引を付けてください。

IBM Campaign のツール

• アプリケーション・サーバーから、孤立した一時ファイルやテーブルを削除します。IBM Campaign クリーンアップ・ユーティリティー (unica_acclean) を使用して、現在のパーティションの孤立した一時ファイルとデータベース・テーブルをすべて特定して削除します。クリーンアップ・ユーティリティーは、IBM Campaign システム・テーブル・データベースとユーザー・テーブル・データベースの両方で使用できます。詳しくは、「IBM Campaign 管理者ガイド」を参照してください。
• IBM Campaign Server Manager (unica_svradm) を使用して、不要な unica_acsvr プロセスがバックグラウンドで実行されていないか確認します。Status コマンドは、切断されたプロセスや孤立したプロセスを特定します。kill コマンド (kill -p processid#) は、不要なプロセスを削除します。利用可能なコマンドと構文のリストは、Help コマンドを使用するか、「IBM Campaign 管理者ガイド」を参照してください。

ログ中

• log4j.properties ファイルで、ロギング・レベルが DEBUG に設定されていないことを確認します。このファイルは、IBM Campaign では <Campaign_home>/conf/campaign_log4j.properties で IBM Marketing Platformでは <Platform_home>/conf/log4j.properties です。
• 構成プロパティー Campaign|partitions|partition [n]|server| logging|loggingLevels が ALL に設定されていないことを確認します。この設定にすると大量のデータが生成されるため、実稼働実稼働にはお勧めできません。
• ロギング・レベルをデフォルトより高く設定すると、パフォーマンスに悪影響が及ぶ可能性があります。
• IBM Campaign ログ・ファイルを調べて、考えられる問題を特定してください。例えば、繰り返し発生する警告を探します。リスナー、Web アプリケーション、Web 接続、フローチャート、セッションやアプリケーションの他の領域のログ・ファイルがあります。デフォルトで、ほとんどのログ・ファイルは <Campaign_home>/logs と <Campaign_home>/partitions/partition [n]/logs にあります。クラスター化リスナー構成の場合は、追加のログ・ファイルが <campaignSharedHome> の下の同等のディレクトリーにあります。詳しくは、「IBM Campaign 管理者ガイド」のロギングの管理に関する部分を参照してください。

構成

• 「IBM Campaign チューニング・ガイド」で説明するように、パフォーマンス関連の構成設定を調整します。
• Campaign|caching カテゴリーの構成プロパティーを探して (例: offerTemplateDataTTLSeconds)、キャッシュがリフレッシュされている頻度を確認します。デフォルト値は 600 (10 分) です。値が小さいほど、キャッシュが更新される頻度が高くなりますが、Web サーバーとデータベースの両方の処理リソースを消費するので、パフォーマンスに悪影響が及ぶ可能性があります。構成プロパティーについての説明が、「IBM Campaign 管理者ガイド」に記載されています。

レポート

ダッシュボードに IBM Cognos のレポートがある場合、レポートは追加の処理リソースを必要とすることに注意してください。多数のレポートが含まれるダッシュボードに多数のユーザーが定期的にアクセスする場合は、パフォーマンスが問題になる場合があります。IBM Cognos レポート・ポートレットは、リソースへ負荷が最も高いものです。

パフォーマンスを向上するには、IBM Cognos を使用してレポートのスケジュールを設定してから、IBM Marketing Platform でポートレットがスケジュールを使用するよう設定します。詳しくは、「IBM Marketing Platform 管理者ガイド」の IBM Cognos のレポートのパフォーマンスの考慮事項に関する部分を参照してください。

フローチャート

• 「IBM Campaign チューニング・ガイド」で説明されているデータベース内最適化を使用します。
• 「IBM Campaign チューニング・ガイド」で説明するように、フローチャートのパフォーマンスに影響する構成設定を調整します。
• あるテーブルからフィールドを選択して以降の処理で使用するために別のテーブルにそれらのフィールドを書き出すために、抽出プロセスの使用を検討します。抽出プロセスは大量データを後続操作のために扱いやすいサイズに削減することを目的としており、これによってパフォーマンスが向上する可能性があります。詳しくは、「IBM Campaign ユーザー・ガイド」を参照してください。
• フローチャートのスケジュール・プロセスを使用する代わりに、IBM Marketing Software スケジューラーを使用します。IBM Marketing Software スケジューラーは、フローチャートが実行されていないときにはサーバー・システムのリソースを消費しないので、より効率的です。

  多数のプロセスがシステムに高い要求を行うときは、スロットルを使用してパフォーマンスを管理します。スロットルは、「設定」>「構成」ページでセットアップするスケジューラー・グループに基づきます。グループに制限しきい値を割り当て、スケジュールをそのグループに関連付けます。詳しくは、「IBM Marketing Platform 管理者ガイド」を参照してください。

• 「オーディエンス ID」フィールドなど、値がほとんど固有のフィールドは、プロファイルを作成しないでください。個別の値が少数のフィールドでは、プロファイル機能がかなり効率的 (および便利) です。

テーブル・マッピング

• 戦略的セグメントを使用するフローチャートか IBM Contact Optimization セッションでオーディエンスを使用する計画の場合のみ、オーディエンスのセグメント・メンバーシップ・テーブルをマップします。戦略的セグメントは、複数のフローチャートまたはセッションで使用できる永続セグメントです。セッション・フローチャートで CreateSeg プロセスを実行して結果を保存することで、戦略的セグメントを作成します。戦略的セグメントを使用しない場合は、セグメント・メンバーシップ・テーブルをマップしないでください。IBM Campaign フローチャートまたは Contact Optimization セッションでの戦略的セグメントの使用はオプションです。セグメント・メンバーシップ・テーブルをマップする場合、IBM Campaign または Contact Optimization は、フローチャートまたは Optimize セッションを実行するたびに、テーブルを更新します。戦略的セグメントを使用していない場合、これは処理上の不要なオーバーヘッドとなります。詳しくは、「IBM Campaign 管理者ガイド」を参照してください。
• ユーザー・テーブルをマップする場合、「リアルタイム・プロファイルを許可する」オプションは、ユーザーが「プロファイル」をクリックするたびにデータベース照会も必要になるため、パフォーマンスが低下する可能性があります。「リアルタイム・プロファイルを許可する」は、チェック・マークを付けたテーブル・フィールドだけではなく、すべてのテーブル・フィールドに適用されます。ユーザー・テーブルは、いつでも再マップしてプロファイルの特性を変更できます。詳しくは、「IBM Campaign 管理者ガイド」を参照してください。

ネットワークとコンポーネント

• ネットワーク・モニター・ツールを使用して、考えられる問題を特定します。以下に例を示します。

  netstat (ネットワーク統計) は、ネットワーク接続 (着信と発信の両方)、ルーティング・テーブル、ネットワーク・インターフェースの統計を表示するコマンド・ライン・ツールです。このユーティリティーは、UNIX と Linux オペレーティング・システムの両方で利用できます。

  tracert (Windows) /traceroute (UNIX) は、経路のパスを表示し、ネットワーク間のパケットの遅延を測定するネットワーク診断ツールです。

• Windows パフォーマンス・モニターは、プロセッサー、メモリー、ディスク、およびネットワークの使用状況に関するレポートを生成できます。
• IBM Interact を使用している場合、SSL を使用して通信するよう Interact のいずれかの部分を構成すると、パフォーマンス・コストが発生します。IBM では、Interact で SSL を使用するように構成しないことをお勧めします。
• (WebSphere または WebLogic の両方のアプリケーション・サーバー・レベルでの) ストレージ・デバイスまたはアプライアンスの速度がパフォーマンスに影響を与えるため、調べることもできます。
• いろいろなアプリケーションと同様に、ソフトウェアとハードウェアを再始動することで、問題が解決することがよくあります。リスナーを再始動してみてください。また、Web アプリケーション・サーバーの再始動も試してください。場合によっては、物理サーバーのリブートも必要である可能性があります。