Rational Asset Manager のパフォーマンスのチューニング

IBM® Rational® Asset Manager のパフォーマンスは、アプリケーション・サーバー、データベース、Web サーバー、キャッシング・プロキシー、ロード・バランサー、およびオペレーティング・システムのチューニング方法に大きく左右されます。このセクションでは、これらのシステムと Rational Asset Manager のチューニング方法に関するガイドラインを示します。 すべての設定を説明することはできませんが、これは Rational Asset Manager に対する大きなユーザー負荷を解消するための開始点です。

Rational Asset Manager のチューニング

このセクションでは、各種の構成でサポート可能な予想されるユーザー負荷やハードウェア・セットアップについては扱いません。 この情報については、Rational Asset Manager のキャパシティー・プランニング・ガイド (Capacity Planning Guide) を参照してください。

Rational Asset Manager の構成ページにある設定を調整することで、最適なパフォーマンスを実現できます。 このページには、リポジトリー管理者がアクセスできます。
表 1. 各プラットフォーム共通の Rational Asset Manager チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
アセットの検索時に応答が遅い ローカル・フォルダーおよび索引フォルダー / リモート・フォルダーおよび共用フォルダーを使用しない

最適なパフォーマンスを得るために、各アプリケーション・サーバーには、そのコンピューターのローカル・ハード・ディスク上に専用のローカル・フォルダーおよび索引フォルダーが必要です。このドライブは、アプリケーション・サーバーやオペレーティング・システムがインストールされているハード・ディスクと同じであってはいけません。

このパラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートし、「ディスク・ストレージ」セクションで、「ローカル・フォルダー」および「索引フォルダー」の各パラメーターを設定します。

アセットの検索時に応答が遅い 人気指標 / 使用不可にする

検索エンジンでは、アセットの人気 (表示回数やダウンロード回数など) を考慮してより関連性の高い検索結果を提供することができますが、これにより大規模リポジトリーのパフォーマンスに影響を与える場合があります。

人気指標を使用不可にするには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートして、「パフォーマンス・オプション」セクションで「人気指標を使用可能にします」チェック・ボックスのチェックを外します。

アセットの検索時に応答が遅い 索引フォルダー / 索引フォルダー専用の高速ドライブを使用する

索引フォルダーは、他の目的には使用されない専用ドライブ上にあることが重要です。ローカル・フォルダーと索引フォルダーを分離することによって、アセット検索時の応答時間を確実に短縮することができます。

このパラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートして、「ディスク・ストレージ」セクションで、「索引フォルダー」パラメーターを設定します。

一般的なパフォーマンス問題が定期的に発生する 統計索引ビルダーのスケジュール / 10 分

統計索引ビルダーを頻繁に実行すると、パフォーマンスが低下します。 ほとんどの環境では、デフォルト設定の 10 分間隔で問題ありません。

パラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」 をクリックします。次に、「ジョブ・スケジュール」セクションで、「統計索引ビルダーのスケジュール」を見つけ、「編集」をクリックします。

一般的なパフォーマンス問題が定期的に発生する プロセス・サブスクリプションのスケジュール / ワークロードが小さい時間帯に設定する

サブスクリプションはカスタム間隔で処理できます。 パフォーマンスを高めるには、この間隔を、Rational Asset Manager で発生しているワークロードが比較的小さい 時間帯に設定します。

パラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートします。次に、「ジョブ・スケジュール」セクションで、「プロセス・サブスクリプションのスケジュール」を見つけ、「編集」をクリックします。

一般的なパフォーマンス問題が定期的に発生する ユーザー/グループ情報の更新スケジュール / ワークロードが小さい時間帯に設定する

ユーザーとグループの情報はカスタム間隔で処理できます。 パフォーマンスを高めるには、この間隔を、Rational Asset Manager で発生しているワークロードが比較的小さい 時間帯に設定します。

パラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートします。次に、「ジョブ・スケジュール」セクションで、「ユーザー/グループ情報更新のスケジュール」を見つけ、「編集」をクリックします。

一般的なパフォーマンス問題が定期的に発生する レビュー・プロセスの通知スケジュール / ワークロードが小さい時間帯に設定する

レビュー・プロセスの通知はカスタム間隔で処理できます。 パフォーマンスを高めるには、この間隔を、Rational Asset Manager で発生しているワークロードが比較的小さい 時間帯に設定します。

パラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートします。次に、「ジョブ・スケジュール」セクションで、「レビュー・プロセスの通知スケジュール」を見つけ、「編集」をクリックします。

ログ内のメモリー不足エラー - セッションの問題 ユーザー当たりの最大セッション数 / 10

1 人のユーザーがサーバー上で使用可能なすべてのセッションを使い果たしてしまうことがあります。原因として考えられるのは、質の悪いスクリプトまたはサービス妨害攻撃です。この問題の発生を防ぐために、ユーザー当たりの最大セッション数はデフォルトで 10 に設定されています。 この制限に達したユーザーは、それ以降サーバー上で新しいセッションを作成できなくなります。

このパラメーターを設定するには、Rational Asset Manager に管理者としてログインし、「管理」 > 「構成」にナビゲートして、「パフォーマンス・オプション」セクションで、「ユーザー当たりの最大セッション数」パラメーターを設定します。

アセットの登録に時間がかかる アセット登録におけるフィーチャー・コンテンツを自動的に作成します / 使用不可にする

アセットを登録する際に、Rational Asset Manager により、アセットに付加される成果物のサムネール・イメージが作成されます。アセットに多数の成果物が含まれる場合、アセットの登録に長時間かかることがあります。

サムネールの自動作成を使用不可にするには、Rational Asset Manager にリポジトリー管理者としてログインし、「管理」 > 「構成」にナビゲートして、「パフォーマンス・オプション」セクションで、「アセット登録におけるフィーチャー・コンテンツを自動的に作成します」チェック・ボックスのチェックを外します。

上記のパラメーターに加えて、管理者は、「管理」 > 「ツール」 > 「ジョブ状況の表示」にナビゲートすることで、Rational Asset Manager 内の「ジョブの状況」ページにアクセスできます。このページでは、Rational Asset Manager Asset Manager のパフォーマンスに影響を与える可能性のある実行中のジョブや実行済みのジョブが表示されます。 「ジョブ状況」ページには、エラー・メッセージも表示されることがあります。

アプリケーション・サーバーのチューニング

Rational Asset Manager はアプリケーション・サーバーと緊密に連係動作するため、アプリケーション・サーバーの設定を最適化することで Rational Asset Manager のパフォーマンスが向上します。

このセクションでは、特に、パフォーマンスに大きな影響を与える IBM WebSphere® Application Server バージョン 7.0 の設定について説明します。これらの設定は WebSphere Application Server 7.0 上でも調整できますが、これらのパラメーターを設定する手順は異なる場合があります。
重要: どのパラメーターを変更する前にも、WebSphere Application Server のプロファイルをバックアップしてください。
表 2. 各プラットフォーム共通の WebSphere Application Server チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
セッション・タイムアウトの問題 メモリー内の最大セッション・カウント / デフォルト

デフォルトでは、WebSphere Application Server は最大で 1000 件のセッションをメモリー内に保持します。ただし、「オーバーフローの許可」オプションも選択されているため、追加のセッションが 2 次セッション・テーブルに格納されます。 1000 件を超えるメモリー内セッションが予想される場合は、2 次セッション・テーブルの値を大きくする必要があります。

メモリー不足エラーを回避するためにセッションの数を制限する場合は、「オーバーフローの許可」チェック・ボックスを選択解除して、メモリー内の最大セッション・カウントをシステムに適した設定値に設定するようにしてください。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「アプリケーション・サーバー」 > 「サーバー・タイプ」 > サーバー名 > 「セッション管理」 > 「メモリー内の最大セッション・カウント」にナビゲートします。

ログ内のメモリー不足エラー Java 仮想マシンのヒープ・サイズ / 1300 から 2000 の間

4 GB のメモリーが搭載されたサーバーでは、1300 MB のヒープ・サイズを持つインスタンスを 2 つ指定するか、2000 MB のヒープ・サイズを持つインスタンスを 1 つ指定できます。 システム・ページングを監視して、十分な使用可能メモリーがあることを確認する必要があります。 サーバーに 8 GB のメモリーが搭載されている場合は、それぞれが 2000 MB のヒープ・サイズを持つインスタンスを 2 つ指定します。

このパラメーターを設定するには、WebSphere 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 > 「初期ヒープ・サイズ」および「最大ヒープ・サイズ」にナビゲートします。

この設定を Rational Asset Manager サーバーに適用する必要があることに注意してください。 IBM Rational Team Concert サーバーに必要な設定は 768MB (これはデフォルト値です) で、最大設定は 2048MB です。 クラスターでは、必要に応じて IBM Rational Team Concert サーバーが専用のノードにインストールされる場合があります。

ログ内のメモリー不足エラー - セッションの問題 セッション・タイムアウト / デフォルト (30 分)

WebSphere Application Server 内のセッション・タイムアウトのデフォルト値は 30 分です。 この値をより短い時間に設定すると、特に多数のユーザーが短時間のトランザクションを実行する環境では、より多くのユーザーをサポートできるようになります。 この値を小さくしすぎると、ユーザーが大きいアセットをアップロードできなくなる可能性があります。 ほとんどのユーザーは、トランザクションの実行が終了しても明示的にログアウトせず、ほとんどのセッションはタイムアウトするまで存在しているということを念頭に置いてください。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > 「サーバー名」 > 「セッション管理」 > 「タイムアウトの設定」にナビゲートします。

おそらく非同期エラーまたは入出力エラーが原因で、大規模アセットのダウンロードに失敗する HTTP インバウンド・チャネル (HTTP 2) の書き込みタイムアウト / 300 秒

WebSphere Application Server でのサーバーからクライアントへの書き込みのタイムアウトのデフォルト値は、60 秒です。この値をより長い時間に設定すると、特にファイルをダウンロードしているクライアントの接続速度が遅い場合、または送信している要求が多い場合に、ファイルのダウンロード時の失敗を防止できます。

このパラメーターを変更するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > サーバー名 > 「ポート」 > 「関連トランスポートの表示」(Rational Asset Manager 用に使用しているポート。例えば、9080) > 「WCInboundDefault」 > 「HTTP インバウンド・チャネル (HTTP 2)」 > 「書き込みタイムアウト」にナビゲートします。

定期的に低速になる / ガーベッジ・コレクションが原因でパフォーマンス・スパイクが発生する クラス・ガーベッジ・コレクション / Xgcpolicy:optavgpause (WebSphere Application Server v6.1 フィックスパック 16 以下の場合) または -Xgcpolicy:gencon (WebSphere Application Server v7 および v6.1 フィックスパック 17 以上 の場合)

特定のサーバー環境やワ ークロードには、他のガーベッジ・コレクション設定 のいずれかが適している可能性があります。 ガーベッジ・コレクション設定について詳しくは、http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html を参照してください。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > サーバー名 > 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」 > 「汎用 JVM 引数」にナビゲートします。

大容量ファイルの転送中にサーバーに障害が発生 (メモリー不足か、ログ内で malloc エラーが発生した可能性あり) Web コンテナーのカス タム・プロパティー channelwritetype / 同 期データ転送 (sync) 非同期データ転送を使用す ると、TCP/IP 接続経由でデータを送信するのに、過剰な数のバッファーが必要な場合があります。
  1. WebSphere Application Server 管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > サーバー名 > 「Web コンテナー設定」 > 「Web コンテナー」 > 「カスタム・プロパティー」にナビゲートします。
  2. 「新規」をクリックします。
  3. 以下のペアを追加します。
    • 名前: com.ibm.ws.webcontainer.channelwritetype
    • 値: sync
OK」をクリックして、構 成を保存します。 アプリケーション・サーバーを再始 動して、プロパティーを有効にします。
デプロイメント・マネー ジャーの場合:
  1. 以下のように、対話式の wsadmin セッションを開始します。
    dmgr-profile-root¥bin>wsadmin -lang jacl
  2. 以下の数行をコピーして、wsadmin> プロンプトで一度に貼り付けます。
    set dmgr [$AdminConfig getid /Server:dmgr/]
    set webcontainer [$AdminConfig list WebContainer $dmgr]
    $AdminConfig create Property $webcontainer {{name com.ibm.ws.webcontainer.channelwritetype} {value sync}} properties
    $AdminConfig show $webcontainer
    $AdminConfig save
  3. デプロイメント・マネージャーを再始動して、プロパティーを取得します。

詳しくは、 http://www.ibm.com/support/docview.wss?uid=swg21317658 を参照してください。

CPU の使用率が高い パフォーマンス・モニター・インフラストラクチャー / 無効

デフォルトでは、WebSphere Application Server では基本パフォーマンス・モニター・インフラストラクチャー (PMI) が有効になっています。 PMI はアプリケーション・サーバーをチューニングするための便利なツールですが、最大のパフォーマンスを得るには、サーバーを適切にチューニングした後にこの機能を無効にしてください。 PMI は、すべてのインスタンスとノード・エージェントに対して無効にする必要があります。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「モニターおよびチューニング」 > 「Performance Monitoring Infrastructure (PMI)」 > サーバー名 > 「Performance Monitoring Infrastructure (PMI) を使用可能にする」にナビゲートします。

データベース接続エラー JDBC 最大接続数 / 100

Rational Asset Manager にログインしているすべてのユーザーをサポートするために十分な数の JDBC 接続を使用できることを確認します。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「リソース」 > 「JDBC」 > 「データ・ソース」 > 「<Rational Asset Manager のデータ・ソース>」 > 「接続プール・プロパティー」 > 「最大接続数」にナビゲートします。

DB2® のチューニングのセクションにある『MAXAPPLS および MAXAGENTS パラメーター (MAXAPPLS and MAXAGENTS parameters)』というトピックも参照してください。

オペレーティング・システムのチューニングのセクションにある『AIX® および Linux の最大プロセス数 (Maximum number of processes for AIX and Linux)』というトピックも参照してください。

一般的なパフォーマンス問題 準備済みステートメントのキャッシュ通知 / 100

WebSphere Application Server は、頻繁に使用される準備済みステートメントをキャッシュに格納する機能を備えています。 キャッシュに格納されたステートメントが破棄される場合は、WebSphere Application Server で PMI をオンにして、この値を大きくします。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「リソース」 > 「JDBC」 > 「データ・ソース」 > 「<Rational Asset Manager のデータ・ソース>」 > 「WebSphere Application Server データ・ソース・プロパティー」 > 「ステートメント・キャッシュ・サイズ」にナビゲートします。

WebSphere Application Server のチューニングについての追加情報 (Further Information for Tuning WebSphere Application Server)』というトピックも参照してください。

表 3. AIX / Linux 用の WebSphere Application Server Web サーバー・チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
CPU の使用率が高すぎるか低すぎる WebContainer プール / 30

Web コンテナー・スレッドは、アプリケーション・サーバーが要求を処理するために使用します。 サーバーの CPU の使用率が低すぎる場合は、この値を大きくしてください。 CPU の使用率が高すぎる場合は、この値を小さくしてください。 Web コンテナー・スレッド数は、50 より大きく設定してはいけません。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > サーバー名 > 「スレッド・プール」 > 「WebContainer」にナビゲートします。

最小サイズ: 15

最大サイズ: 30

表 4. Windows 用の WebSphere Application Server チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
CPU の使用率が高すぎるか低すぎる WebContainer プール / 50

Web コンテナー・スレッドは、アプリケーション・サーバーが要求を処理するために使用します。 サーバーの CPU の使用率が低すぎる場合は、この値を大きくしてください。 CPU の使用率が高すぎる場合は、この値を小さくしてください。 Web コンテナー・スレッド数は、50 より大きく設定してはいけません。

このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > サーバー名 > 「スレッド・プール」 > 「WebContainer」にナビゲートします。

最小サイズ: 25

最大サイズ: 50

これらのパラメーターに加えて、パフォーマンス・モニター・インフラストラクチャー (PMI) を有効にすることで、特定のワークロード下の WebSphere Application Server をチューニングできます。 これにより、パフォーマンス・データを示す詳細なグラフが得られます。 データを取り込むために、通常のワークロードでも PMI を有効にする必要がありますが、その結果としてパフォーマンスが低下するため、データ取り込みの完了後には PMI を無効にする必要があります。

PMI を使用可能にするには、WebSphere Application Server 管理コンソールにログインして、「モニターおよびチューニング」 > 「Performance Monitoring Infrastructure (PMI)」 > サーバー名 > 「Performance Monitoring Infrastructure (PMI) を使用可能にする」にナビゲートします。

データベース・サーバーのチューニング

Rational Asset Manager のパフォーマンスを向上させるには、以下のパラメーターおよび値を指針として、データベースをチューニングする必要があります。ただし、サーバー・セットアップ・アプリケーションを使用して Rational Asset Manager をインストールする場合、このセクションで提供されているパフォーマンス・チューニング設定値が設定されるため、これらの推奨される設定値を使用する場合は、このセクションをスキップできます。

注: このセクションでは、DB2 バージョン 9.7 を対象としていますが、ここで紹介するパラメーターの多くは他のバージョンの DB2 でも使用できます。 Oracle や SQL Server でも同様のパラメーターが用意されている可能性があります。
表 5. 各プラットフォーム共通の DB2 チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
使用可能な接続がない MAXAPPLS / AUTOMATIC (WebSphere Application Server の最大 JDBC 接続数 × インスタンス数)

MAXAPPLS の値が、アプリケーション・サーバーで指定されている JDBC 接続プールの数を処理するのに十分な大きさであることを確認します。 MAXAPPLS の設定値は、JDBC 最大接続数の設定値以上である必要があります。

設定場所: データベース・パラメーター

アプリケーション・サーバーのチューニングのセクションにある『JDBC 最大接続数』というトピックも参照してください。

使用可能な接続がない MAXAGENTS / AUTOMATIC (WebSphere Application Server の最大 JDBC 接続数 × インスタンス数)

これは DB2 バージョン 9.5 以前のための設定であるため、DB2 バージョン 9.7 では使用できません。

MAXAGENTS の値が、アプリケーション・サーバーで指定されている JDBC 接続プールの数を処理するのに十分な大きさであることを確認します。 MAXAGENTS の設定値は、JDBC 最大接続数の設定値以上である必要があります。

設定場所: インスタンス・パラメーター

アプリケーション・サーバーのチューニングのセクションにある『JDBC 最大接続数』というトピックも参照してください。

デッドロック MAXLOCKS / AUTOMACTIC (80)

MAXLOCKS パラメーターは、アプリケーションが保持できる DB2 内の使用可能ロックの最大パーセントを指定します。このパーセントを超えると、行ロックがテーブル・ロックにエスカレートします。 これらのテーブル・ロックはデッドロックを引き起こす可能性があります。

設定場所: データベース・パラメーター

デッドロック LOCKLIST / AUTOMATIC (20000)

LOCKLIST パラメーターは、DB2 内のロック用に使用できるメモリー量を指定します。 次の式を使用して、特定の環境にこのパラメーターを設定します。

LOCKLIST = [(512 × 64 × MAXAPPLS) / 4096] × 2

このパラメーターは、DB2 で使用できるメモリー・ヒープ・サイズより大きい値に設定してはいけません。 設定場所: データベース・パラメーター

デッドロック LOCKTIMEOUT / 60

単一のロックが他のトランザクションを停止している場合は、その結果としてデッドロックが発生する可能性があります。 これを防止するには、ロックのタイムアウトを 60 秒に設定します。

設定場所: データベース・パラメーター

一般的なパフォーマンス問題 統計 / 定期的な実行をスケジュールする テーブルに対して統計を実行すると、最適化プログラムは、データにアクセスするための最適なパスを決定しやすくなります。 統計は、定期的に実行するか、スケジュールに基づいて自動的に実行する必要があります。
データベース移行時のエラー LOG_FIL_SIZ / 10000 Rational Asset Manager の移行機能は、LOG_FIL_SIZ の設定値が小さすぎる何千ものアセットが含まれたデータベースでは正常に実行できない場合があります。
表 6. AIX / Linux 用の DB2 チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
DB2 サーバーにアクセスできない *オペレーティング・システムのチューニングのセクションにある『AIX および Linux の最大プロセス数 (Maximum number of processes for AIX and Linux)』というトピックを参照してください。 DB2 サーバーにアクセスできない場合は、db2agents が最大プロセス数を使用済みである可能性があります。
各自の環境で確認すべき他のパラメーターの例としては、以下が挙げられます。
  • APP_CTLHEAP_SZ
  • DATABASE_MEMORY
  • DFT_PREFETCH_SZ
  • NUM_IOCLEANERS
  • NUM_IOSERVERS
  • SORTHEAP
  • MAX_QUERYDEGREE
これらのすべてのパラメーターが、すべての環境で使用可能であるわけではありません。

DB2 で各種のパラメーターを AUTOMATIC に設定すると、それらのパラメーターが現在のワークロードに基づいて自動的にチューニングされるようになります。 このように設定すると、最初は、特定のパラメーター値のチューニングが遅れた場合にパフォーマンスが低下したりエラーが発生したりする可能性がありますが、この設定は、最大のパフォーマンスを実現するためにチューニングが必要なパラメーターを特定するための便利な方法です。

パラメーターの値を大きくしすぎて、DB2 のコントロール・センターを起動できない場合は、DB2 のコマンド行で「db2 update db cfg for db_name using parameter_name value」というステートメントを実行することで、そのパラメーターを変更できます。

その他の参考資料:
  • DB2 は、ここではスペースの都合により紹介できなかった多くのチューニング・パラメーターを持つ複雑なシステムです。 DB2 のチューニングに関する最も詳しい資料の 1 つは、「Best Practices for Tuning DB2 UDB V8.1 and its Databases」(Fraser McArthur 著) です。 http://www.ibm.com/developerworks/db2/library/techarticle/dm-0404mcarthur/

Web サーバーのチューニング

このセクションでは、WebSphere Application Server の補足パッケージに含まれている IBM HTTP Web Server のチューニング情報を提供します。

このセクションで説明するパラメーターは、httpd.conf ファイル内で変更できます。

表 7. 各プラットフォーム共通の Web サーバー・チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
接続終了エラー MaxKeepAliveRequests / 0 このディレクティブは、単一のクライアントが発行できる要求の最大数を指定します。この最大数を超えると接続が自動的に終了します。 一般に、この値は 0 に設定されています。
一般的なパフォーマンス問題 LoadModule / ibm_afpa_module modules/mod_afpa_cache.so
注: この設定値の使用は IHS 7 の時点で非推奨になったため、有効にすべきではありません。http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_cacheenable.htmlを参照してください。
イメージなどの静的コンテンツをキャッシュに格納するには、次の行をコメントを外します。
LoadModule ibm_afpa_module modules/mod_afpa_cache.so

これにより、Fast Response Cache Accelerator (FRCA) が有効になります。

一般的なパフォーマンス問題 Afpa ロギング / オフ
注: この設定値の使用は IHS 7 の時点で非推奨になったため、有効にすべきではありません。
FRCA ロギングをオンにする必要がない場合は、AfpaLogFile ディレクティブの前にコメント文字 (#) を挿入することで FRCA ロギングをオフにできます。 これにより、サーバーのパフォーマンスを向上させることもできます。
#AfpaLogFile "_path_to_server_/logs/afpalog" V-ECLF
表 8. AIX / Linux 用の Web サーバー・チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
Web サーバー・ログ内のスレッド不足エラー ThreadLimit / 25 Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。
Web サーバー・ログ内のスレッド不足エラー ThreadsPerChild / 25 Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。
表 9. Windows 用の Web サーバー・チューニング・パラメーター
問題 パラメーター / 設定 詳細情報
Web サーバー・ログ内のスレッド不足エラー ThreadLimit / 4000 Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。
Web サーバー・ログ内のスレッド不足エラー ThreadsPerChild / 3000 Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。

キャッシング・プロキシー・サーバーのチューニング

このセクションでは、IBM Edge Caching Proxy を対象にして説明します。 DMZ キャッシング・プロキシー・サーバー構成についての情報は、『DMZ キャッシング・プロキシー・サーバーの構成』セクションを参照してください。

この文書で説明しているパラメーターは、ibmproxy.conf ファイル内で変更できます。

表 10. IBM Edge Server のチューニング・パラメーター
問題 パラメーター / 設定 詳細情報
ファイル・サイズが大きいアセットをアップロードできない LimitRequestBody / 2G デフォルトでは、このパラメーターは 10 M に設定されています。 この値を大きくして、ユーザーが大きいファイルをアップロードできるようにします。
タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない InputTimeOut / 60 分

このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。

アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。

タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない ReadTimeout / 60 分

このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。

アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。

タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない ScriptTimeout / 60 分

このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。

アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。

表 11. その他の設定
パラメーター 設定
SendRevProxyName yes
PurgeAge 3
DirShowCase off
MaxActiveThreads 110
ConnThreads 15
MaxPersistRequest 15
ServerConnPool on
CacheMemory 1200 M (最大)
CacheAlgorithm responsetime
Numclients 100
flexibleSocks off
ListenBacklog 256

DMZ キャッシング・プロキシー・サーバーの構成

パフォーマンスを向上させるには、以下のキャッシング・プロキシー・サーバーのガイドラインに従ってください。

  • ファイル /DMZ-install-dir/profiles/SecureProxySrv01/config/cells/cell-name/nodes/node-name/servers/proxy1/server.xml で、以下の手順を実行できます。
    • PMI (パフォーマンス・モニター) を無効にします。
      <services xmi:type="pmiservice:PMIService" 
      xmi:id="PMIService_1243598970603" 
      enable="false" 
      initialSpecLevel="" 
      statisticSet="basic" 
      synchronizedUpdate="false" />
    • トレース・サービスを「BASIC」に設定します。
      <services xmi:type="traceservice:TraceService"
      xmi:id="TraceService_1243598970603" 
      enable="true" 
      startupTraceSpecification="*=info" 
      traceOutputType="SPECIFIED_FILE" 
      traceFormat="BASIC" 
      memoryBufferSize="8"> 
        <traceLog xmi:id="TraceLog_1243598970603"
       fileName="$(SERVER_LOG_ROOT)/trace.log"
       rolloverSize="40"
       maxNumberOfBackupFiles="10" />  
      </services>  
    • 診断サービスを無効にします。
      <services xmi:type="diagnosticproviderservice:DiagnosticProviderService" 
      xmi:id="DiagnosticProviderService_1243598970603" 
      enable="false" 
      startupStateCollectionSpec=".*:.*=0" />
  • ファイル /DMZ-install-dir/profiles/SecureProxySrv01/config/cells/cell-name/nodes/node-name/servers/proxy1/proxy-settings.xml で、outboundRequesttimeout の値をデフォルト値のままにします。
    <proxy:ProxySettings 
    xmi:id="ProxySettings_1243598971020" 
    enableCaching="false" 
    cacheInstanceName="proxy/DefaultCacheInstance" 
    outboundRequestTimeout="1800" 
    connectionPoolEnable="true" 
    maxConnectionsPerServer="0" 
    enableLogging="true" 
    outboundConnectTimeout="10000" 
    enableCustomErrorPagePolicy="false" 
    enableStaticRouting="true">
      <properties xmi:id="Property_1243847354992" 
    name="http.routing.sendReverseProxyNameInHost" 
    value="true" description="" 
    required="false" 
    validationExpression="" /> 
    - <routingPolicy xmi:id="RoutingPolicy_1243598971020">
    - <routingRules xmi:id="RoutingRule_1243847354917"
    name="local_port81_rule" 
    isEnabled="true" 
    virtualHostName="port_80" 
    uriGroup="local81_all">
      <routingAction xmi:type="proxy:GenericClusterRoute" 
    xmi:id="GenericClusterRoute_1243847354926" 
    genericServerClusterName="local81_http_cluster" /> 
      </routingRules>
      </routingPolicy>
      <staticCachePolicy xmi:id="StaticCachePolicy_1243598971020" /> 
      <staticFileServingPolicy xmi:id="StaticFileServingPolicy_1243598971020" /> 
      </proxy:ProxySettings>

    低速接続で大容量ファイル (1 GB 以上) をアップロード中に、DMZ プロキシー・サーバーにより 504 タイムアウト・エラーが返される場合があります。 このエラーは Rational Asset Manager の問題を示すものではなく、アップロードは正常に完了します。それでも 504 エラーを回避するには、outboundRequesttimeout の値を大きくしてください。

オペレーティング・システムのチューニング

各プラットフォーム共通:
  • ページ・ファイル・サイズが 2 GB 以上であることを確認します。
  • AIX システムでは、WebSphere が配置されているディスクとは異なるディスク上にページング・ファイルを定義してください。

    これらが別々に配置されるようにするには、WebSphere のインストール先を決定してから、swap -l または lsps -a を実行します。

Windows:

表 12. Windows オペレーティング・システムの設定
問題 パラメーター / 設定 詳細情報
Rational Performance Tester によるテスト中に「アドレスは使用中です (Address already in use)」というエラーが表示される レジストリー項目 MaxUserPort / 65534
注: この設定は、Rational Asset Manager サーバーではなく、Rational Performance Tester クライアント上で変更する必要があります。
  1. レジストリー・エディターで、My Computer¥HKEY_LOCAL_MACHINE¥ SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters にナビゲートします。
  2. 「パラメーター」を右クリックして、「新規」 > 「DWORD 値」をクリックします。
  3. この DWORD 値の名前として「MaxUserPort」と入力します。
  4. この値を右クリックして、「変更」をクリックします。
  5. 値を「65534」に設定します。
  6. 「ベース」で「10 進数」を選択します。
  7. コンピューターをリブートします。
セッション可用性のボトルネックを回避する方法 (6 インスタンスのクラスター上で 900 人のユーザーがいる場合に発生) レジストリー項目 TcpTimedWaitDelay / 30
  1. レジストリー・エディターで、My Computer¥HKEY_LOCAL_MACHINE¥ SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters にナビゲートします。
  2. 「パラメーター」を右クリックして、「新規」 > 「DWORD 値」をクリックします。
  3. この DWORD 値の名前として「TcpTimedWaitDelay」と入力します。
  4. この値を右クリックして、「変更」をクリックします。
  5. 値を「30」に設定します。
  6. 「ベース」で「10 進数」を選択します。
  7. コンピューターをリブートします。

AIX/Linux

以下の説明は、AIX を対象にしています。

最大プロセス数

ユーザーが実行できるプロセスの最大数は、十分に大きい値に設定する必要があります。 このことは、多数のデータベース・エージェントが配置されている可能性のあるデータベース・サーバーに特に当てはまります。

設定されている最大プロセス数を表示するには、次のコマンドを使用します。
lsattr -E -l sys0 -a maxuproc
最大プロセス数を設定するには、次のコマンドを使用します。
chdev -l sys0 -a maxuproc=2000
このコマンドを実行すると、システムの再始動後に上限数が 2000 に設定されます。

ファイル記述子

/etc/security/limits ファイルで、次のようにすべての設定を無制限に変更します。 これらの設定を変更することの影響は、ログインしているユーザーやサービスを使用しているユーザーによって異なるため、変更内容がすべてのユーザーに適用されるように、変更内容をデフォルトのユーザーに設定します。
Soft FILE Size      -1
Soft CPU Time       -1
Soft STACK Size     -1
Soft CORE File Size -1
Hard FILE Size      -1
Hard CPU Time       -1
Hard STACK Size     -1
Hard CORE File Size -1
この変更は、ulimit コマンドを使用して行うこともできます。
表 13. AIX/Linux オペレーティング・システムの設定
問題 パラメーター / 設定 詳細情報
外部 DNS が使用される /etc/netsvc.conf netsvc.conf ファイルに次の行を追加します。
hosts=local,bind4
イーサネット・アダプターがセグメンテーション・オフロードを実行する
no -o tcp_recvspace=65536
no -o tcp_sendspace=65536
no -o udp_sendspace=65536
no -o udp_recvspace=65536
no -o tcp_finwait2=60
no -o tcp_timewait=1
no -o tcp_keepidle=600
no -o tcp_keepintvl=10
no -o tcp_keepinit=40
これらのコマンドの効果は、ご使用のアプリケーションが作成および送受信する TCP/IP パケットの大きさによって左右されます。 「no -a」コマンドの効果は、システムをリブートするまで継続します。 これらのコマンドの効果を永続化するには、以下のコマンドを /etc/tunables/nextboot ファイルに追加します。
no:  
tcp_recvspace=65536
tcp_sendspace=65536
udp_sendspace=65536
udp_recvspace=65536
tcp_finwait2=60
tcp_timewait=1
tcp_keepidle=600
tcp_keepintvl=10
tcp_keepinit=40

これらのコマンドは、TCP/IP インターフェースごとに設定することもできます。 「lsattr -E -l en0」コマンドの結果を確認して、これらが TCP/IP インターフェースで設定されていない場合は、AIX では「no -a」コマンドの値が使用されます。

AIX で物理プロセッサー数より多い数の仮想プロセッサーが認識される smtctl -m off AIX の smtctl コマンドは、AIX で認識されている仮想プロセッサーの数を表示します。 次のコマンドを実行して SMT を無効にします。
smtctl -m off

smtctl -m off コマンドを実行する場合は、変更内容を永続化するために、後で bosboot コマンドを実行する必要があります。 bosboot を実行しない場合は、smtctl -m off を実行したことの効果がシステム再始動後に失われます。

各物理プロセッサー上の 2 つのスレッドはレベル 1 キャッシュを共用します。 これらのスレッドが関連していない場合は、他のキャッシュ・データが破損して、その結果として、システムはキャッシュを更新するための追加のメモリー・フェッチを待つことになるため、最終的に全体的な スループットが低下する可能性があります。 ワークロードに最適な設定を確認するために、この設定をオン/オフして何度かテスト実行してみてください。

NIS が実行されている NIS を無効にします。 /etc/hosts ファイルと /etc/passwd ファイルに「+」が含まれた行がある場合は、システムでは「YellowPages」とも呼ばれる NIS が実行されています。 このことは次のコマンドによっても確認できます。
ps -ef | grep yp
NIS は、初期状態の AIX では通常は無効になっています。 アプリケーション・サーバーで NIS が不要な場合は、NIS を無効にした状態でテスト実行してみてください。
多数のソケットが FIN_WAIT_2 状態になっている no -o tcp_finwait2=60

「netstat -an」コマンドによって FIN_WAIT_2 状態の多数のソケットが表示される場合、これは「高い接続速度が発生している」ことを意味しており、サーバー・ログ内の 「アドレスは使用中です (Address already in use)」というメッセージに対応しています。

これは no コマンドによって制御できます。 まず次のコマンドを実行して現在の設定を表示します。
"no -a | grep fin"
次に 1200 半秒 (10 分) というデフォルト値を確認します。 次の設定を使用してテスト実行します。
no -o tcp_finwait2=60

no コマンドの効果は、マシンをリセットまたはリブートするまで継続します。 このコマンドの効果を永続化するには、このコマンドを /etc/tunables/nextboot ファイル内に設定します。

プロセッサーは大きいページを使用できるが、 実際には使用していない JVM に次のパラメーターを追加する: -Xlp

この JVM は、WebSphere Application Server 上の Rational Asset Manager サーバー用です。WebSphere Application Server 管理コンソールで「アプリケーション・サーバー」-> 「RAM サーバー名」 ->「Java およびプロセス管理」->「プロセス定義」->「Java 仮想マシン」->「汎用 JVM 引数」を選択します。

パラメーターは -Xlp<size> です。デフォルトの大容量ページング・サイズを有効にするには、サイズを指定しないで -Xlp を指定する必要があります。特定のサイズを指定することもできます。例えば、-Xlp64 を指定すると、64 KB のページが有効になります。


フィードバック