WAS パフォーマンス管理

パフォーマンスの指標
1. スループット
  1. 単位時間(秒)あたりにシステムにより処理されるリクエスト数
  2. システム全体の処理能力
2. 応答時間
  1. リクエストを出してから、結果が戻りきるまでの時間
  2. ユーザーからみた処理能力
3. 性能評価
  1. スループットグラフ
    1. 横軸を同時ユーザー数、縦軸をスループット
  2. 応答時間グラフ
    1. 横軸を同時ユーザー数、縦軸を応答時間
スループット
1. スループットグラフ
2. システムの状態
  1. Aゾーン
    1. アクセス数増加に伴いスループットも増加
    2. すべてのリクエストを滞留させることなく処理できている状態
  2. Bゾーン
    1. CPU100%後もアクセス数増加で、応答時間は悪化するが、スループットは増加
    2. アクセス数が許容量(飽和点)を超えると、スループットは落ち始める
  3. Cゾーン
    1. 飽和点をさらに超えると、システムとして不健全な状態
    2. 資源の競合やページングの頻発により本来の能力が発揮できない状態
  4. CPUの使用率が低いにもかかわらず、スループットが飽和点に達する場合、能力を活用し切れていない。
    1. ボトルネックの追求、解消が必要
  5. 想定アクセス数に対して、AまたはBゾーンの範囲で稼動できるようにチューニングを行う
応答時間
1. 応答時間グラフ
2. リクエストが処理能力を超えると、応答時間は急激に悪化
  1. 適切にチューニングされていればエラーを戻すなど、応答時間は一定限度内に収まる
  2. チューニングが不適切な場合、応答が戻らない自体
動的キャッシュ
1. v4以降、動的コンテンツをキャッシュする機能をサポート
  1. JSPやサーブレットなどの動的コンテンツやコマンドの実行結果をWAS上にキャッシュする
  2. JVMヒープに保管
  3. cachespec.xmlで定義
  4. サーブレット/JSP・キャッシュ
  5. コマンド・キャッシュ
  6. オブジェクト・キャッシュ
  7. Webサービス・キャッシュ
2. ロケーション
チューニング
1. 基本ポイント
  1. キューイング・ネットワーク
    1. クライアントからのリクエスト
      1. ランダムに到達
      2. リクエスト数に波がある
    2. 一度に処理するリクエスト数の制限
      1. 各々のコンポーネントの入り口
      2. Webサーバー、アプリケーション・サーバー、データベース
      3. 処理しきれない分は行列に並ばせ、順番に受け付け
      4. 一定限度までのリクエストは並行に処理
      5. 設定された数を超えた同時リクエストは、キューに入れられる
      6. キューへの送信側で設定されたタイムアウト値を超えた場合は、クライアントにエラー
      7. 適切なタイムアウトの設定
      8. システムの許容量を超えたリクエストがあった場合に、ユーザーのストレスを軽減
      9. システムの負荷を必要以上に大きくしない
    3. 種類
      1. オープン・キュー
      2. 活動状態にあるリクエスト数に制限なし
      3. クローズド・キュー
      4. 活動状態にあるリクエスト数に上限
      5. 活動状態か待ち状態のいずれか
    4. キューイング・ネットワーク
      1. 原則
      2. 一般的には、ネットワーク側（Webサーバーの手前）で処理を待つリクエストの数を多く、アプリケーション・サーバー内部で処理を待つリクエストの数が小さくなるように調整
      3. リクエストをできるだけネットワーク側で待たせることによってアプリケーション・サーバーへの負荷を軽減
      4. バックエンド側のスレッド数を増やしたい場合は、その前段のコンポーネントのスレッド数も増加させて多くのリクエストを受け付けるようにする必要
      5. 理想的には、システムの負荷テストを行った上で、それぞれのキューの最大数に達したときにシステムのCPUの使用率が100%となり、システムの最大のパフォーマンスが得られるように、パラメータを設定
    5. WASパラメーター設定
      1. Webサーバー
      2. <IHS_root>/conf/httpd.confファイル
      3. 最大同時実行数
      4. MaxClients/ThreadsPerChildディレクティブ
      5. 設定値を超えた要求に対するタイムアウトは、Webブラウザーごとの実装によって決定
      6. Webコンテナー
      7. 最大同時実行数
      8. Webコンテナー・スレッドのパラメーター
      9. [サーバー] → [アプリケーション・サーバー] → [ApplicationServer_name] → [コンテナー設定] → [Webコンテナー設定] → [Webコンテナー]
      10. [追加プロパティ]→[Webコンテナー・トランスポート・チェーン]→[WCInboundDefault]→[TCP インバウンド・チャネル(TCP 2)]→[関連項目]→[スレッド・プール]→[WebContainer]
      11. プール内のスレッドは、[最大サイズ]で設定した値まで、作成可能
      12. 接続の最大値
      13. ① [サーバー] → [アプリケーション・サーバー] → [ApplicationServer_name] → [コンテナー設定] → [Webコンテナー設定] → [Webコンテナー・トランスポート・チェーン]
      14. [WCInboundDefault] → [TCP インバウンド・チャネル(TCP 2)]
      15. [最大のオープン接続数]で設定した数だけの接続を受け付け
      16. データソース
      17. 最大同時実行数
      18. [リソース] → [JDBCプロバイダー] → [JDBCProvider_name] → [追加プロパティ] → [データ・ソース] → [DataSource_name] → [追加プロパティ] → [接続プール・プロパティ]
      19. 最大接続数で設定
    6. Webサーバー
      1. v1.3とv2.0/6.1でリクエストの処理方法が異なる
      2. v1.3（UNIX系）
      3. 親プロセスは、子プロセスを生成してIHSに来るリクエストを処理
      4. 同時に処理可能なリクエストの数は子プロセスの数に依存
      5. 生成する子プロセスの数はhttpd.confファイルで設定可能です。最大同時実行数はMaxClientsで決定
      6. v2.0/6.1（UNIX系）
      7. 各々の子プロセスがスレッドを生成し、そのスレッドによってリクエストが処理
      8. 同時に処理できるリクエスト数はhttpd.confファイルで設定するMaxClientsで決定されますが、指定された数はリクエストを実行するスレッドの最大数
      9. v1.3よりも少ない子プロセス数で多くのリクエストを実行
      10. 子プロセスの生成にかかる負荷を抑制
      11. v1.3/2.0/6.1 （Windows）
      12. 生成された親プロセスによって、１つの子プロセスが生成
      13. 子プロセスがスレッドを生成し、そのスレッドによってリクエストが処理
      14. 最大同時実行数はThreadsPerChildで決定され、指定された数は生成される最大スレッド数
    7. データベース接続
      1. 接続プール・サイズ
      2. データベースへの接続を作成する処理は、非常に負荷のかかる処理
      3. WASでは作成した接続をプールして再利用するという仕組み
      4. Prepared Statement Cacheサイズ
      5. WASでステートメント・キャッシュを利用すると、データベース側でプリペア処理が行われたSQLがWASにキャッシュされ、効率的にプリペア処理を省略することができる
      6. ステートメント・キャッシュは接続プールのコネクションごとにキャッシュ
      7. [リソース]→[JDBCプロバイダー]→[JDBCProvider_name]→[追加プロパティ]→[データ・ソース]→[DataSource_name]→[追加プロパティ]→[WebSphere Application Server データ・ソース・プロパティ] → [ステートメント・キャッシュ・サイズ]
  2. JVMメモリー
    1. GCポリシー
      1. JVM(具体的にはJVMのSTコンポーネント)が提供するメモリ管理方法はGCポリシーを指定することで変更することができる
      2. STコンポーネントはヒープ内のどこに空き領域が存在するかを管理
      3. J9 VMで利用可能なGCポリシー
      4. Optimize for Throughput
      5. デフォルトのポリシー
      6. Mark-Sweep-Compactionの三つのフェーズに分けて実施
      7. Compactionフェーズはオブジェクトの移動が伴い高負荷なので、発生条件が整ったときにのみ実施
      8. ガーベッジ･コレクション実行中はヒープへのアクセスを行っているすべてのスレッドが停止
      9. Optimize for Pause Time
      10. レスポンス・タイムのばらつきが小さいことがより優先されるケースに検討
      11. Mark-Sweep-Compaction型
      12. リクエスト処理している時間帯にMark処理もこまめにやってしまうことで停止時間を短縮
      13. スループットの面で不利
      14. Generational Concurrent
      15. 一般に「世代別GC」と呼ばれる方法を採用
      16. 個々のオブジェクトの想定される生存期間に応じて、ヒープ・アロケーションを行う場所を変えながらヒープ全体を管理
      17. Nursery領域とTenured領域と呼ばれる二つの異なる領域に分割
      18. Nursery領域
      19. 新規に生成されるオブジェクト
      20. さらに二つの領域
      21. Allocate領域
      22. まずAllocate領域
      23. Survivor領域
      24. Allocate領域がいっぱいになると、ヒープ内の「生きた」オブジェクトのトレースが行われます。その際に、「生きた」オブジェクトがあるとそのオブジェクトをSurvivor領域にコピー
      25. Allocate領域の全体のチェックが終わると、「生きた」オブジェクトはすべてSurvivor領域にコピー
      26. Survivor領域を使ってこれ以降のリクエスト処理を行える
      27. Allocate、Survivor領域の役割を入れ替え
      28. Tenured領域
      29. ある回数のガーベッジ・コレクションをくぐり抜けて「生存」し続けることができると移動
      30. 「短命」のオブジェクトに対して集中してGC
      31. Subpooling
      32. ヒープ･アロケーションのアルゴリズムを変更することで適切なパフォーマンスを得ることを目的
      33. POWERアーキテクチャーのCPUを利用したプラットフォームであることが必要条件
    2. ヒープサイズ
      1. ヒープサイズが実際の必要量よりも少ない場合
      2. ガーベッジ・コレクションの実施頻度が上がる
      3. 最悪の場合メモリ不足エラー(OutOfMemory)
      4. ヒープサイズが実際の必要量よりも多すぎる場合
      5. ガーベッジ･コレクションの実施時間が長くなる
      6. OSから割り当て可能なサイズを超えて設定をしてしまうと、ページングが発生する恐れ
      7. 二通りの考え方
      8. JVMに動的に変更できるように設定
      9. 最小ヒープサイズを最大ヒープサイズよりも大きくすることで、差分の範囲でJVMがヒープサイズ調整のアルゴリズムの則って動的にヒープを変更
      10. ヒープサイズを固定
      11. 最小ヒープサイズと最大ヒープサイズを同じ値にすることでサイズが固定
      12. 一般的な設定指針
      13. 必要とするタイミングで必要な量だけのヒープをWAS（JVM）が確保できるように必要十分なサイズを確保
      14. 設定
      15. [サーバー]→[アプリケーション・サーバー]→[ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Javaおよびプロセス管理]→[プロセス定義]→[追加プロパティ]→[Java 仮想マシン]　
2. モニタリング・ツール
  1. Performance Monitoring Infrastructure
    1. WASでは各リソースの様々なパフォーマンスデータをMBean(Managed Bean)という特別なJavaBeanに格納
    2. PMIはこのMBeanと通信して各コンポーネントの必要なパフォーマンスデータを取得
    3. 設定
      1. 管理コンソールによってPMIを使用可能にする必要
      2. [モニターおよびチューニング]→[Performance Monitoring Infrastructure (PMI)]→[AppServer_name]を選択して、構成タブの[Performance Monitoring Infrastructure (PMI)を使用可能にする]にチェック
    4. 要求メトリック
      1. 主要コンポーネントにおいて経過した時間を計測し、ログに記録する機能
      2. [モニターおよびチューニング]→[要求メトリック]
      3. 、[要求メトリックを使用可能にする]にチェック
      4. ログの解析
  2. Tivoli Performance Viewer
    1. PMIを使用してパフォ-マンス・データを取得
    2. WASの管理コンソールに組み込まれている
    3. モニターの開始
      1. [モニターおよびチューニング]→[Performance Viewer]→[現行アクティビティ]
      2. [コレクション状況]が[使用可能]から[モニター対象]
      3. この時点からパフォーマンス・データの収集が開始
    4. ユーザー設定
      1. ナビゲーション・ツリーより[設定]→[ユーザー]
      2. リフレッシュ速度
      3. データ表示
    5. ロギング設定
      1. 期間
      2. [ロギング開始]をしてから[ロギング停止]を行わない限り、ロギングを継続する時間を設定します。デフォルトでは２０分
    6. 現行アクティビティの表示
      1. チェック・ボックスにチェックを付けたモニター項目についてビューアーに表示
      2. [モジュールの表示]ボタンを押すことで、ビューアーにグラフ表示
    7. モニタリング・ポイント
    8. ログの再生
      1. [モニターおよびチューニング]→[Performance Viewer]→[ログの表示]
      2. ② [ログ・ファイルの明示的パス]にチェックをいれて、参照ボタンでログ・ファイルを選択
  3. パフォーマンス・アドバイザー
    1. Runtime Performance Advisor
      1. アプリケーション・サーバー上で稼動し、パフォーマンスを定期的にチェック
      2. [WebSphere ランタイム・メッセージ]と標準出力であるSystemOut.logファイルに出力
      3. デフォルトでは使用可能になっていない
      4. [サーバー]→[アプリケーション・サーバー]→[ApplicationServer_name]→[パフォーマンス]→[Runtime Performance Advisor構成]
      5. 構成タブの一般プロパティで[Runtime Performance Advisorを使用可能にする]のチェック
    2. TPV Advisor
      1. 管理コンソールでリソースの状況やアドバイスを表示
      2. TPVコンソール・パネルのナビゲーション・ツリーの[アドバイザー]を選択してTPV Advisorを表示