13. TPモニタ

13.1. 注意事項

13.1.1. UNIX版でのsignal利用制限

UNIX版のサーバアプリケーションの内部では、signalが発生すると異常処理が発生したと見なして、TPモニタはアボート処理を行います。 よって、signalを利用したサーバアプリケーションの作成を制限しています。

特に重大な障害時に発生するSIGILL,SIGFPE,SIGBUS,SIGSEGVや内部制御用に使用しているSIGUSR1,SIGUSR2のシグナルマスクを変更した時の動作は保証できません。

Linux版にて、プロセスグループの「モジュールの種類」にJava EE または CORBA Javaを選択している場合、そのサーバアプリケーションがSIGTERMを受信すると、プロセスは停止処理を行わずに即時終了します。サーバアプリケーションがSIGTERMを受信するケースは、次のとおりです。

13.1.2. オブジェクトリファレンスの登録方法が一時的の場合の注意点

(CORBAの場合のみ)
名前サーバへのオブジェクトリファレンスの登録方法が"一時的に扱う"の場合、プロセス起動時に多数のリファレンスを一度に登録すると名前サーバに負荷がかかります。 名前サーバへの登録に失敗したりクライアント側でオブジェクトリファレンスの取得に失敗したりする可能性がありますので注意してください。

13.1.3. Javaのクラスロードについて

CORBAアプリケーションの場合、Javaのクラスロードの優先順は以下のようになります。

  1. J2SEの標準クラス
  2. ${AS_INSTALL}/domains/<ドメイン名>/lib/ext配下のjarファイル内のクラス
  3. WebOTXのシステムクラス
  4. 環境変数CLASSPATHに設定されているjarファイル内のクラス
  5. 共有コンポーネントのjarファイル内のクラス
  6. R4形式サーバコンポーネントのjarファイル内のクラス
  7. R5形式サーバコンポーネントのjarファイル内のクラス

次のような向きのクラス参照はできませんので注意してください。

また、複数のjarファイルでクラスの重複がある場合、java.lang.ClassCastException等のエラーが発生する可能性があります。 その場合は、クラスの重複を取り除くような対処をしてください。
もしクラスの重複を取り除くのが困難である場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できる可能性があります。

-notusewojarloader

ただし、このオプションを設定しますとコンポーネントの動的配備・配備解除機能が利用できなくなりますのでご了承ください。
Java EEアプリケーションの場合は [ ドメイン構築・基本設定ガイド > 5. アプリケーション > 5.9. クラスローダ ] を参照してください。

13.1.4. Javaヒープサイズ、メモリプールサイズ、最大同時接続数の上限

32ビットWindowsを使用している場合、WebOTXではJavaヒープサイズとメモリプールサイズの合計は最大で700MB程度となります。また、IIOPリスナの最大同時接続数の設定可能な値はOSの制限により最大で1700程度です。

  1. Javaヒープサイズの上限
    メモリプールサイズ + Javaヒープサイズ < 700MB程度
    Javaヒープサイズは連続した領域を確保する必要があります。 ユーザアプリケーションが使用できる仮想メモリ空間はOSの制限により2GBとなっていますが、連続して確保できる領域はProcessExplorer等のツールを使用して確認すると1.4〜1.6GB程度となっています。(連続した領域でなければ2GB程度使用可能です。)
    WebOTXではユーザアプリケーションのプロセスの仮想メモリの一部領域をWebOTX制御用としてアドレス固定で確保しているため、Javaヒープサイズが確保できる連続した領域は700MB程度となります。
    よって、32ビットWindowsにおいてCORBA Javaプロセスグループ、またはJava EEプロセスグループでメモリプールサイズや初期ヒープサイズ、最大ヒープサイズを変更する場合は、それらの合計値が700MB以下となるようにしてください。

  2. IIOPリスナの最大同時接続数の制限
    次の式で示されるIIOPリスナプロセスの仮想メモリ空間の制限があります。 ただし、メモリプールサイズとIIOPリスナの最大同時接続数だけで2GB分の仮想メモリを全て使用できるわけではありません。 IIOPリスナの最大同時接続数の上限は最大1700程度となっています。
    メモリプールサイズ + IIOPリスナの最大同時接続数 * 1MB <2GB程度
    OSで各スレッドに1MBのスタック空間が割り当てられているため、IIOPリスナの接続端末1つに1MBが必要になります。 各スレッドで必要な連続領域は1MBであり、Javaヒープサイズのように数百MBの領域を連続して確保する必要はないため、OSの制限である2GBに達するまではIIOPリスナの最大同時接続数を増やすことが可能です。
メモリプールサイズ + Javaヒープサイズを700MB以上としたい場合の拡張方法

WindowsでJavaアプリケーションのみを使用している場合に限り「メモリプールサイズ + Javaヒープサイズ」の上限を900MB程度まで拡張することができます。 WebOTXを停止した状態で次のファイルのバックアップを採取後、任意の行に次の値を追加(手修正)してください。

修正ファイル : ${INSTANCE_ROOT}\config\tpsystem\tpbase.cnf
値 : (以下の3行をそのまま追加(セパレータは空白文字))
QUESHMATADDR 20000000
MSGSHMATADDR 21000000
MEMSHMATADDR 23000000

13.1.5. 送受信電文長の上限

WebOTXは大量のクライアントからの同時リクエストに対応し、一台のクライアントの送受信に通信等が占有されることはシステム構築上避けるべきである、というコンセプトの元に作成されています。
よってWebOTXサーバにおける送受信電文長の上限を99,999,998バイトと定めています。
これを超える通信があった時は、CORBA::IMP_LIMIT()、マイナー=LENGTH_OVER(3933)エラーが出力されます。

リクエスト電文長(クライアントからサーバへの要求)は、200から300バイトのヘッダ領域の後にinおよびinoutの引数データが続きます。 このデータの大きさは型の定義と並びに依存します。
リプライ電文長(サーバからクライアントへの返却)は、40バイト前後のヘッダ領域の後にoutおよびinoutの引数データが続きます。 このデータの大きさも型の定義と並びに依存します。

プロセスグループの「トレース設定」で「トレースレベル」を6以上に設定すると、送受信電文長を確認できます。

13.1.6. プロセスグループ上でのオブジェクトリファレンス参照について

V8.3よりプロセスグループのJavaシステムプロパティに「jp.co.nec.orb.UseHostName=true」を指定しません。 これにより、オブジェクトリファレンスでホスト名はIPアドレス形式に変換して設定されます。 オブジェクトリファレンスにホスト名を使用する場合は、プロセスグループのJavaシステムプロパティに「jp.co.nec.orb.UseHostName=true」を指定します。

IPアドレスを利用する方が性能は優れていますが、IPアドレスの変更に備える場合やV8.2以前と同じ動作を期待する場合は「jp.co.nec.orb.UseHostName=true」を指定してください。

13.1.7. TPシステム関連のコマンド実行でエラーとなる

Windows OSで、TPシステム関連のコマンド(wostack, jnlsave, stop_tpm, contpsなど<WebOTXインストールディレクトリ>\Trnsv\binにあるコマンド)はマシンにログインしたユーザで実行されます。ログインユーザとWebOTX AS Agent Serviceのサービスを起動するアカウントが異なる場合、コマンドの実行はエラーとなります。これらのコマンドを使用する場合、WebOTX AS Agent Serviceのサービスを起動するアカウントでマシンにログインしてください。
なお、WebOTX AS Agent Serviceのサービスを起動するアカウントをローカルシステムアカウントとしている場合、コマンドの実行はエラーとなり、使用できません。コマンドを使用したい場合、WebOTX AS Agent Serviceのサービスを起動するアカウントの変更が必要になります。

13.1.8. coreの最大サイズ指定について

V9.2から、tpadm2.shの廃止に伴い、TPモニタで固定値を設定していたcoreの最大サイズ指定を廃止しました。coreの最大サイズは起動するシェルの設定に従いますので、ulimitコマンドの利用や/etc/security/limits.confファイルの編集などにより、coreの最大サイズを指定してください。
環境によってはcoreの最大サイズの既定値が0であるため、coreが出力されず、障害発生時の調査が困難になる可能性があります。
なお、coreはプロセスが使用するメモリ使用量に応じたサイズとなりますので、coreの最大サイズが小さい場合、不完全なファイルとなります。
逆に、coreの最大サイズを大きくすると、大量にメモリを使用するプロセスで障害が発生した場合、coreの出力によってプロセスの停止に時間がかかります。
システムで許容される負荷やディスクの空き容量などから、coreの最大サイズを決定してください。

13.1.9. 動的配備・配備解除について

起動中のプロセスグループに対してコンポーネントの配備・配備解除を行う動的配備・配備解除機能には、以下のような制限があります。

13.2. 制限事項

13.2.1. モジュールアイドル時間について(C++のみ)

TPシステムの「例外ハンドル」の設定で、「例外ハンドルを行う」がtrue(既定値)である場合、マルチスレッドで動作するC++アプリケーションのオペレーション呼び出しが例外すると、以降該当モジュールの「モジュールアイドル時間」が更新されなくなります。
該当プロセスグループを再起動すると、モジュールアイドル時間が更新されるようになります。

13.2.2. IPv6使用時のIPアドレス表示

IPv6使用時、以下の情報のIPアドレスを表示できません。
いずれの場合も、IPアドレス情報には"255.255.255.255"が表示されます。

13.2.3. start-domainコマンドの使用制限について

Windows版のWebOTX Application Serverでは、以下の条件を全て満たす場合に運用管理コマンド(otxadmin)のstart-domainによるユーザドメインの起動が失敗します。

以上の条件を満たす環境で運用管理コマンド(otxadmin)のstart-domainでユーザドメインを起動する場合は、"WebOTX AS Agent Service"サービスのログオンユーザをLocal System以外の管理者権限を持ったユーザに変更してください。

13.2.4. クライアント管理ライブラリの利用について

Windows版では、VC++2005、VC++2008では、クライアント管理ライブラリを利用できません。また、VC++2010、VC++2012のデバッグ版でも、クライアント管理ライブラリを利用できません。

13.2.5. ドメインを強制停止する場合の使用制限について

Windows版のWebOTX Application Serverでは、運用管理コマンド(otxadmin)のドメイン停止コマンド(stop-domainコマンド)を実行する際に次の条件を満たすとTPシステムの停止に失敗します。

上記の条件を満たす場合は、以下の記述順番通りにTPシステムの停止を行ってください。

  1. 事象発生の確認
    ドメイン強制停止後に、タスクマネージャからTPシステムのプロセスが残存していないかを確認します。
    タスクマネージャを起動し、テーブルに表示する列の選択画面から「コマンドライン」のチェックボックスをチェックした状態で、プロセスの一覧からtpmMain.exeのプロセスを探します。tpmMain.exeが存在した場合、コマンドラインの列に表示されている内容から、停止が失敗したTPシステムと一致するか確認します。
    tpmMain.exeのコマンドラインの表示例
    "<WebOTXインストールディレクトリ>\Trnsv\bin\tpmMain.exe" -n <TPシステム名> -l ・・・・
    TPシステム名は${INSTANCE_ROOT}\logs\tpsystem\history.act の以下の表示から確認します。
    TPS15-01216 起動情報 : TPM NAME=[<TPシステム名>], TPM NUM=[<数字>], PID=[<PID>],CURRENT DIR=[<インストールディレクトリ>]

    上記確認の結果、TPシステムのプロセスが残存している場合は 2.以降の手順に進みます。
  2. タスクスケジューラへの登録
    次のコマンドでタスクを登録します。引数に指定する<TPシステム名>は 1. で確認したTPシステム名と同様です。
    >SCHTASKS /Create /SC ONIDLE /I 1 /TN tpmprockill /RU "" /TR "cmd.exe /c '<WebOTXインストールディレクトリ>\Trnsv\bin\wotpm.exe' stop <TPシステム名>
    成功: スケジュール タスク "tpmprockill" は正しく作成されました。
    
  3. タスクスケジュールの実行
    次のコマンドにて 2. で登録したタスクを即時実行します。
    >SCHTASKS /Run /TN tpmprockill
    成功: スケジュール タスク "tpmprockill" の実行が試行されました。
    
  4. タスクスケジュールの削除
    次のコマンドにて 2. で登録したタスクを削除します。
    >SCHTASKS /Delete /TN tpmprockill /F
    成功: スケジュール タスク "tpmprockill" は正しく削除されました。
    
  5. 残存プロセスの確認
    1.で確認したプロセスが停止したことを確認します。
  6. ドメインの起動
    1〜5までを完了後、ドメインを起動します。