|
|
WebOTX Manual V10.2 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.2 (第4版) 目次を表示 |
業務システムの運用時に重要となるのは、システムの安定稼動です。 特にインターネット業務システムでは負荷の予測が困難なため、過負荷時にも安定して動作できるアプリケーションの実行環境が求められます。
WebOTXはメインフレームで培われたオンライントランザクション処理 (OLTP) 技術を取り込んだアプリケーションサーバです。 OLTP技術により、CPU、メモリなどのコンピュータ資源に対し、大量に発生するトランザクション要求を効率良く割り当て、高い並列性・独立性を保ちながら処理することができます。 またOLTP技術によってシステムの安定動作も実現しており、障害の検出や局所化、デッドロック発生時の再実行などのリカバリを実現しています。
インターネットで発生する想像を超えた負荷に対し、システムを恒久的に安定動作させることは困難であり、最終的にはCPU、メモリ、サーバ、ネットワークなどのハードウェアの増設が必要になります。
しかし、一般にハードウェアの増設は短期間で完了するものではないため、その間システムが不安定な状態では業務システムとして問題です。
WebOTXでは、トランザクション毎の優先度付けと流量制御により、資源の枯渇を防ぎながら重要な業務を過負荷環境下でも安定して動作させることができます。
さらに不要な業務を完全に閉塞することで、重要業務以外の負荷を無くすこともできます。
高負荷に対応するためにも、業務の実行基盤は高性能であることが求められます。 WebOTXは世界最高水準の高速動作が可能なObject Request Broker(ORB)コアを採用しており、マルチスレッドやコネクションプーリング、ローカルスタブ(分散オブジェクトのプロセス内呼び出し)により、 高性能なアプリケーションの実行環境を提供しています。
WebOTXは、WebサーバやWebアプリケーションサーバで多く使われている負荷分散型クラスタとメインフレームなどの業務システムで使われているフェイルオーバ型クラスタをサポートしています。
負荷分散型クラスタは同一の構成のサーバ台数を増加することで簡単にアプリケーションサーバの可用性を高められ、性能もネットワークや共有リソースの限界まで拡張できますが、
多数のサーバハードウェアを構成することでデータベースなどの共用リソースの障害発生確率が高くなるため、業務やアプリケーションで特定のデータ(レコード)へのアクセスの集中を避ける必要があります。
一方、フェイルオーバ型クラスタは集中してアクセスされるデータに対して障害発生確率を低く抑えることができますが、フェイルオーバ発生時の切り替え時間中はサービスを停止または保留することになります。
WebOTXでは、業務特性に応じてこれらを最適に組み合わせてシステムを構築することができます。
WebOTXでは、システムを安定稼動させるためにメインフレームで培われたOLTP技術をStandardに取り込んでいます。
これにより、サーバのコンピュータ資源(CPU、メモリ)を効率良く利用でき、一時的なソフトウェア障害に対してもサービス全体を停止することなく安定してサービスを継続できるようにしています。
また、Expressエディションでは、サーバを並列して安定稼動を図るスケールアウトの考え方でシステム構築する構成を想定して、システムの軽量化のためにOLTP機能を一部だけ取り込んでいます。
ここではWebOTXのStandardが提供するOLTP機能について説明します。
WebOTXでは、OLTP技術を取り込んだTPモニタにより、アプリケーションサーバ上で動作するアプリケーションが管理されます。 アプリケーションは、以降で説明するTPシステム、アプリケーショングループ、プロセスグループの単位でグルーピングされて、TPモニタではこれら構成単位毎に起動、停止などの運用制御や状態監視、障害リカバリを行います。
TPシステムはドメイン単位で構成され、複数の業務アプリケーションを管理します。 マルチドメイン構成では1つのマシン上に複数のTPシステムを起動させることができ、クラスタ運用ではダウンしたサーバのシステムをそのまま稼働中のバックアップサーバに引き継ぐことができます。
1つのマシン上に作成できるTPシステムの最大数はプラットフォームによって異なり、以下がそれぞれの環境における最大値となります。
| OS | 最大システム数 |
|---|---|
| Windows | 20 |
| HP-UX | 105 |
| Linux | 105 |
アプリケーショングループとは、開始・終了などの運用を共にするアプリケーション群をグルーピングしたものです。 例えば、「受発注業務」「在庫数管理業務」といったような業務毎にツリーを分けて管理するといった用途に用います。 こうすることで「受発注業務」は10時から17時まで動作させその後は停止させる、 「在庫数管理業務」は24時間動作させる、といったアプリケーショングループ単位での独立した運用が行えるようになります。
プロセスグループとは、ある特定のサービスを提供するプロセス群です。 同一のプロセスグループに登録されているコンポーネントは同一のプロセス上でロードされます。 WebOTXはビジネスロジックを記述した1つまたは複数のコンポーネントをプロセスグループに登録し、プロセスとして実行します。 WebOTXでは、プロセスグループ単位に実行多重度(プロセス数、スレッド数) などを設定することができます。
モジュール(コンポーネント)とは、アプリケーションのモジュールファイルを指します。 Javaの場合はjarなどのJavaアーカイブファイル、 Java EEアプリケーションの場合はearアーカイブファイルを指します。 WebOTXでは、これらのモジュール単位にアプリケーションとして配備を行ないます。
オブジェクトとは、EJBのインタフェースを実装した実行オブジェクトです。 各Bean単位でオブジェクトが生成されます。
オペレーションとは、サーバアプリケーションのオブジェクトで実装されたクライアントから呼び出し可能なサービスであり、EJBの場合はHome/Remoteインタフェースで実装したpublicメソッドになります。 これらのオペレーションは、クライアントからのオペレーションコールにより実行されます。
一部のサーバアプリケーションでは、オブジェクト内で状態を保持するかどうかを指定することができます。 状態を保持するオブジェクトをステートフルといい、保持しないオブジェクトをステートレスといいます。
ステートフル:
ステートフルのオブジェクトでは、オブジェクトのインスタンスはクライアントからの処理要求(ファクトリオブジェクトのオブジェクト生成要求)時に初めて生成され、オブジェクトが要求を出したクライアントと1対1にマッピングされます。
以降の同一のクライアントから要求は、マッピングされたインスタンスで処理することになります。
ステートレス:
ステートレスのオブジェクトでは、アプリケーションが動作するプロセスの起動時にオブジェクトのインスタンスを一度に生成してプールしておきます。
プールされたインスタンスはオペレーションの処理が終了しても消滅せず、プロセス終了時に消滅します。
そのため、2度目以降のオペレーション呼び出しでは生成のオーバーヘッドがなくスループットをあげることができます。
EJBアプリケーションはBeanの種類によってステートレス、ステートフルが決定されるため、変更することはできません。
| Bean の種類 | オブジェクト | ステート |
|---|---|---|
| ステートレスSession Bean | home | ステートレス |
| remote | ステートレス | |
| ステートフルSession Bean | home | ステートレス |
| remote | ステートフル | |
| Entity Bean | home | ステートレス |
| remote | ステートフル | |
| メッセージ・ドリブンBean | - | ステートレス |
| シングルトンSession Bean | home | ステートレス |
| remote | ステートレス |
WebOTXではアプリケーションをコンポーネント単位で動的に登録、変更、削除することができます。
プロセスの再起動が必要な設定項目を変更したときに、運用によってはプロセスが停止できず、設定を反映することができないことがあります。 本機能ではこのような場合に、新設定を反映したプロセスを起動し、新設定のプロセスが起動完了となった時点で旧設定プロセスを停止することで、プロセスグループの設定を動的に反映できます。 設定については [ 構築・運用 > ドメインの構築 > TPシステム > 設定詳細 > プロセスグループの設定の動的変更 ] を参照してください。
プロセスグループ起動時に予備スレッドを起動しておき、必要に応じて予備スレッドを実行可能な状態にすることにより、Transaction負荷が高い状況に対応することができます。 設定については [ 構築・運用 > ドメインの構築 > TPシステム > 設定詳細 > 予備スレッドの事前生成と活性化 ] を参照してください。
「Open SSL」もしくは「SecureWare/セキュリティパック」をWebOTX実行環境に適用することにより、WebOTXのクライアント−サーバ間通信を Secure Socket Layer (SSL) プロトコルで行えます。
SSLは共通鍵暗号化方式と公開鍵暗号化方式、デジタル証明書を併用した認証および暗号化のプロトコルで、WebOTXのクライアント−サーバ間通信においてクライアント、サーバの認証および電文の暗号化を行うことができます。
WebOTXのSSL通信についての特徴を以下に説明します。
図3.4.2.11-1
クライアント、サーバでそれぞれ認証を行うための鍵識別子を設定します。 クライアントアプリケーションでは起動時の引数、またはAPIで鍵識別子を指定します。 サーバアプリケーションではTPシステムの設定として統合運用管理ツールで設定を行います。 設定後はクライアントとサーバのコネクション開設時に相互に認証を行います。 また、サーバアプリケーションではAPIでクライアントを識別するための証明書情報を取得することが可能です。
WebOTXのIIOPリスナでは、SSLを使用した通信と使用しない通信を同時にサポートするため、通信用のポート番号をそれぞれ独立して設定することが可能です。 これにより、ファイアウォールを越える通信はSSLを利用し、ローカル内での通信はSSLを利用しない通信と振り分けて利用することが可能です。
TPモニタはサービス開始時にTPシステムを管理するために必要なリソース(主にメモリ)を確保します。
事前にリソースを確保することにより、運用中にリソース不足による動作の不安定な状況を避けることができます。
WebOTXでは、システム規模に応じたリソース配分を行なうために、TPシステム単位で以下のシステム・パラメータの設定を行えます。
| パラメータ | 既定値 | 最大値 |
|---|---|---|
| アプリケーショングループ数 | 985固定 | |
| プロセスグループ数 | 985固定 | |
| コンポーネント数 | 1000 | 3844 |
| インタフェース数 | 2000 | 10000 |
| オペレーション数 | 10000 | 2147483647 |
| 最大プロセス数 | 100 | 985 |
| 最大スレッド数 | 300 | 9850 |
WebOTXにおけるクライアントからのオペレーション要求の処理フローを以下に示します。
図3.4.3.2-1
WebOTXアプリケーションサーバは、サーバアプリケーションの制御を行なうTPモニタおよび、クライアントのオペレーション要求、応答処理を行なうリスナ、実際に業務ロジックを実行するプロセスグループ群から構成されます。 この際、既定では、EJBの呼び出しはIIOPリスナで処理を行い、Webの呼び出しはAJPリスナで処理を行います。 また、プロセスグループ単位では要求受信用のキューを備えており、プロセスグループ単位で設定した実行多重度(プロセス数、スレッド数)を超えた要求は、キュー内で保留されます。 プロセスグループはWebOTXの制御部分(ベースライブラリ、オブジェクトマネージャ)とユーザが作成したサーバコンポーネントから構成されています。以下にその構成部分について説明します。
各リスナはクライアントからのオペレーション要求を受け付けると、要求を処理するプロセスグループを判別し、該当プロセスグループのキューに要求をキューイングします。 ベースライブラリでは、該当プロセスグループのうち処理実行待ちのスレッドにその要求を割り当て、オブジェクトマネージャに処理を渡します。 オブジェクトマネージャでは、オペレーション要求に応じたユーザコンポーネントの該当オペレーションの呼び出しを行います。 ユーザコンポーネントで実際のビジネスロジックが処理され、オペレーションの処理結果はオブジェクトマネージャ、ベースライブラリを通して各リスナの持つ送信用キューにキューイングされます。 各リスナは送信用キューに処理結果がキューイングされると、該当クライアントに応答を返します。
クライアントからプロセスグループの実行多重度を超えた要求があった場合、要求はキューイングされ空きスレッドができるまで処理を保留します。 また、キューイング要求上限数（アプリケーションごとに設定可能）を超えた要求に対してはクライアントにエラーを返します。 サーバの資源に応じてプロセスグループの実行多重度(プロセス・スレッド)、キューイング数を適切に設定することにより、 想定外の大量のトランザクション要求に対しても、サーバリソースが枯渇して動作が不安定となる状況を回避し、リソースの範囲内で安定した動作を行わせることができます。 またトランザクション毎にプライオリティ(実行優先度)を設定でき、高負荷で様々な処理がキューイングされている状態においても、重要な処理を優先的に実行することが可能です。
WebOTXでは、予測できない急激な負荷変動に対しても重要度の高い業務やユーザに対してサービスを継続させるために、以下のような様々なキュー制御を行なっています。
図3.4.3.3-1
WebOTXでは、アプリケーションを複数のプロセスに分散して実行するマルチプロセス構成と、各プロセスでシングルスレッドやマルチスレッドを動作させるマルチスレッド構成がとれます。
マルチスレッド構成では、すべてのプロセス上のスレッド群は単一のキューに対してデータの到着を待ち合わせるので、空きスレッドに効率良くトランザクション要求をディスパッチすることができます。
マルチプロセス構成では、アプリケーションの一時的な障害に対してサービスの継続が可能になり、データや環境、タイミングなどの要因でアプリケーション障害が発生しても、そのプロセスだけが異常終了し、他のプロセスは影響を受けません。
そのため、システム全体でサービスを中断させることがありません。
しかしマルチプロセス構成はマルチスレッド構成に比べてより多くのリソースを必要とします。 システムで多数のプロセスが起動する構成ではマシンのリソース不足を招き、サーバ自体が不安定になる恐れがあります。 そのため、マルチプロセス構成は予期せぬアプリケーション障害に備えての多重化とし、クライアントからの同時実行に備えての多重化はできる限りマルチスレッドで行う構成が望ましいといえます。
また、システム運用中に発生した想定外の大量のトランザクション要求に対して、動的にアプリケーション多重度(スレッド、プロセス)を増加させることが可能です。
これにより、大量のトランザクション要求をサーバ側が処理しきれずにキューに滞留し、結果としてレスポンスの悪化を招く事態が避けられます。
また、負荷が下がったときに安全に実行多重度を元に戻すこともできます。
以下の測定値はWindowsのアプリケーションプロセスで最低限必要となるメモリ使用量です。システム構築時のチューニングの参考としてください。 ただし、実際のアプリケーションではユーザロジックで確保しているメモリ使用量を考慮に入れる必要がある点と、メモリ使用量はOSやJavaのバージョンにより異なる点はご注意ください。
| スレッド数 | メモリ使用量(JavaAP) |
|---|---|
| 1 | 33MB |
| 2 | 35MB |
| 5 | 38MB |
| 10 | 43MB |
| 20 | 54MB |
| 50 | 85MB |
| 100 | 138MB |
例）5プロセス10スレッド構成の場合
メモリ使用量(JavaAP) = 43MB × 5プロセス = 215MB
プロセスグループの強制停止処理時に即時強制停止することができます。即時強制停止ではプロセスグループに対して即時にシグナル送信(Windowsの場合はTerminateProcess())を行います。 設定については、 [ 構築・運用 > ドメインの構築 > TPシステム > 設定詳細 > アプリケーショングループ停止処理時間の短縮 ] を参照してください。
StandardではTPモニタ機能により、プロセスグループで動作するアプリケーションプロセスの状態を常に監視しています。 ここではTPモニタによる障害に対する機能について説明します。
WebOTXではシステムの動作を確認できる各種のログやトレースを提供しています。またAPIを用いることによりユーザロジックの中でログ出力、トレース出力ができ、障害解析や性能分析に役立てることができます。 WebOTX V6.2以降では、障害解析で原因究明を行ないやすくするために、起動時ログを通常時のログと分けて出力します。
WebOTXではOLTP技術を取り込んだTPモニタによりアプリケーションサーバ上で動作するアプリケーションが管理されます。 アプリケーションはTPシステム、アプリケーショングループ、プロセスグループの単位でグルーピングされ、TPモニタはこれら構成単位毎に起動、停止などの運用制御や状態監視、障害リカバリを行います。
クライアントからのトランザクション要求に対してサーバアプリケーションが不正な処理を行い、例外が発生した場合に、該当スレッドを閉塞して、例外の発生をコールバックAPIでアプリケーションに通知します。 アプリケーションは、データベースのロールバック前に障害情報の保存などの後処理を行うことができます。
クライアントからのトランザクション要求に対して、あらかじめ設定した時間が経過してもサーバアプリケーションが応答を返さない場合に、アプリケーションを異常終了させて該当プロセスを閉塞します。 これにより、クライアントに応答が返らない事態やサーバの資源を無制限に消費する事態を回避できます。
上記事象によりアプリケーションプロセスが異常終了した場合に、そのプロセスが使用していたリソース(コネクション、共有メモリ、データベース資源)をWebOTXが解放し、設定に応じてプロセスの再起動を行います。 この機能により、障害発生後もプロセス異常終了前と同じ処理能力を維持することができます。
アプリケーションプロセスの異常終了が検出されると、TPS15-01107メッセージがイベントログ・シスログに出力されます。 異常が発生した場合はまずはイベントログ・シスログを確認してください。
図3.4.4.2-1
プロセスグループがマルチプロセス構成の場合、その中の一つのアプリケーションプロセスが異常終了しても、他のアプリケーションプロセスは通常どおり処理を行うことができます。 このため、プロセスグループとしては異常終了したアプリケーションプロセスが再起動されるまでの間もサービスの継続性を確保できます。
アプリケーションプロセスの再起動に回数を設定し、プロセスの異常終了時にはこの指定に応じて再起動が行なえます。 ただし障害が再現性のあるものである場合、障害発生後に自動的に再起動させても、同じ障害が再度発生して、再起動が繰り返される可能性があるので注意が必要です。 また自動的に再起動させてしまうと障害の発生に気付かない恐れがあるので、テスト環境で使用する場合は再起動させない設定とし、本番運用では再起動する設定とする構成を推奨します (統合運用管理ツールの[TPシステム]-[上限設定]-[プロセス障害時の再起動回数])。
オペレーション実行中に何らかの障害でプロセスが終了した場合、TPモニタがそのプロセスに代わりエラー応答をクライアントに返し、イベントログ・シスログに情報を残します。 このときキューで処理を待っていたリクエストは別プロセスが引き継いで処理をすることができますが、 他に起動中のアプリケーションプロセスがなく、かつプロセス再起動回数を使い果たした場合は要求を別プロセスに引き継げません。 しかしこの場合でもエラー応答をクライアントアプリケーションに返すため、サーバアプリケーションの異常終了に影響されてクライアントアプリケーションが無応答になることはありません。
クライアントアプリケーションに返却されるエラーコードの詳細は [ リファレンス > 例外一覧 ] を参照してください。
WebOTXでは、オペレーション実行中にJavaランタイム例外が発生するとアプリケーションプロセスを異常終了させますが、この際に捕捉した例外のスタックトレースをシステムトレースに記録します。 この情報から、Javaソースのどの行が原因で異常終了したかを特定することができます。
デフォルトでは以下の場所にアプリケーションログを出力しています。
なお、異常終了の場合はログがsaveディレクトリに移動するため、saveディレクトリも確認してください。
WebOTXでは、オペレーションの実行中にネイティブ例外が発生すると該当スレッドを閉塞させ、スレッドの残りがない場合はプロセスを終了させます。 また、このときイベントログ・シスログにメッセージと、ネイティブ例外エラーコードを出力します。 システムトレースに記録されたライブラリロードアドレスと開発時のmapファイルを使用することで、障害箇所を特定できる可能性があります。
例外発生時の情報はアプリケーションログに出力されます。デフォルトでは以下の場所にアプリケーションログを出力しています。
なお、異常終了の場合はログがsaveディレクトリに移動するため、saveディレクトリも確認してください。
アプリケーションエラーが発生したとき、アプリケーションログにエラーメッセージを出力します。 このメッセージを確認することで、エラーが発生したオペレーション呼び出しを特定することが可能です。 またV8.3以降では、アプリケーションログにスタックトレースを出力するか、もしくは例外ハンドルの設定を無効にしてワトソンログ出力を有効にすることができます。 例外ハンドルの設定は統合運用管理ツールの[TPシステム]-[例外ハンドル]-[WebOTXで例外処理を行う]で行なえます。
出力されたスタックトレースを解析するには、 [ トラブルシューティング > 障害解析 > 機能別リンク > TPシステム(Standard) > プロセス突然終了への対応 ] を参照してください。
システムトレースにはアプリケーションプロセスが異常終了した時点で実行中だった未完了のオペレーションの状態が記録されるため、異常終了したオペレーションを絞り込むことができます。
この機能は、アプリケーションプロセスが実行されるたび共有メモリに記録している情報を元に出力しているので、アプリケーションの終了の要因に関わらず利用できます。
一方で、オペレーションの絞込みは障害情報記録(Java)、障害情報記録(Native)の情報で行なえる場合もありますが、
これらの機能はアプリケーションプロセス中で実行される機能であるため、killコマンドやタスクマネージャで強制終了された場合などの状況によっては機能しないことがあります。
Standardでは、アプリケーションプロセスが無応答や極度の遅延に陥った場合に、状態を検出し、情報を採取してリカバリを行う機能を実装しています。
プロセス起動処理(Java VMの起動,ORB初期化など)やプロセス終了処理(ORB解放,JavaVM停止など)で無応答となった場合に、プロセスのストール検出機能により障害を検出し、該当アプリケーションプロセスを強制終了する機能です。 この障害で強制終了されたプロセスがあらかじめ再起動設定を行なっていた場合、起動処理時の障害時に再起動が実行されます。 また、以下で説明する [ スレッド起動停止の実行時間超過の検出 ] や [ オペレーション実行時間超過の検出と自律復旧 ] などの、 アプリケーションプロセス中の制御スレッドで実装されている監視機能が正常に機能しないような異常状態になった場合であっても、 プロセスのストール監視機能により障害を検出し、アプリケーションプロセスを強制終了します。 タイマの設定方法は [ 構築・運用 > チューニング > APサーバ > その他チューニングに関する設定 > 起動・停止タイムアウト(プロセス終了) ] を参照してください。
この機能では、スレッド起動処理(サーバオブジェクトや常駐オブジェクト作成)やスレッド終了処理(サーバオブジェクトや常駐オブジェクト削除)が無応答になった場合に障害として検出し、プロセスを強制終了します。 この機能で強制終了されたプロセスがあらかじめ再起動設定を行なっていた場合、起動処理中に障害が発生した時に再起動が実行されます。 この機能で使用するスレッド初期化タイムアウト時間はプロセスグループ単位に設定できます。 タイマの設定方法は [ 構築・運用 > チューニング > APサーバ > その他チューニングに関する設定 > 起動・停止タイムアウト(メッセージ表示) ] を参照してください。
サーバアプリケーションで実行したオペレーションが無応答のときに、その状態を無応答障害として検出し、警告メッセージをシスログ(Windowsの場合はイベントログ)に、アプリケーションログにスタックトレースを出力する機能です。 この機能では、サーバアプリケーションが実行時間の上限を超えても応答がない場合、WebOTX はアプリケーションプロセスが無応答障害に陥っていると判断し、警告メッセージとスタックトレースを出力します。 あらかじめ実行時間の上限の設定をしていた場合は、アプリケーションプロセスを強制終了し、再起動設定を行なっていればプロセスの再起動を実行します。 この機能により、クライアントに応答が返らない事態や、サーバの資源を無制限に消費する事態を回避できます。 実行時間の上限の値はオペレーション毎に設定することができます。設定方法は [ 構築・運用 > チューニング > APサーバ > その他チューニングに関する設定 > 実行時間タイムアウト ] を参照してください。
この機能では、データベースのデッドロックなどの再試行可能な障害であればそのオペレーションを自動的にやり直したり、 データベースのオーバーフローなどでは更新系のサービス(オペレーション)だけを停止するなど、 障害の原因によってきめ細かいリカバリ処理を行うこともできます。
AP応答監視タイマ機能では、サーバアプリケーションの無応答障害を検出し、別プロセスが異常状態のアプリケーションプロセスに成り代わってクライアントアプリケーションにエラー応答(NO_RESPONSE(3920))を返します。 これによりサーバアプリケーションの無応答障害が発生しても、クライアントアプリケーションは無応答状態を回避して応答を受け取ることができます。 AP応答監視タイマ機能はプロセスグループ毎に設定することができます。設定方法は [ 構築・運用 > チューニング > APサーバ > その他チューニングに関する設定 > 呼び出しタイムアウト ] を参照してください。
WebOTXではサーバアプリケーションの全スレッドそれぞれで実行されている処理の情報を取得することができます。 この機能では、各スレッドの状態(IDLE状態/実行状態など)、実行中のオペレーション名、実行中オペレーションの開始時刻、接続しているクライアントアプリケーションのIPアドレスが確認できます。 この機能を利用して、無応答障害が発生している最中にこの情報を確認することで障害原因を絞り込んだり、CPU時間を確認することでCPUループを引き起こしているオペレーションを特定することができます。
また、この機能では各プロセスのCPU使用率、CPU使用時間(ユーザモード/システムモード)、メモリ使用量（仮想/物理）コンテナ状態（起動処理の進み具合）も採取することができます。
図3.4.4.4-1
この機能では、無応答障害に陥っているアプリケーションプロセス(Java)のスタックトレースを採取することができます。 この情報より、サーバアプリケーション中のどの箇所で無応答となっているかを特定することができます。 前述の実行時間の上限の監視機能では、無応答障害を検出すると、同様のスタックトレースを採取してAPトレースに記録します。
この機能では、無応答障害発生中に任意のタイミングでスタックトレースをAPトレースに記録することも可能です。 この機能を統合運用管理ツールから使用するには、プロセスグループ名を右クリックして「スタックトレースの採取」を実行してください。 コマンドを使用する場合は、マニュアルの [ リファレンス > コマンドリファレンス > TPシステム > wostack ] を参照してください。
また、実行時間の上限の監視機能が無応答障害を検出すると、終了直前に実行中だった未完のオペレーションの状態がシステムトレース( [ 構築・運用 > ログ > イベントメッセージ > Standard上のアプリケーションのログ出力 > サーバアプリケーショントレース採取 ] )に記録されます。 この情報から異常終了の原因をオペレーション単位で絞り込むことができます。
この機能では、一定時間オペレーション呼び出しがないクライアントアプリケーションの接続を強制的に切断することができます。 これにより、長時間使用されていない不必要と思われる接続を抑止し、ネットワークリソースの消費を抑えることができます。 設定方法は [ 構築・運用 > チューニング > APサーバ > その他チューニングに関する設定 > クライアント無通信監視間隔 ] を参照してください。
図3.4.4.4-1
TCPレベルのkeepalive機能を設定し、アライブチェックを行うことができます。これによりネットワーク障害で使用不可能となった接続を検出して切断することができます。 keepalive機能自体はOSが持つ監視機能となり、WebOTXではOSのkeepalive機能使用有無のみを設定します。keepalive機能のアライブチェック間隔は各OSに依存します。 WebOTXに対する設定は [ トラブルシューティング > 障害解析 > 機能別リンク > TPシステム(Standard) > クライアント接続数オーバーへの対応 ] を参照してください。
運用アシスタント機能は、定期的に採取した情報をもとにシステムの稼働状況を学習・分析し、適切な運用を支援する自律運用機能です。 運用アシスタントでは以下の設定の最適化と、適正値算出のコスト削減をはかることができます。 また、稼働状況の変化に合わせて、システムの設定を動的に変更させることも可能です。
システムの稼働状況から、設定されている多重度（プロセス数/スレッド数）が適切かどうか分析します。多重度は少なすぎると性能問題を引き起こし、多すぎると不必要にリソースを消費してしまいます。 本機能では、多重度が少なすぎる/多すぎると判断すると、統合運用管理ツールなどを通じてオペレータに通知します。また、オプション設定によって、システムの稼働状況に合わせて多重度を自動設定することもできます。
計算では求めづらく、また設定箇所の多い「実行時間の上限」を、運用アシスタント機能により自動的に算出します。 「実行時間の上限」はオペレーションのストール障害復旧の要となる重要な設定です。 オペレータは一つの操作だけで、全オペレーションに対して適切な実行時間の上限を設定することができます。
オペレーションの呼び出し時間の統計データより、平常時よりオペレーション実行時間が長くなっている場合に、スローダウン障害を検出して統合運用管理ツールなどを通じてオペレータに通知します。 本機能では一般的な監視機構とは違って、オペレーションごとの閾値設定なしでスローダウン障害を検出できます。 また、スローダウン状態が長期化している場合は、更に警告を通知します。このときには自動的にスタックトレースも採取するので、スローダウン障害発生時の情報の消失を防ぎ、障害調査を容易にします。
本機能ではスローダウン発生時にイベントログ・シスログにメッセージを出力します。 さらにV8.2以降では、アプリケーションログにスタックトレースを3秒間隔で5回出力するので、これらを確認することでどの処理で遅延が発生しているか特定できる場合があります。
オペレーションのスローダウンを検出してから「スローダウンの継続を監視する間隔」を超えてなお、スローダウン状態が継続していると「長期にわたるスローダウン状態」を検出し、 イベントログ/syslog,agent.log(webotx_tpmmgr.log)にメッセージを出力するとともに、該当プロセスグループのスタックトレースを採取します。 このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。 詳しくは [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント ] を参照してください。
スローダウン検出後は、ジャーナル、オペレーションジャーナル、イベントジャーナルなどの統計データから原因を絞り込むことができます。 詳しくは [ トラブルシューティング > 障害解析 > 機能別リンク > TPシステム(Standard) > オペレーション遅延への対応 ] を参照してください。