ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソフトウェア
  3. WebSAM
  4. Micro Focus Performance Agent software
  5. FAQ
  6. FAQ(障害)
ここから本文です。

Micro Focus Performance Agent software - FAQ(障害)

Micro Focus Performance Agent softwareは、以前はHP OpenView Performance Agent(OVPA)、OpenView MeasureWare(MWA)と呼称されておりました。

障害

Q1Micro Focus Performance agent software(以下、OVPA)で障害が発生したときに採取する情報はなにがありますか。
A1発生した障害の内容などにもより取得する情報は多種になります。
下記以外にも採取する情報はありますが、障害問合せの都度障害内容を判断した上でレスポンスセンターより依頼させていただきます。

採取情報の代表例:
    あらかじめロケールの設定を"C"に設定してください。
  • 障害発生日時と当時実施されたOVPAを除く他作業の有無を確認してください。
    (有れば、その詳細も報告してください。)
  • 障害の再現性有無と再現手順を教えてください。
  • OVPAのバージョンが11.XXよりも古い場合
    /opt/perf/bin/perfstat -z を実行して作成された圧縮ファイルを採取してください。
  • OVPAのバージョンが11.XX以降の場合
    /var/opt/OV/tmp/oa_data/ディレクトリ削除(前回採取時の残骸)
    /var/opt/OV/tmp/oa_data_YYYY-MM-DD_HH.MM.tar.gz 削除(前回採取時の残骸)
    cd /opt/OV/contrib/OpC
    ./oa_data_collector.sh -sap を実行
    /var/opt/OV/tmp に作成された圧縮ファイル oa_data_YYYY-MM-DD_HH.MM.tar.gz を採取してください。
Q2Micro Focus Performance agent software(以下、OVPA)が何かのトラブルによりコアファイルを出力した場合、コアファイルの出力先はどこになりますか。
A2コアファイルの出力先は、カレントのディレクトリになります。
なお、OVPAでは出力先の指定はサポートしておりません。
OVPAはrootユーザで利用する為、通常は/(ルート)配下を確認して頂くことになります。
Q3Micro Focus Performance agent software(以下、OVPA)の以下のメトリックを用いて取得したメモリ使用率の合計値が100%になりません。
GBL_MEM_UTIL = GBL_MEM_SYS_UTIL + GBL_MEM_CACHE_UTIL + GBL_MEM_USER_UTIL
A3GBL_MEM_UTIL(システム全体のメモリ使用率)は、GBL_MEM_FREE_UTIL(FREE領域のメモリ使用率)を含みません。
OS既存コマンド等で確認できるメモリ使用率とは異なり、OVPAでは空き部分を考慮していません。
GBL_MEM_UTILは、ユーザモードで使用されているメモリ使用率とシステムモードで使用されているメモリ使用率とバッファキャッシュで使用されているメモリ使用率の合計です。
Q4Micro Focus Performance agent software(以下、OVPA)のGBL_MEM_USERとpsコマンドのSZ(*1)の同時刻帯の採取値が同じになりません。
*1:プロセスのテキスト、データ、およびスタック・スペースの物理メモリサイズ
A4それぞれの集計方法なども異なるため、必ず同じ値(測定値)になるとは限りません。 同じ兆候を示しているかを確認する場合、双方の比較は有益です。
双方が出力する値(測定値)はそれぞれ異なることがあるため、双方の値を比較することは有益ではありません。

OVPAのGBL_MEM_USERは、ユーザーコードとデータに割り当てられた物理メモリ量であり、コード、ヒープ、スタック、共有メモリを含んでいます。
psコマンドのSZには、共有メモリやmmapの領域が含まれません。
このような集計方法の違いが値(測定値)の違いとなって表面化しています。
Q5Micro Focus Performance agent software(以下、OVPA)のGBL_CPU_*とsar -uコマンドの各CPU使用率情報の値が同じになりません。
(sar -uコマンドで出力される、"%usr", "%system", "%total"に該当するOVPAのメトリックをおしえてください。)
A5それぞれ集計方法なども異なるため、必ず同じ値(測定値)になるとは限りません。
同じ兆候を示しているかを確認する場合、双方の比較は有益です。
双方が出力する値(測定値)はそれぞれ異なることがあるため、双方の値を比較することは有益ではありません。

sar -u の結果と近い値(近似値)を提供するメトリックは以下のGBL_CPU_* になります。
  • sarの"%usr" : GBL_CPU_USER_MODE_UTIL
  • sarの"%system" : GBL_CPU_SYS_MODE_UTIL
  • sarの"%total" : GBL_CPU_TOTAL_UTIL
Q6【Linux版】Micro Focus Performance agent software(以下、OVPA)のメトリックとLinux環境でfreeやvmstatなどのOS標準コマンドの測定した値が一致しません。
A6それぞれ集計方法なども異なるため、必ず同じ値(測定値)になるとは限りません。
同じ兆候を示しているかを確認する場合、双方の比較は有益です。
双方が出力する値(測定値)はそれぞれ異なることがあるため、双方の値を比較することは有益ではありません。

OVPAは長期間の傾向を分析するために、測定インターバルは5分となっています。(その間に収集した測定値を集約します。)
一方、OS標準コマンド(freeやvmstat)は5分の集約値ではないため、メモリ使用状況の変動がまったくない状況でなければ、その測定値はおのずと差異が出ます。
Linux版OVPAの場合は OSが提供している/proc/meminfo(各種メモリリソースのパフォーマンスデータが格納)の数値だけを利用しているのでなく、その他の要素も加えて独自に計算しているため差異が発生します。
Q7日曜日00:00:00にcodaプロセスが再起動しています。なぜでしょうか。
A7バージョン11.XXまでに実装されていたcodaプロセスの仕様による動作です。(バージョン12.XX以降は該当しません。)

codaプロセスは/var/opt/OV/datafiles/codaXXXXXファイルのロールバック処理を実施するために日曜日の00:00:00に自動再起動を行います。
この処理に対して、時間の変更、有効/無効等の設定をすることはできません。 また、この時間にCODAプロセスが停止していた場合、直後の起動したタイミングで自動再起動が実行されます。
Q8Micro Focus Performance agent software(以下、OVPA)がインストールされているサーバの/varの空容量がなくなりました。OVPAへの影響はあるでしょうか。
A8OVPAの性能データは/var配下のOVPAディレクトリに蓄積されます。
/varの空容量がない場合、性能データを蓄積することができないため、OVPAのプロセス(scopeux/oacore)が異常終了します。
復旧するためには、/var配下の空き容量を確保した後にOVPAを停止させて性能データ(rawlog)を退避、削除してからOVPAを起動させて下さい。
性能データ(rawlog)の退避、削除方法については、こちらを参照してください。

なお、OVPAが正常に性能データを蓄積し続けるために必要な最低限の/var配下の空き容量の目安は、/var/opt/perf/parmファイルのsizeパラメータで指定している各log*ファイルのSIZE値の合計を2倍した値を最低限確保することを推奨しています。
Q9【全プラットホーム対象/バージョン11.XX以前】
/var/opt/perf/datafiles/log* ファイル(rawlog)の各ファイルサイズが2GB以上になると、rawlogの破損((corrupt)が発生して性能データを収集、蓄積するデーモンであるscopeuxが異常終了します。
(/var/opt/perf/parmファイルのsizeパラメータで2GB以上のファイルサイズを指定しないでください。)
A9バージョン11.XX以前が対象です。(12.XX以降のバージョンは該当しません。)

/var/opt/perf/datafiles/log* ファイル(rawlog)のファイルサイズが2GB以上になると、rawlogの破損((corrupt)が発生して性能データを収集、蓄積するデーモンであるscopeuxが異常終了する既知問題があります。
回避策は、/var/opt/perf/parmファイルのsizeパラメータの各rawlogのサイズ値を2GBより小さいサイズに設定し、2GBに達する前にロールバック処理(ロールアウト処理)が実行されるように設定してください。

なお、parmファイル編集後は必ず/opt/perf/bin/ovpa restart scopeを実行して、OVPAに対してparmファイルを再読み込みさせてください。
Q10/var/opt/perf/status.scopeに以下の警告が頻繁に出力されていました。
これは致命的な問題でしょうか。

**** /opt/perf/bin/scopeux : 02/18/06 19:31:09 ****
WARNING: Measurement Buffers Lost see metric
GBL_LOST_MI_TRACE_BUFFERS. (PE221-50)
A10致命的な障害ではありません。
メッセージは、リソース収集処理中のmidaemonが、カーネルから得た情報を円滑にscopeux/oacoreプロセスやGlancePlus製品に引き渡せなかったことを意味します。
このメッセージが頻繁に出力される場合には、/opt/perf/bin/midaemon -sizesを用いてmidaemonが起動する際に確保する共有メモリ資源の取得サイズを確認し、共有メモリ資源のサイズを調整することを推奨します。

midaemonの共有メモリ資源のサイズ調整については、こちらを参照してください。
Q11ディスクストレージが接続されているマシンにOVPAがインストールされています。
ディスクストレージから提供される個別論理Diskならびに、ディスクストレージ内に構成されるLUN/物理Diskに関するリソース情報がOVPAでは正しく表示されない場合があります。
A11製品の使用上の注意事項に抵触して発生している事象になります。

OVPAが提供可能としているDisk情報(BYDSK_*)は、SCSI接続された内蔵Diskが対象であり、ディスクストレージ装置から提供される個別論理Diskに対する情報の提供機能は有していません。 そのため、今回のような環境ではOVPA側から見た情報が期待通りの情報を返さない場合があります。
このような環境構成の場合には、ディスクストレージから提供される個別論理Diskならびに、ディスクストレージ内に構成されるLUN/物理Diskに関する情報は、各ディスクストレージベンダーが提供しているディスクストレージ管理ソフト(例えば、EMC社製ストレージであれば EMC Control Center (ECC))を用いて行うことを推奨しています。

OVPAとしては、ディスクストレージ装置が付加されているシステムでOVPAを用いる場合には、ストレージから提供される論理Diskの性能/閾値監視やリソース情報の収集の実施をするのではなく、システム全体のDisk情報(GBL_DISK_*)を参照するに留める運用の実施を推奨します。
Q12【HP-UX版】HP-UX 11iv3(11.31)にMicro Focus Performance agent software(以下、OVPA)をインストールしたところ、midaemonが使用するメモリ使用量(RSS)のサイズが500MBを超えるサイズを使用しています。
A12HP-UX 11iv3上で動作する、OVPAならびにMicro Focus GlancePlus softwareで動作するmidaemonの実装動作により取得されたサイズになります。
この動作は、製品の障害で発生している事象ではありません。

この報告事例では、事象の発生はHP-UX 11iv3マシンのFirmwareの更新(Ver. 6.0.0521への更新)を境に発生する様になったと報告しています。
midaemonが取得するRSS(以下、workarea)のサイズはGBL_NUM_CPUメトリックを元にして算出されますが、HP-UX 11iv1, 11iv2までは、GBL_NUM_CPUが参照するkernel構造体には、「実際に実装されているCPU(core)数」がkernelより返され、それを元にworkareaのサイズを取得していました。
Firmwareの更新で、この構造体には『搭載可能な最大CPU(core)数』を返す様に仕様が変わりました。
そのため、HP-UX 11iv3上で動作するmidaemonは、11iv1, 11iv2の時に比べより多くのworkareaサイズを取得するようになりました。

この事象は、搭載可能なCPU(core)数が多くなるHP-UX 11iv3サーバー(マシンのTierの数字が大きなHP-UX 11iv3サーバー)で顕著に現れます。

なお、この既知問題については、OVPAのバージョン11.11で製品側で対応済みです。

ページの先頭へ戻る