このセクションでは、各種の構成でサポート可能な予想されるユーザー負荷やハードウェア・セットアップについては扱いません。 この情報については、Rational Asset Manager のキャパシティー・プランニング・ガイド (Capacity Planning Guide) を参照してください。
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 のパフォーマンスが向上します。
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| セッション・タイムアウトの問題 | メモリー内の最大セッション・カウント / デフォルト | デフォルトでは、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 管理コンソールにログインして、および「最大ヒープ・サイズ」にナビゲートします。 この設定を Rational Asset Manager サーバーに適用する必要があることに注意してください。 IBM Rational Team Concert サーバーに必要な設定は 768MB (これはデフォルト値です) で、最大設定は 2048MB です。 クラスターでは、必要に応じて IBM Rational Team Concert サーバーが専用のノードにインストールされる場合があります。 |
| ログ内のメモリー不足エラー - セッションの問題 | セッション・タイムアウト / デフォルト (30 分) | WebSphere Application Server 内のセッション・タイムアウトのデフォルト値は 30 分です。 この値をより短い時間に設定すると、特に多数のユーザーが短時間のトランザクションを実行する環境では、より多くのユーザーをサポートできるようになります。 この値を小さくしすぎると、ユーザーが大きいアセットをアップロードできなくなる可能性があります。 ほとんどのユーザーは、トランザクションの実行が終了しても明示的にログアウトせず、ほとんどのセッションはタイムアウトするまで存在しているということを念頭に置いてください。 このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 |
| おそらく非同期エラーまたは入出力エラーが原因で、大規模アセットのダウンロードに失敗する | HTTP インバウンド・チャネル (HTTP 2) の書き込みタイムアウト / 300 秒 | WebSphere Application Server でのサーバーからクライアントへの書き込みのタイムアウトのデフォルト値は、60 秒です。この値をより長い時間に設定すると、特にファイルをダウンロードしているクライアントの接続速度が遅い場合、または送信している要求が多い場合に、ファイルのダウンロード時の失敗を防止できます。 このパラメーターを変更するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 |
| 定期的に低速になる / ガーベッジ・コレクションが原因でパフォーマンス・スパイクが発生する | クラス・ガーベッジ・コレクション / 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 管理コンソールにログインして、にナビゲートします。 |
| 大容量ファイルの転送中にサーバーに障害が発生 (メモリー不足か、ログ内で malloc エラーが発生した可能性あり) | Web コンテナーのカス タム・プロパティー channelwritetype / 同 期データ転送 (sync) | 非同期データ転送を使用す
ると、TCP/IP 接続経由でデータを送信するのに、過剰な数のバッファーが必要な場合があります。
デプロイメント・マネー
ジャーの場合:
詳しくは、 http://www.ibm.com/support/docview.wss?uid=swg21317658 を参照してください。 |
| CPU の使用率が高い | パフォーマンス・モニター・インフラストラクチャー / 無効 | デフォルトでは、WebSphere Application Server では基本パフォーマンス・モニター・インフラストラクチャー (PMI) が有効になっています。 PMI はアプリケーション・サーバーをチューニングするための便利なツールですが、最大のパフォーマンスを得るには、サーバーを適切にチューニングした後にこの機能を無効にしてください。 PMI は、すべてのインスタンスとノード・エージェントに対して無効にする必要があります。 このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 |
| データベース接続エラー | JDBC 最大接続数 / 100 | Rational Asset Manager にログインしているすべてのユーザーをサポートするために十分な数の JDBC 接続を使用できることを確認します。 このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 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 管理コンソールにログインして、にナビゲートします。 WebSphere Application Server のチューニングについての追加情報 (Further Information for Tuning WebSphere Application Server)』というトピックも参照してください。 |
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| CPU の使用率が高すぎるか低すぎる | WebContainer プール / 30 | Web コンテナー・スレッドは、アプリケーション・サーバーが要求を処理するために使用します。 サーバーの CPU の使用率が低すぎる場合は、この値を大きくしてください。 CPU の使用率が高すぎる場合は、この値を小さくしてください。 Web コンテナー・スレッド数は、50 より大きく設定してはいけません。 このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 最小サイズ: 15 最大サイズ: 30 |
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| CPU の使用率が高すぎるか低すぎる | WebContainer プール / 50 | Web コンテナー・スレッドは、アプリケーション・サーバーが要求を処理するために使用します。 サーバーの CPU の使用率が低すぎる場合は、この値を大きくしてください。 CPU の使用率が高すぎる場合は、この値を小さくしてください。 Web コンテナー・スレッド数は、50 より大きく設定してはいけません。 このパラメーターを設定するには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。 最小サイズ: 25 最大サイズ: 50 |
これらのパラメーターに加えて、パフォーマンス・モニター・インフラストラクチャー (PMI) を有効にすることで、特定のワークロード下の WebSphere Application Server をチューニングできます。 これにより、パフォーマンス・データを示す詳細なグラフが得られます。 データを取り込むために、通常のワークロードでも PMI を有効にする必要がありますが、その結果としてパフォーマンスが低下するため、データ取り込みの完了後には PMI を無効にする必要があります。
PMI を使用可能にするには、WebSphere Application Server 管理コンソールにログインして、にナビゲートします。
Rational Asset Manager のパフォーマンスを向上させるには、以下のパラメーターおよび値を指針として、データベースをチューニングする必要があります。ただし、サーバー・セットアップ・アプリケーションを使用して Rational Asset Manager をインストールする場合、このセクションで提供されているパフォーマンス・チューニング設定値が設定されるため、これらの推奨される設定値を使用する場合は、このセクションをスキップできます。
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| 使用可能な接続がない | 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 の設定値が小さすぎる何千ものアセットが含まれたデータベースでは正常に実行できない場合があります。 |
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| DB2 サーバーにアクセスできない | *オペレーティング・システムのチューニングのセクションにある『AIX および Linux の最大プロセス数 (Maximum number of processes for AIX and Linux)』というトピックを参照してください。 | DB2 サーバーにアクセスできない場合は、db2agents が最大プロセス数を使用済みである可能性があります。 |
DB2 で各種のパラメーターを AUTOMATIC に設定すると、それらのパラメーターが現在のワークロードに基づいて自動的にチューニングされるようになります。 このように設定すると、最初は、特定のパラメーター値のチューニングが遅れた場合にパフォーマンスが低下したりエラーが発生したりする可能性がありますが、この設定は、最大のパフォーマンスを実現するためにチューニングが必要なパラメーターを特定するための便利な方法です。
パラメーターの値を大きくしすぎて、DB2 のコントロール・センターを起動できない場合は、DB2 のコマンド行で「db2 update db cfg for db_name using parameter_name value」というステートメントを実行することで、そのパラメーターを変更できます。
このセクションでは、WebSphere Application Server の補足パッケージに含まれている IBM HTTP Web Server のチューニング情報を提供します。
このセクションで説明するパラメーターは、httpd.conf ファイル内で変更できます。
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| 接続終了エラー | 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を参照してください。
イメージなどの静的コンテンツをキャッシュに格納するには、次の行をコメントを外します。これにより、Fast Response Cache Accelerator (FRCA) が有効になります。 |
| 一般的なパフォーマンス問題 | Afpa ロギング / オフ | 注: この設定値の使用は IHS 7 の時点で非推奨になったため、有効にすべきではありません。
FRCA ロギングをオンにする必要がない場合は、AfpaLogFile ディレクティブの前にコメント文字 (#) を挿入することで FRCA ロギングをオフにできます。
これにより、サーバーのパフォーマンスを向上させることもできます。 |
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| Web サーバー・ログ内のスレッド不足エラー | ThreadLimit / 25 | Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。 |
| Web サーバー・ログ内のスレッド不足エラー | ThreadsPerChild / 25 | Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。 |
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| Web サーバー・ログ内のスレッド不足エラー | ThreadLimit / 4000 | Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。 |
| Web サーバー・ログ内のスレッド不足エラー | ThreadsPerChild / 3000 | Rational Asset Manager に同時にアクセスするユーザーの数によっては、スレッドの上限数を増やす必要があります。 上限数を増やす必要があるかどうかを判断するには、Web サーバーのログにスレッド不足のエラーや警告が記録されていないか確認します。 |
このセクションでは、IBM Edge Caching Proxy を対象にして説明します。 DMZ キャッシング・プロキシー・サーバー構成についての情報は、『DMZ キャッシング・プロキシー・サーバーの構成』セクションを参照してください。
この文書で説明しているパラメーターは、ibmproxy.conf ファイル内で変更できます。
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| ファイル・サイズが大きいアセットをアップロードできない | LimitRequestBody / 2G | デフォルトでは、このパラメーターは 10 M に設定されています。 この値を大きくして、ユーザーが大きいファイルをアップロードできるようにします。 |
| タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない | InputTimeOut / 60 分 | このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。 アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。 |
| タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない | ReadTimeout / 60 分 | このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。 アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。 |
| タイムアウトになるためにファイル・サイズが大きいアセットをアップロードできない | ScriptTimeout / 60 分 | このパラメーターを 60 分に変更すると、ユーザーは大きいアセットをアップロードするのに十分な時間が得られます。 アプリケーション・サーバー・チューニングのセクションにある『セッション・タイムアウト』というトピックも参照してください。 |
| パラメーター | 設定 |
|---|---|
| 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 |
パフォーマンスを向上させるには、以下のキャッシング・プロキシー・サーバーのガイドラインに従ってください。
<services xmi:type="pmiservice:PMIService" xmi:id="PMIService_1243598970603" enable="false" initialSpecLevel="" statisticSet="basic" synchronizedUpdate="false" />
<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" />
<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 の値を大きくしてください。
これらが別々に配置されるようにするには、WebSphere のインストール先を決定してから、swap -l または lsps -a を実行します。
Windows:
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| Rational Performance Tester によるテスト中に「アドレスは使用中です (Address already in use)」というエラーが表示される | レジストリー項目 MaxUserPort / 65534 | 注: この設定は、Rational Asset Manager サーバーではなく、Rational Performance Tester クライアント上で変更する必要があります。
|
| セッション可用性のボトルネックを回避する方法 (6 インスタンスのクラスター上で 900 人のユーザーがいる場合に発生) | レジストリー項目 TcpTimedWaitDelay / 30 |
|
以下の説明は、AIX を対象にしています。
最大プロセス数
ユーザーが実行できるプロセスの最大数は、十分に大きい値に設定する必要があります。 このことは、多数のデータベース・エージェントが配置されている可能性のあるデータベース・サーバーに特に当てはまります。
lsattr -E -l sys0 -a maxuproc最大プロセス数を設定するには、次のコマンドを使用します。
chdev -l sys0 -a maxuproc=2000このコマンドを実行すると、システムの再始動後に上限数が 2000 に設定されます。
ファイル記述子
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 コマンドを使用して行うこともできます。
| 問題 | パラメーター / 設定 | 詳細情報 |
|---|---|---|
| 外部 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 ypNIS は、初期状態の 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 のページが有効になります。 |